OCSP contro una CRL: come funziona davvero ogni controllo di revoca

Uno di questi due controlli di revoca restituisce una risposta firmata su un solo certificato, e l’altro restituisce una lista firmata che si scarica per intero. Entrambi devono dire a un verificatore se una credenziale è ancora attendibile, ed entrambi falliscono in modi che non si somigliano affatto. L’ordine che segue è quello che un operatore incontra davvero in produzione, a partire dai byte sul cavo e finendo con un gateway che rifiuta una connessione. Saltare un passaggio è il modo in cui una distribuzione finisce con una politica di revoca che esiste solo sulla carta.

Passo 1: che cosa restituisce ogni controllo e per quanto tempo resta utilizzabile

Una CRL viene pubblicata come un unico oggetto firmato che copre ogni certificato revocato da un emittente, così un verificatore la preleva una volta e la riusa finché il nextUpdate della lista non è passato. Una risposta OCSP è più stretta: risponde esattamente per un certificato e porta thisUpdate, producedAt e di solito anche nextUpdate. Questa differenza governa tutto il resto. Una CRL in cache invecchia in silenzio, perché il file viene ancora analizzato e la sua firma ancora verificata, mentre una risposta OCSP scaduta è ovviamente inutile nel momento in cui se ne leggono i timestamp.

La cache è quindi la prima cosa da fissare: quale componente tiene la copia e a quale tetto quella copia obbedisce. Su un gateway il tetto dovrebbe essere nextUpdate meno un margine di sicurezza, mai quello che suggerisce per caso un’intestazione di cache HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate stampa entrambe le date, e una lista il cui nextUpdate è già nel passato va trattata come mancante e non solo come vecchia.

Passo 2: dove il certificato indirizza il client

Il certificato foglia di solito porta due indizi: un’estensione di punto di distribuzione CRL e una voce di accesso alle informazioni dell’autorità per OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints stampa il primo, e il secondo si trova nella sezione AIA di openssl x509 -in client.pem -noout -text. Ciascuna delle estensioni è un puntatore, non un obbligo. Un client che non implementa mai il controllo di revoca si connetterà benissimo a un certificato le cui estensioni nominano un risponditore morto da un anno.

I punti di distribuzione spesso nominano un host interno che si risolve solo all’interno di un segmento di rete, e alcuni client più vecchi rifiutano del tutto gli URL ldap. Verificate la raggiungibilità dall’host che termina il tunnel, non dal vostro portatile, perché è l’unico punto di vista il cui fallimento conta davvero.

Passo 3: scegliete fail-closed o fail-open prima dell’interruzione

Un risponditore irraggiungibile o una lista scaduta impongono una decisione: rifiutare la connessione, oppure accettarla e registrare la lacuna. Il sottocomando verify di OpenSSL rende esplicita la scelta rigorosa, perché aggiungere -crl_check trasforma una CRL non disponibile in unable to get certificate CRL e in una verifica fallita. Il soft-fail nella maggior parte degli stack non è affatto un flag, è l’assenza del controllo, ed è esattamente per questo che arriva per caso.

Per vedere quale comportamento ha davvero un client, togliete il risponditore e riconnettetevi. Se il tunnel si alza lo stesso, trovate la riga di log che ha registrato il controllo saltato, poi chiedetevi se qualcuno leggerebbe quella riga durante un incidente. Lo stesso fornitore può differire per protocollo, con un client IKEv2 e un client OpenVPN sulla stessa macchina che leggono impostazioni non correlate.

Passo 4: dimostrate che il controllo viene eseguito dove il traffico è ammesso

Trovate il processo che termina o autorizza la connessione, poi chiedetegli la riga di configurazione che abilita il controllo di revoca. Un gateway che valida la catena ma non chiede mai della revoca applica una politica diversa da quella nella vostra documentazione, e nessuno screenshot di una catena di certificati dimostra il contrario. OpenVPN scrive l’opzione come crl-verify; strongSwan tiene le ricerche CRL e OCSP sotto la configurazione della CA, dove si impostano crl_uris o ocsp_uris. Se non potete indicare né l’una né l’altra, supponete che il controllo sia assente.

Una risposta OCSP conta solo quando l’ha firmata la CA emittente, o quando l’ha firmata un risponditore che detiene l’uso esteso della chiave OCSPSigning delegato da quella CA, quindi una risposta di un servizio non correlato non dimostra nulla. Se gestite voi il risponditore, monitoratelo come dipendenza rigida, perché un solo servizio morto diventa un’interruzione per ogni client fail-closed insieme.

Passo 5: revocate un certificato di proposito

Prendete un certificato di prova, revocatelo attraverso lo stesso canale usato dalla produzione e interrogate direttamente il risponditore. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text dovrebbe riportare Cert Status: revoked insieme a un orario di revoca, e una risposta good significa che la vostra revoca non ha raggiunto il risponditore interrogato dai vostri client. Poi eseguite openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem per vedere la stessa decisione attraverso il percorso della lista. Leggete la stringa del motivo invece del codice di uscita, perché un rifiuto per revoca e un errore di catena finiscono entrambi in un fallimento.

Il passo che conta davvero è l’ultimo: riconnettetevi con il vecchio profilo contro il punto di applicazione reale e confermate che il rifiuto viene dalla revoca. Poi riconnettetevi con un certificato nuovo e valido per dimostrare che non avete solo rotto l’ascoltatore. Eliminare il profilo sul client non dimostra nulla sulla decisione del server, e nemmeno un’esecuzione riuscita di openssl verify su una macchina che non termina mai un tunnel. RFC 6960 definisce che cosa contiene una risposta OCSP conforme, compresi i valori di stato che questo test legge.