OCSP, CRLs, crlset - Consegna e attacchi di revoca

Question

OCSP, CRLs, crlset - Consegna e attacchi di revoca

#1 da (0 voti)

1

Le risposte OCSP hanno un campo "nextUpdate", che è il tempo previsto per il nuovo aggiornamento di revoca e che la revoca corrente può essere considerata valida. Le revocazioni possono essere memorizzate nella cache dai server cert intermedi, che ho visto usati nei progetti che forniscono risposte graffate. Ho letto che le revoche vengono consegnate immediatamente dalla CA principale alla CA intermedia.

In questo caso, cosa succederebbe se ci fosse un attacco DoS al server CA radice, quindi è stato impedito di consegnare la revoca? Ciò potrebbe esporre una finestra di opportunità, utilizzando la voce di revoca memorizzata nella cache del server intermedio, che suggerirebbe erroneamente al client di un utente finale che un certificato di sito Web è valido, quando può essere non valido. Il client o il browser dell'utente potrebbero interagire con un sito dannoso fino a quando il DoS non viene arrestato, viene effettuata una chiamata a tutti i server intermedi, ecc. Fino a 7 giorni.

Ci sono stati almeno tre attacchi DoS sui server dei nomi radice della durata di almeno un'ora, tuttavia non sono sicuro di come influenzerebbero la capacità di un server CA di inviare traffico in uscita. Forse hanno canali secondari per ottenere l'elenco di revoche.

Qualcuno ha ulteriori informazioni sugli aspetti tecnici di questo e sulla possibilità che questo tipo di attacco si verifichi? Inoltre, sono curioso che qualcuno conosca l'infrastruttura di memorizzazione nella cache per i CRL e la tempistica per aspettarsi che venga visualizzata una revoca in una tipica CA intermedia?

Chrome utilizza il proprio metodo proprietario per la scansione di CRL e Google li spinge al browser in blocchi, chiamati crlset. A prima vista, OCSP ha un vantaggio temporale migliore rispetto a crlset, perché contatta direttamente i risponditori autorizzati per ottenere lo stato delle revoche, tuttavia dopo aver scoperto che alcuni provider hanno implementato periodi di aggiornamento della cache CRL definiti in modo variabile, non sono sicuro che sia effettivamente migliore. Google sostiene che il loro elenco di revoche viene aggiornato quotidianamente e questo è più frequente di altre soluzioni.

Qualcuno conosce i compromessi in fatto di sicurezza tra OCSP e il metodo crlset di Google? In particolare, quali sono i tempi e l'affidabilità migliori per ottenere la risposta alla revoca? La rivendicazione di Google è supportata da prove?

public-key-infrastructure certificates certificate-authority certificate-revocation ocsp

posta Nick 27.09.2018 - 08:10

fonte

1 risposta

Leggi altre domande sui tag public-key-infrastructure certificates certificate-authority certificate-revocation ocsp

Come disabilitare i ticket di sessione TLS in Chrome? OWASP ZAP non esegue la scansione di tutti gli URL in Jenkins

score 0 · Answer 1

Ho fatto una domanda su CRL e OCSP ieri e poi ho letto su di esso e io per primo sono giunto alla conclusione che al momento non esiste una soluzione "perfetta".

In un sistema perfetto il browser dovrebbe verificare lo stato di revoca presso la stessa CA almeno una volta ogni sessione, ma per far funzionare tutto ciò che CA avrebbe bisogno di creare enormi cluster di server con grandi connessioni ridondanti in tutto il mondo per garantire tempi di risposta minimi .

Perché non è fattibile (non ci si può aspettare che ogni CA crei un'infrastruttura così grande) La pinzatura OCSP è stata creata in primo luogo con gli svantaggi che hai indicato.

Il crlset di Google è fondamentalmente una via di mezzo, funge da cache CRL. Il vantaggio è che Google dispone di un'infrastruttura server enorme che è meno soggetta agli attacchi DoS, quindi in teoria questa è una buona cosa. Il rovescio della medaglia è che sei dipendente da Google con tutti i problemi di privacy e altri problemi che ne derivano.

A mio parere, i certificati dovrebbero includere un campo booleano "controllo di revoca obbligatorio su ogni richiesta" che costringe il cliente ad aggiornare lo stato di revoca su ogni richiesta. Quindi, fondamentalmente infrastrutture critiche e applicazioni ad alta sicurezza come i siti bancari applicano sempre uno stato di revoca aggiornato all'inizio di ogni sessione e siti meno critici non lo fanno e optano per usabilità invece di (più) sicurezza. Inoltre, gli utenti dovrebbero avere la possibilità di impostarlo individualmente per ogni sito (proprio come le opzioni dei cookie, ecc.) A meno che non sia applicato dal server (quindi disattivarlo quando il server lo impone non dovrebbe essere possibile).

Questa è una questione tanto più politica che tecnica, serve una regolamentazione per ottenere qualcosa di simile.

Ma poi di nuovo, il vettore di attacco per questo scenario è piuttosto sottile in realtà se ci pensate. Perché in pratica devi prima attaccare il server e corrompere il certificato (che dovrebbe essere molto improbabile per applicazioni ad alta sicurezza) E fare simultaneamente la CA radice con un attacco enorme, quindi niente viene fuori e quindi usare quella piccola finestra per eseguire il tuo attacco, questo è molto, molto improbabile e può essere migitato ancora di più se il periodo del prossimo aggiornamento fosse ancora più piccolo (che dovrebbe essere in ambienti ad alta sicurezza).

Quindi è anche una questione di "Chi è responsabile per l'integrità di un server?" perché quando qualcuno ottiene la chiave privata del tuo server, lo stato di revoca del tuo certificato non è esattamente il problema più grande che hai ma qualcuno che ha accesso root al tuo server (o peggio ancora ottiene la chiave senza accesso root).