SSL avanzato: Autorità di certificazione intermedia e distribuzione di box incorporati

Question

Ok Ragazze e ragazzi SSL avanzati - Aggiungerò una taglia a questo dopo i due giorni, perché penso che sia un argomento complesso che merita una ricompensa per tutti coloro che meditatamente risposte.

Alcuni dei presupposti qui sono semplicemente questo: ipotesi, o ipotesi più speranzose. Considera questo un rompicapo, semplicemente dicendo 'Questo non è possibile' manca il punto.

Soluzioni alternative e parziali sono le benvenute, esperienza personale se hai fatto qualcosa di "simile". Voglio imparare qualcosa da questo anche se il mio intero piano è difettoso.

Ecco lo scenario:

Sto sviluppando su un sistema Linux embedded e vogliono il suo server web per essere in grado di servire out-of-the-box, SSL senza problemi. Ecco i criteri di progettazione sto puntando per:

must have:

• non posso avere l'utente aggiungere il mio certificato CA homegrown per il proprio browser
• che non posso avere l'utente aggiungi al browser un certificato autofirmato generato staticamente (in formato mfg)
• Non riesco a chiedere all'utente di aggiungere al proprio browser un certificato autofirmato generato dinamicamente (all'avvio).
• Non è possibile eseguire l'impostazione predefinita su HTTP e avere un abilitato/disabilitato per attivare SSL. Deve essere SSL.
• Sia la casella incorporata che il client browser Web possono avere o meno l'accesso a Internet, pertanto è necessario presupporre che funzioni correttamente senza accesso a Internet. Le uniche CA radice su cui possiamo fare affidamento sono quelle fornite con il sistema operativo o il browser. Facciamo finta che quella lista sia "fondamentalmente" la stessa attraverso i browser e i sistemi operativi - ad esempio, avremo una percentuale di successo del ~ 90% se ci basiamo su di essi.
• Non riesco a utilizzare un'operazione fly-by-night, ad esempio "Certificato SSL di Fast Eddie Clearing House - con prezzi così bassi i nostri server DEVONO essere compromessi! '

Nice to have:

• non voglio che l'utente ha avvertito che il nome host del certificato non corrisponde al nome host nel browser. Considero questo piacevole da avere perché potrebbe essere impossibile.

Non vogliamo:

• Non voglio spedire lo stesso insieme di chiavi statiche per ogni casella. Tipo di implicito nella lista 'can not', ma conosco il rischio.

Sì Sì, lo so ..

• posso e forniscono un meccanismo per l'utente di caricare i propri cert chiave/ma ritengo questa 'modalità avanzata' e fuori del campo di applicazione di questa domanda. Se l'utente è abbastanza avanzato da avere la propria CA interna o le chiavi di acquisto, allora sono fantastici e io li adoro.

Pensando Cap Tempo

La mia esperienza con SSL sta generando CERT/chiavi per essere firmato da root 'reale', così come intensificare il mio gioco un po 'con fare il mio CA interna , distribuendo certs internamente "autofirmati". So che puoi concatenare i certificati, ma non sono sicuro di quale sia l'ordine delle operazioni. Ad esempio, il browser "avvicina" la catena vede una CA radice valida e la vede come un certificato valido, oppure è necessario avere la verifica a tutti i livelli?

Mi sono imbattuto nella descrizione di intermediate certificate authority che mi ha fatto pensare a potenziali soluzioni. Forse ho passato da 'la soluzione più semplice' a 'modalità incubo', ma sarebbe possibile:

Crazy Idea # 1

• Ottenere un intermedio cert un'autorità certificato firmato da un 'vero e proprio ' CIRCA. (ICA-1)
  • ROOT_CA -> ICA-1
• Questo certificato sarebbe stato utilizzato in fase di produzione per generare una coppia di un'autorità di certificazione unica senza password sub-intermedio per scatola.
  • ICA-1 -> ICA-2
• Usa ICA-2 per generare un cert/chiave del server unico. L'avvertenza qui è, puoi generare una chiave/coppia per un IP (e non un nome DNS?)? Ad esempio, un potenziale caso d'uso sarebbe l'utente che si connette inizialmente alla casella tramite http e quindi reindirizza il client al servizio SSL utilizzando l'IP nell'URL di reindirizzamento (in modo che il browser non si lamenti delle mancate corrispondenze). Questa potrebbe essere la carta che porta giù la casa. Poiché la connessione SSL deve essere stabilita prima che possano verificarsi eventuali reindirizzamenti, posso vedere che anche questo è un problema. Ma, se tutto ciò funzionasse magicamente
• Potrei quindi utilizzare l'ICA-2 per generare nuove coppie di chiavi/chiavi ogni volta che la casella cambia IP in modo che quando il server Web viene ripristinato, ha sempre una catena di chiavi 'valida'.
  • ICA-2 -> SP-1

Ok, sei così intelligente

Molto probabilmente, la mia soluzione contorta non funzionerà - ma sarebbe ottimo se lo facesse. Hai avuto un problema simile? Che cosa hai fatto? Quali sono stati gli scambi commerciali?

Answer 1

Fondamentalmente, no, non puoi farlo nel modo che speri.

Non sei un'autorità SSL intermedia e non puoi permetterti di diventarne uno. Anche se lo fosse, non c'è verso di dargli la possibilità di distribuire ai consumatori tutto il necessario per creare nuovi certificati validi per qualsiasi dominio, considerato di default in tutti i browser. Se ciò fosse possibile, l'intero sistema crollerebbe (non che non abbia già problemi).

In genere, le autorità pubbliche non possono firmare i certificati emessi per gli indirizzi IP, anche se non c'è nulla che tecnicamente lo possa impedire.

Ricordare che se si distribuiscono realmente le chiavi private in moduli crittografici protetti a prova di manomissione, i propri dispositivi non sono realmente protetti da SSL. Chiunque abbia uno dei dispositivi può estrarre la chiave privata (soprattutto se è senza password) e fare attacchi MITM validi, firmati, su tutti i tuoi dispositivi. Scoraggi le intercettazioni occasionali, ma questo è tutto.

L'opzione migliore è probabilmente ottenere e firmare i certificati per un sottodominio Internet valido, quindi richiedere al dispositivo di rispondere per tale sottodominio. Se si tratta di un dispositivo di rete nel percorso in uscita, è probabile che sia possibile eseguire alcune magie di routing per farlo rispondere al dominio, analogamente a quanti sistemi walled-garden funzionano. Potresti avere qualcosa come "system432397652.example.com" per ogni sistema, e quindi generare una chiave per ogni casella corrispondente a quel sottodominio. Avere l'accesso IP diretto al reindirizzamento al dominio e fare in modo che la casella intercetti la richiesta o eseguire alcuni trucchi DNS su Internet in modo che il dominio risolva l'IP interno corretto per ciascun client. Utilizzare un dominio host a scopo singolo per questo, non condividere con altri siti Web aziendali.

Pagare di più per i certificati in realtà non li rende più o meno legittimi. Nel momento in cui un'azienda è diventata una CA radice, è lontana da un'operazione fly-by-night. È necessario verificare e verificare se lo standard StartSSL è adatto alle proprie esigenze, poiché non vengono addebitate in base ai certificati.