Perché non richiediamo che i siti Web abbiano più certificati indipendenti?

why do we not require websites to be validated by, say, 3 certificates of independent CAs?

Ecco alcuni motivi:

1. Costo . I certificati di acquisto sono già piuttosto costosi *; triplicare tali spese e costringere gli acquirenti a guadare più a fondo nel pool di potenziali CA, dove solitamente partono da un punto di vista economico, non sarebbe il benvenuto.

2. Complessità . Al momento, se un certificato scade, il sito è offline o degradato fino a che l'IT non riesce a scansioni e risolve il problema. Succede sorprendentemente spesso dato che le date di scadenza sono conosciute e possono essere pianificate per. La tua proposta triplicherebbe il numero di certificati che devono essere installati correttamente, che devono essere sostituiti prima della scadenza, che necessitano di catene di certificati corrette ... Alcune di queste cose sono già abbastanza difficili oggi con una sola CA!

3. Compatibilità . I protocolli TLS non specificano un metodo operativo in cui devono essere convalidati più certificati, pertanto è necessario aggiornare o sostituire il protocollo in uso, operazione che richiederà anni. Non c'è modo di specificare al client che questo particolare server richiede la convalida multi-certificato, quindi gli attacchi di downgrade sono banali - ancora una volta, avresti bisogno di creare un metodo, e quindi attendere anni prima che il supporto si diffonda.

4. Blocco del certificato . La tua idea dice "Supponiamo che il modello CA sia rotto e che una soluzione aumenti la nostra dipendenza dal modello CA." Se una CA può essere compromessa, perché non due (supponendo che una maggioranza di 2/3 vince nel modello)? A quel punto inizierai a dire "Beh, ovviamente vogliamo fidarci di Entrust più della Consolidated Republik of Tadpolistan" - a quel punto hai raggiunto Blocco del certificato , che è già una cosa.

5. WoT else? L'altra conclusione naturale che raggiungerai, quando decidi che alcune CA sono più affidabili di altre, è che dovrebbe esserci un metodo per incorporare la reputazione. Questo è chiamato Web of Trust ed è un modello concorrente per il trust centralizzato delle CA oggi. Un'implementazione del metodo WoT è il Perspectives Project , che è un approccio interessante allo stesso problema che descrivi (e che funziona in complemento a e in compatibilità con il modello di CA esistente).

* Prima che qualcuno salti e dice "Startcom!" oppure "Let's Encrypt", ricorda che oggi le aziende guidano il modello CA. Pagano ingenti somme di denaro e alcuni di loro acquistano migliaia di cerati ogni anno. L'impatto sui costi deve essere considerato contro tutti i giocatori. (E anche nella fascia bassa, se vuoi un certificato gratuito, ora dovresti trovare 3 fornitori gratuiti affidabili, quando trovarne uno era già una sfida.)

RTLS non supporta più certificati foglia per una singola sessione, né X509 supporta più emittenti per un singolo certificato. Ciò significa che ci saranno cambiamenti necessari sul protocollo. Ma lascia semplicemente ignorare lo sforzo per apportare tali modifiche e guardare quanta più sicurezza otteniamo con la tua proposta. Diamo un'occhiata a come può essere emesso un cattivo certificato, in quali situazioni la tua proposta aiuta e in che modo si confronta con le proposte esistenti.

In che modo l'autore dell'attacco può ottenere un certificato

Un certificato errato può essere emesso se la CA è compromessa dall'aggressore, ovvero è bacata, compromessa o se la CA impiega persone non affidabili. In questo caso la tua proposta sarebbe di aiuto perché speri che non tutte le CA multiple abbiano questi problemi allo stesso tempo. Ovviamente non è così semplice, perché è meglio assicurarsi che le diverse CA siano effettivamente controllate da entità diverse ed eseguano codice diverso, cioè che un singolo hack non sia in realtà un hack di più CA.

Ma un utente malintenzionato può anche ottenere un certificato compromettendo il processo di convalida del dominio . Questo processo funziona in modo simile per tutte le CA e se l'utente malintenzionato accede alla posta del proprietario del dominio o del server, potrebbe ottenere un certificato per lo stesso server da più CA. In questo caso la tua proposta non sarebbe affatto di aiuto. Ma ovviamente in questo caso l'hacker otterrebbe solo l'accesso ad alcuni certificati per domini male protetti, mentre nel caso di un compromesso CA potrebbe ottenere molti certificati anche per domini con buona sicurezza.

Quali proposte alternative esistono

Con certificato o pinning chiave pubblica ( HPKP ) a il proprietario del dominio può assicurarsi che il certificato utilizzi una chiave pubblica specifica. Con HPKP l'effetto è che l'utente malintenzionato dovrebbe ottenere l'accesso alla chiave privata del certificato esistente, ovvero hackerare il server. Questo protegge i domini con una buona sicurezza contro l'uso improprio dei certificati l'autore dell'attacco creato compromettendo una CA. La cosa bella di HPKP è che è economico e facile da implementare e che è già supportato dai principali browser .

La trasparenza del certificato è un registro pubblico che può essere utilizzato per scoprire se una CA ha emesso un certificato che non dovrebbe e se una CA è a conoscenza del fatto che ha emesso un certificato specifico . Questo può essere utilizzato dal proprietario del dominio per verificare la presenza di certificati rogue. Sebbene non tutti i CA abbiano registri di questo tipo, il numero è in crescita perché i fornitori di browser richiedono il supporto come requisito per diventare una CA affidabile. Per ora Chrome richiede che tutti i certificati EV (barra verde) siano coperti da tale registro e che alcune altre CA siano anche obbligate a rilasciare tali registri poiché hanno mostrato di avere insicurezze in passato. La cosa bella è che i browser di supporto come Chrome sanno quale CA dovrebbe avere un tale log e può controllarlo.

DANE consente al proprietario del dominio di pubblicare il proprio certificato in il DNS senza la necessità di CA. Naturalmente questo deve essere in qualche modo protetto dallo spoofing del DNS, quindi ha bisogno di DNSSec. DANE può essere utilizzato sia con certificati autofirmati che con una CA pubblica o con certificati firmati CA come protezione aggiuntiva. Sebbene non sia attualmente implementato nei browser, è già utilizzato per la posta da diversi provider e il supporto in questa area è in crescita.

Sommario

Sebbene la tua proposta sia utile per aumentare la sicurezza, è necessario apportare importanti modifiche al protocollo TLS esistente (servire più certificati foglia) o al modello X509 (più emittenti per un singolo certificato). Ma almeno i certificati multipli facoltativi sono probabilmente possibili da implementare con l'aiuto delle estensioni TLS, quindi non abbiamo bisogno di una nuova versione TLS per questo. Tuttavia, aumenterà i dati trasferiti durante l'intera stretta di mano (molti certificati fogliari e certificati di catena) che rallenteranno l'handshake.

Le proposte alternative non hanno bisogno di tali cambiamenti a livello di protocollo poiché funzionano al di fuori del protocollo TLS. Inoltre, nel caso di HPKP e DANE forniscono un maggiore controllo sul certificato al proprietario del dominio rispetto alla tua proposta.

Ma alla fine tutte queste idee potrebbero in teoria essere utilizzate insieme per aumentare la sicurezza. E mentre la tua proposta aumenterebbe la sicurezza, probabilmente è più dirompente degli altri e causerebbe più costi, ed è per questo che per ora gli altri sono preferiti.

Ciò che proponi aumenterebbe effettivamente la sicurezza, ma a un aumento dei costi amministrativi e della complessità tecnica. Penso che i compromessi CA siano semplicemente eventi troppo rari per giustificare tali costi. Inoltre, se uno schema simile verrà messo in pratica, sarà probabilmente più elaborato rispetto a semplici 2 voti su 3. Ad esempio, avere solo due certificati, uno valido e uno invecchiato, dovrebbe essere sufficiente per confermare l'identità proteggendo da singoli compromessi della CA.