Perché permettiamo che i certificati SSL vengano sostituiti prima della loro data di scadenza, senza la revoca di altri?

Il primo problema che riesco a vedere è come trovi il primo certificato? Se hai già visitato il sito in precedenza, suppongo che tu possa farlo, ma per chiunque non conservi i certificati in giro da tutti i siti che hanno visitato, avremmo bisogno di qualche infrastruttura per poter cercare tutti i certificati che risolvono per un particolare CN.

Inoltre, un tale sistema potrebbe aggiungere un altro punto di errore in quanto un tale servizio potrebbe essere attaccato (o la stessa lista di revoche potrebbe essere attaccata) con conseguente incapacità di autenticare un certificato.

Inoltre non sono sicuro che sia una grande minaccia per la sicurezza. A quanto ho capito, la lista di revoche riguarda principalmente l'impossibilità di utilizzare un certificato trapelato su un sito canaglia, per non impedire l'uso di un certificato canaglia da nessuna parte. E infatti, con un tale sistema, potrebbe essere possibile che il certificato canaglia annientasse la fiducia del certificato reale originale che potrebbe essere ancora più dannoso.

Sì, il problema dei registrar canaglia è un problema difficile da risolvere e se hai un archivio locale del certificato su file, allora potrebbe valere la pena di visualizzare un avviso se è stato sostituito prima della scadenza, ma io non sono certo che vogliamo che la revoca venga utilizzata per qualcosa di più della perdita del controllo della chiave privata o dell'emissione iniziale non valida (che in realtà è un'altra forma di perdita di controllo della chiave privata).

Esistono diverse situazioni normali che implicano l'esistenza di diversi certificati simultaneamente validi per un determinato server SSL:

• Il server ha diversi front-end, ognuno con la propria chiave privata e certificato, sebbene tutti i certificati contengano il nome del server. Avere una chiave privata per sistema è una buona idea perché evita lo spostamento delle chiavi private e lo spostamento delle chiavi private raramente è una buona idea.

• La chiave privata è stata persa, ma non è stata compromessa o rubata; per esempio. la macchina è stata distrutta in un incendio. Dovrebbe essere emesso un nuovo certificato per la nuova chiave del server, ma non c'è alcun punto in revocare il vecchio certificato (vedi sotto).

• Un certificato del server scadrà presto; ne viene rilasciato uno nuovo Ci sarà una certa sovrapposizione durante la quale entrambi i certificati sono validi, in modo che la transizione possa essere attivata senza alcun tempo di inattività.

Concettualmente , il modello X.509 è una delle affermazioni positive del locale proprietà. Un certificato X.509 dice "questa chiave appartiene a quell'entità". Non c'è nulla in X.509 che dice "quell'entità ha solo x certificati attivi"; questo non fa parte delle proprietà che X.509 tenta di mantenere, e sarebbe effettivamente impossibile da applicare, perché nulla mi impedirebbe di costruire la mia CA e rilasciare certificati per altre persone. Voglio dire, se trovo un certificato emesso da qualche CA, allora posso estrarre il contenuto del certificato e metterlo in un nuovo certificato che posso firmare. Quindi posso arbitrariamente fare migliaia di nuovi certificati per qualsiasi server che desidero - e questo non è nemmeno "sbagliato" perché non sto scrivendo alcuna falsa affermazione in nessuno di questi certificati.

Corrispondentemente, CRL non sono progettati per essere un modo per pubblicare informazioni su qualsiasi elenco di "certificati attivi". Un certificato è revocato non perché non sarà più utilizzato dal proprietario , ma perché i verificatori non lo accetteranno più , che è una cosa molto diversa. Non revochi un certificato quando la chiave privata viene distrutta; la revochi quando sospetti che la chiave privata sia nelle mani sbagliate.

Che X.509 potrebbe non essere il modello esatto giusto per i server HTTPS sul Web globale è un punto valido. Questo è il succo di Convergence : sostituzione del modello X.509 (asserzioni positive che escono dalle autorità fidate) con un altro modello in cui i server hanno alcuni contestuali stato e, in particolare, non cambiare i certificati ogni cinque minuti. Con X.509, un determinato server SSL potrebbe perfettamente avere un milione di certificati validi allo stesso tempo, e usare uno scelto a caso per ciascuna connessione; La validazione X.509 è totalmente all'altezza. Ma "i normali server HTTPS non lo fanno" e Convergence prova a mungere ulteriore sicurezza dall'idea di "server normali".

Propongo un controprogetto:

Che cosa succede se non sono soddisfatto della mia attuale CA, CA-1 e mi sposto in CA-2 e chiedo loro di rilasciare un nuovo certificato per il mio sito. Se non sono più un cliente di CA-1 e si rifiuta di aggiungere il mio certificato originale al CRL, i browser dello scenario rifiutano il mio nuovo (e valido) certificato.

Inoltre ci possono essere casi in cui si utilizzano certificati su più server o load balancer. Il tuo meccanismo richiede di aggiornare tutti i dispositivi contemporaneamente (insieme al CRL).

Quello che stai proponendo è di aggiungere rilevamenti anomali molto rudimentali nei browser che prenderebbero buone decisioni nel 96% dei casi ma non sempre.

Il CRL è per i certificati che sappiamo (o sospettiamo strongmente) che sono stati compromessi, non per qualsiasi certificato che abbiamo finito ma che crediamo sia ancora sicuro. Il vero problema nel tuo scenario è che c'è una CA canaglia, non che i browser accettano due certificati diversi per lo stesso dominio allo stesso tempo. I browser dovrebbero smettere di fidarsi della CA cattiva.