CA di emissione compromessa

Hai indovinato: la revoca è asincrona . Quando revochi un certificato, questo diventa veramente efficace solo quando scade l'ultimo CRL pre-revoca. Se emetti CRL valide per un anno, un certificato revocato può ancora essere considerato attendibile da altri sistemi fino a un anno.

Si dovrebbe prevedere CRL come caratteristica contenimento del danno : con CRL, si può avere un limite esplicito sulla durata del compromesso che avrà un impatto sui sistemi. Il CRL a vita lunga è più facile da pubblicare (poiché lo fai meno spesso), ma di conseguenza impiega più tempo a contenere il danno. Questo è un compromesso.

L'unica soluzione, nel contesto di una PKI X.509, è di pubblicare CRL più spesso, con una vita più breve. Tuttavia, poiché la CA principale è offline (e, a parità di tutte le altre condizioni, un'ottima idea), l'emissione di un CRL implica un'operazione manuale, quindi costi. Sono a conoscenza di due soluzioni alternative:

1. Potresti creare un CRL indiretto : mentre la CA principale non è in linea, il potere di firmare un CRL potrebbe essere affidato a un sistema online distinto con una propria coppia di chiavi. X.509 supporta questo, con estensioni pertinenti (vedi questa risposta ). Sfortunatamente, i CRL indiretti non sono ben supportati dal software esistente.

2. Si potrebbe rendere la CA radice parzialmente online. In una configurazione che ho contribuito a sviluppare ed è attualmente distribuita in produzione, la CA radice "offline" produce un CRL su base settimanale e lo invia su ... il suo output audio. L'idea è che la spina "line out" sia fisicamente a senso unico, quindi anche se c'è un cavo che va da quella spina alla presa "line in" di un'altra macchina (online), la CA radice può ancora essere considerata come "disconnesso". Inoltre, un'ispezione visiva può facilmente notare che il filo è nella spina destra (quella verde).

   Questa soluzione richiede alcuni software per codificare il nuovo CRL come suono e decodificarlo dall'altra parte; il semplice codice che ho scritto offriva prestazioni pessime (circa 300 bit / s), ma era molto robusto e il CRL settimanale è molto breve (dato che, in condizioni normali, è completamente vuoto). Poiché non vi è alcun riconoscimento (il collegamento è veramente a senso unico), il mittente deve inviare ripetutamente lo stesso file, ancora e ancora, con un'intestazione riconoscibile per la sincronizzazione e un checksum per il rilevamento degli errori (per un CRL, è possibile verificare il firma, che è buono come qualsiasi checksum può ottenere). In questo modo, puoi avere una CA root offline e continuare a ricevere la pubblicazione CRL automatizzata su base settimanale (potrebbe persino essere giornaliera).

   (Il mio progetto iniziale prevedeva un altoparlante e un microfono effettivi, ma questo potrebbe rivelarsi problematico in un ambiente rumoroso e le sale server sono molto rumorose.Le persone con alcune competenze elettroniche potrebbero costruire un circuito con un LED e un fotorilevatore. un altro modo è utilizzare un cavo ethernet a doppino intrecciato con un solo paio collegato, ma questo potrebbe non funzionare con le interfacce ethernet che cercano di effettuare il rilevamento medio ed è più difficile da controllare visivamente, dal momento che devi scollegare il cavo per controllare il cablaggio.)

Sì, la macchina può fidarsi del certificato della CA di emissione fino a novembre 2016. Esistono alcune "soluzioni" in uso - in particolare nei browser Web - quando esiste un certificato che deve essere "revocato":

• Avvia una nuova versione del browser che include la revoca. Davvero inefficiente, ma funziona.

• Chrome inserisce gli elenchi di revoca ( crlsets ) separatamente attraverso il loro canale di aggiornamento.

• OCSP fornisce un modo per verificare online che il certificato non è stato revocato. In questo modo, è sufficiente inviare la revoca al server che gestisce l'OCSP. Il problema è che il server OCSP diventa un singolo punto di errore, poiché è necessario considerare il certificato non valido se non riceve una risposta OCSP. Se si verifica un errore soft, un MITM deve solo bloccare il controllo OCSP (che, dato che sono MITM, possono farlo spesso) e la connessione avrà esito positivo. Vedi [1]

Un modello di convalida basato su CA ha esito negativo poiché non è in grado di eseguire la revoca di se stesso; non c'è flessibilità di fiducia quando una CA radice viene compromessa, poiché è necessario sostituire l'ancoraggio di fiducia. Se si tratta semplicemente di una CA di emissione anziché di una radice, l'evento di revoca può avere esito positivo. Tuttavia, esaminiamo gli approcci di base alla convalida:

• Elenchi di revoca certificati - una lista nera di certificati revocati distribuito come un file. I CRL di grandi dimensioni sono difficili da consumare e causare problemi di prestazione.

• OCSP senza Nce: una risposta ripetibile può essere prodotta in serie e cache. Piccolo, veloce ed efficiente.

• OCSP con Nonce - una richiesta e una risposta OCSP che include a nonce crittografico; OCSP non forzato è sempre attivo. Piccolo, veloce, ma introducendo un po 'più di un successo nelle prestazioni rispetto a un OCSP vaniglia richiesta / risposta.

OCSP in precedenza era più orientato ad essere una versione live di CRL, una lista nera. Tuttavia, le più recenti RFC per OCSP consentono anche l'uso di OCSP come whitelist. Gli approcci di blacklist e whitelist combinati per la convalida sono molto più sicuri.

Quando pensi alla convalida, tieni presente che puoi e dovresti prendere in considerazione altre alternative ai modelli di fiducia basati su CA, in particolare per reti o reti più grandi in cui è necessaria la possibilità di compromissione della CA o flessibilità.

Se viene data la possibilità di scegliere tra CRL di produzione, OCSP o entrambi, ho sempre in programma di utilizzare entrambi i modelli, con preferenza data all'OCSP con fail-closed, integrato da CRL. In generale, preferisco gli schemi di convalida basati su VA, poiché hanno la possibilità di revocare le CA compromesse.

Ora che ho scritto tutto questo, risponderò alle tue domande

La convalida basata su CRL dovrebbe quasi sempre essere meno preferita della convalida basata su OCSP

I CRL possono essere eliminati da un prodotto IT, ad es. su Windows

certutil -setreg chain\ChainCacheResyncFiletime @now