La pubblicazione di CRL su HTTP è una potenziale vulnerabilità?

Non esiste un CRL non firmato; il campo firma è obbligatorio e qualsiasi sistema che utilizza il CRL verificherà la firma.

In puro X.509 , un CRL sarà considerato "accettabile" come fonte di informazioni sullo stato di revoca di un determinato certificato E se è firmato da un "emittente di revoca consentito": la firma del CRL deve corrispondere alla chiave pubblica contenuta in un certificato già validato, il cui subjectDN è uguale a issuerDN di E (puoi avere un DN distinto se E contiene l'estensione del punto di distribuzione CRL e l'CRL ha un'estensione del punto di distribuzione Emittente corrispondente; ma dimentichiamo questa ulteriore complessità). Le regole complete sono esposte nella sezione 6.3 . Si noti che "puro X.509" dovrebbe funzionare nel contesto della Directory, il tipo di server LDAP mondiale che fa riferimento a tutto sotto nomi distinti non ambigui.

Poiché la Directory non funziona davvero, perché non esiste affatto, le implementazioni esistenti tendono ad implementare regole più stringenti e più semplici. In generale, un browser Web che convalida un problema di E certificato da CA C accetterà un CRL solo se è firmato anche dalla stessa CA, con la stessa chiave. Questa regola mantiene la convalida del percorso semplice e limitata (altrimenti, è possibile immaginare una situazione in cui è necessario ottenere un CRL per ciascun certificato nel percorso e ogni CRL deve essere verificato con un altro certificato emittente CRL che richiede la propria convalida del percorso, quindi sopra). Pertanto, è improbabile che produrre il proprio CRL relativamente alla propria CA radice abbia alcun effetto effettivo.

CRL, come i certificati, sono quindi oggetti che sono sempre firmati e mai utilizzati senza verificare la firma (*), in modo che possano essere pubblicati su un semplice HTTP. Usare HTTPS per servire CRL è solo risorse sprecate; potrebbe addirittura impedire il download di CRL perché alcune implementazioni (ad es. Windows) si rifiutano di seguire l'URL HTTPS durante la convalida dei certificati (sia per CRL, OCSP, o download CA intermedio extra), perché ciò significherebbe SSL, quindi un altro certificato da convalidare, e possibilmente un ciclo infinito.

^{(*) I qui esclude i "certificati" CA di origine, tradizionalmente autofirmati; questi non sono certificati real nel senso X.509, ma solo oggetti che imitano le regole di codifica dei certificati.}

Informazioni sull'attacco di riproduzione, il CRL ha una data e ora con la data di generazione e un data per il prossimo aggiornamento . La data del prossimo aggiornamento è obbligatoria nel profilo PKIX. Se un certificato viene revocato, il vecchio CRL può essere riprodotto prima di nextUpdate se viene utilizzato un canale non protetto .

Vorrei solo aggiungere che alcuni (almeno) browser Mozilla hanno una variabile di configurazione: security.OCSP.require (vedi IRL su: config) che, per impostazione predefinita, è impostato su false.

Sembra che se security.OCSP.require è impostato su "false", il browser dovrebbe tornare a verificare il CRL nell'URI del punto di distribuzione CRL denominato, che coincide con lo stesso URI utilizzato nel campo di accesso alle informazioni dell'autorità dove presumibilmente si troverebbe la firma della CA e del CRL.

Empiricamente (almeno in Linux) se questo URL è bloccato, almeno i browser Mozilla (Firefox, Sea Monkey, Chrome) passeranno il certificato senza verifica se è stato revocato e sostituito.

Ho difficoltà a capire come questa non sarebbe una vulnerabilità, ma non era il punto cruciale della domanda originale.

Nota: in Windows, le impostazioni CRL e OCSP sembrano essere una funzione di Criteri di gruppo (Criteri del computer locale, Configurazione del computer, Impostazioni di Windows, Impostazioni di sicurezza, Criteri chiave pubblica) e possono essere configurate, ma almeno a Windows 2003 non sembra essere configurato per impostazione predefinita. Su Mac, questo potrebbe essere ulteriormente mitigato da Keychain, per coloro che sono inclini a fidarsi di una terza parte con le loro password ....