it-swarm.dev

Come funziona la pinzatura OCSP?

Ho esaminato pinzatura OCSP per HTTPS, che sembra piuttosto interessante. Da quello che posso dire, è essenzialmente un modo di scaricare CRL dalla CA al server, consentendo di fare tutto in una connessione, mitigando alcuni problemi di privacy. Come funziona il processo da una prospettiva di alto livello?

Sono principalmente interessato a:

  • Dove/in che modo la pinzatura OCSP viene contrassegnata come abilitata? È qualcosa che fa la CA?
  • In che modo il server ottiene il CRL aggiornato dalla CA? Come fa a sapere quando aggiornare?
  • Cosa impedisce a qualcuno di rimuovere la bandiera "OCSP è abilitato" dall'handshake?
  • Se la connessione SSL è compromessa (ad esempio tramite BEAST o una perdita di chiave privata), si apre un'opportunità per l'attaccante di causare problemi a lungo termine manipolando il CRL?
31
Polynomial

A [~ # ~] crl [~ # ~] è un oggetto che contiene l'elenco dei numeri di serie dei certificati che sono stati revocati da una determinata CA . È un oggetto firmato; l'emittente CRL è di solito la CA stessa (con la stessa chiave) ma questo potere può essere delegato.

Una risposta OCSP è la risposta di un risponditore OCSP quando riceve una richiesta sullo stato di revoca di un certificato. Il protocollo di richiesta/risposta è specificato in RFC 256 . Le risposte stesse sono firmate dal rispondente e possono avere una vita indipendente; ciò significa che una determinata risposta OCSP può essere considerata un CRL specializzato che parla di un singolo certificato.

Durante la convalida del certificato , il verificatore (ad esempio un browser Web, durante la convalida del certificato del server) deve creare una catena di certificati, a partire da uno dei suoi trust anchor (alias certificati radice), verifica tutte le firme, i nomi e le estensioni, quindi procede con l'accertamento dello stato di revoca di ciascun certificato nella catena. Quest'ultimo passaggio prevede l'ottenimento di risposte CRL e/o OCSP, la loro convalida (il che significa verificare le firme su di esse) e leggere il loro contenuto. Ciò solleva due distinti tipi di domande:

  1. In che modo un verificatore verifica che una risposta CRL o OCSP sia autentica e aggiornata e si applichi realmente al certificato in questione?
  2. In che modo un verificatore ottiene innanzitutto la risposta CRL o OCSP?

Corrispondenza CRL/OCSP con un certificato

Concentriamoci sulla seguente impostazione: il verificatore desidera ottenere lo stato di revoca del certificato [~ # ~] t [~ # ~] (come "target"). Ha già creato e verificato una catena di certificati che termina con il certificato CA [~ # ~] c [~ # ~] seguito da [~ # ~] t [~ # ~], il che significa che la firma su [~ # ~] t [~ # ~] corrisponde alla chiave pubblica in [~ # ~] c [ ~ # ~]. Inoltre, lo stato di revoca di [~ # ~] c [~ # ~] è stato verificato e ora è [~ # ~] t [~ # ~] a cui è interessato il verificatore. [~ # ~] t [~ # ~] può essere un certificato di entità finale (ad esempio il certificato del server SSL) o un altro certificato CA come parte di una catena più lunga, che si estende oltre [~ # ~] t [~ # ~].

Un CRL è firmato; who indica che si tratta di una sottile distinzione tra X.509 e la sua interpretazione PKIX nel contesto di Internet . Per l'X.509 "originale", un CRL è valido se è firmato da un'entità che ha un certificato valido e reca lo stesso Nome distinto della CA. Funziona bene se il CRL è firmato con la stessa chiave pubblica di [~ # ~] t [~ # ~], ovvero la chiave della CA [~ # ~] c [~ # ~]: a quel punto, [~ # ~] c [~ # ~] è un certificato completamente validato, quindi la sua chiave pubblica può essere "fidata" (il verificatore è ragionevolmente sicuro che la chiave pubblica sia realmente di proprietà di un'entità che va sotto il nome indicato in [~ # ~] c [~ # ~] 's subjectDN campo). Tuttavia, potrebbe essere qualsiasi altro certificato con quel nome e situato alla fine di una propria catena valida (che può implicare più sviluppo del percorso, convalida ed elaborazione di CRL). In X.509, i nomi distinti sono tutto, perché X.509 era pensato per Directory, l'aggregato di server simile a LDAP in tutto il mondo in cui tutto è referenziato in modo univoco con il suo nome distinto.

PKIX, il gruppo di lavoro che si occupa di Internet, ha notato che la Directory, per quanto meravigliosa, condivide alcune caratteristiche con animali mitici come Mokèlé-mbèmbé , in particolare che non sembra esistere affatto (almeno, non è stato segnalato alcun avvistamento confermato). Di conseguenza, PKIX applica una limitazione per contenere i problemi: il certificato dell'emittente CRL deve trovarsi alla fine di un percorso che inizia con lo stesso ancoraggio di fiducia del percorso che termina con [~ # ~] t [~ # ~]. Ciò dovrebbe evitare problemi di trans-root quando due CA distinte che non si conoscono hanno finito per usare gli stessi nomi distinti (avrebbero potuto notare subito il problema se avessero funzionato nel contesto della Directory, se fosse esistito). Questo punto specifico è in RFC 528 , sezione 6.3.3, passaggio (f).

È possibile delegare il ruolo dell'emittente CRL, nel qual caso il nome distinto dell'emittente CRL si trova nel CRL Distribution Points extension in [~ # ~] t [~ # ~] stesso e una corrispondenza Issuing Distribution Point estensione si trova nel CRL.

Per le risposte OCSP, viene utilizzato un sistema simile. La risposta OCSP può essere firmata dalla stessa CA (con la chiave in [~ # ~] c [~ # ~]); oppure potrebbe esserci un emittente dedicato. Le cose sono più limitate lì: quando c'è un emittente dedicato, deve avere un certificato che viene emesso direttamente da [~ # ~] c [~ # ~] stesso e recante un'estensione specifica che lo contrassegna come risponditore OCSP (Extended Key Usage con il id-kp-OCSPSigning OID, vedere la sezione 4.2.2.2 di RFC 256 ). Il certificato per quel risponditore può essere allegato alla risposta OCSP stessa (al di fuori dell'area firmata, ma comunque codificato all'interno dello stesso BLOB).

Il punto importante è che non importa come sono state ottenute le risposte CRL o OCSP: sono oggetti firmati, verificando le firme e tutto il contenuto corrispondente e il contenuto dell'estensione sono sufficienti. L'oggetto stesso può viaggiare su TCP, e-mail, chiavi USB, roulotte di cammelli, apprese a memoria e declamate da un attore shakespeariano, qualunque cosa. La firma sottrae questi dettagli. Certificati, CRL, Le risposte OCSP non possono essere "manipolate" senza invalidare la firma.

Le risposte CRL e OCSP hanno date di validità . Entrambi hanno un campo thisUpdate che indica quando sono stati emessi (formalmente, la data in cui sono state raccolte le informazioni che contengono). Hanno anche un campo nextUpdate che è la data prima della quale dovrebbe essere emessa una versione più recente; quindi, serve come una specie di data di scadenza. Si prevede che i verificatori memorizzino nella cache le risposte CRL e OCSP, utilizzando queste date per sapere se la versione memorizzata nella cache è ancora utilizzabile o se è necessario ottenerne una nuova.

Come individuare le risposte CRL e OCSP

Il modo in cui viene distribuita una risposta CRL o OCSP non è importante per sicurezza, ma, naturalmente, un verificatore non può indovinare l'URL dal nulla. L'URL da cui è possibile scaricare CRL è codificato in CRL Distribution Points estensione del certificato [~ # ~] t [~ # ~] (questa estensione ha due ruoli: un ruolo di convalida per la delega del potere di emissione CRL e un ruolo descrittivo per fornire puntatori nelle posizioni in cui è possibile scaricare il CRL effettivo). http:// URL sono comuni, ma anche ldap:// URL (specialmente in ambienti chiusi come le reti aziendali). Un https:// L'URL per il download CRL può portare a un ciclo (poiché il download comporta la convalida del certificato di un altro server SSL), pertanto tenderà a non essere supportato bene o affatto (Windows non seguirà tale URL).

Allo stesso modo, l'URL in cui è possibile trovare un risponditore OCSP si trova nel Authority Information Access estensione nel certificato [~ # ~] t [~ # ~].

Questi URL sono solo indicativi; il verificatore può utilizzare qualsiasi risposta CRL o OCSP che potrebbe ottenere, indipendentemente dalla sua provenienza, a condizione che tutte le firme siano verificate. Poiché le risposte CRL e OCSP hanno una durata non trascurabile, ha senso memorizzarle nella cache e riutilizzarle. La pinzatura OCSP è un modo per un SSL server per ottenere risposte OCSP per il proprio certificato e fornirle al cliente, supponendo che il cliente possa averne bisogno. Ciò rende l'intero processo più efficiente: il client non deve aprire connessioni extra per ottenere le risposte OCSP stesso e la stessa risposta OCSP può essere inviata dal server a tutti i client entro un determinato periodo di tempo. Un modo per vederlo è che il server SSL funge da proxy Web allo scopo di scaricare le risposte OCSP.

La pinzatura OCSP dipende interamente dal server SSL; il contenuto dei certificati e le risposte OCSP non sono interessati. La CA o il risponditore OCSP non devono essere consapevoli del fatto che la pinzatura si verifica affatto.

"Rimuovere" la bandiera di pinzatura OCSP dall'handshake romperebbe i messaggi Finished alla fine dell'handshake, quindi questo non è fattibile per l'attaccante, a meno che ciò non gli consenta di interrompere l'intera stretta di mano prima della fine. Comunque, no: la mancanza di pinzatura OCSP non significa che il cliente non accerterà lo stato di revoca; significa solo che il cliente sarà da solo e dovrà ottenere le risposte CRL o OCSP da solo.

La cosa spiacevole della pinzatura OCSP è che non è ancora ampiamente supportato. L'idea è sana, però. Le sue implicazioni per la sicurezza sono che, con la pinzatura, un server SSL ha un potente argomento per convincere il browser Web a effettivamente fare il suo lavoro e non saltare del tutto i controlli sullo stato di revoca, come sfortunatamente molti browser Web sono inclini fare (le cose cambiano in quella materia, ma lentamente).

Nota: La durata della risposta CRL/OCSP di solito varia da pochi minuti a qualche giorno. Le date sono verificate rispetto alla nozione di client; i client con orologi non aggiornati possono incorrere in problemi.

38
Thomas Pornin