Passa al contenuto principale

8. Richiesta di stato del certificato

La verifica dello stato di revoca di un certificato può richiedere che il client contatti una terza parte come un'autorità di certificazione (CA) o un risponditore del Protocollo di Stato del Certificato Online (OCSP). Per i client soggetti a vincoli di larghezza di banda, ciò può rappresentare un costo significativo. L'estensione "status_request" consente ai client di richiedere al server TLS di ottenere lo stato del certificato per conto del client.

8.1. Messaggi Hello​

I client che richiedono lo stato del certificato DEVONO includere un'estensione di tipo "status_request" nel client hello (esteso). Il campo "extension_data" di questa estensione contiene "CertificateStatusRequest" dove:

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPStatusRequest;
    } request;
} CertificateStatusRequest;

enum { ocsp(1), (255) } CertificateStatusType;

struct {
    ResponderID responder_id_list<0..2^16-1>;
    Extensions request_extensions;
} OCSPStatusRequest;

opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;

Nell'OCSPStatusRequest, i campi "responder_id_list" e "request_extensions" sono strutture codificate DER [X690] di un ResponderID e di Extensions, rispettivamente, come definito in [RFC2560]. "Extensions" è importato da [RFC5280]. Un "ResponderID" codificato DER di lunghezza zero significa che il risponditore è implicito dal certificato in questione. "Extensions" di lunghezza zero significa che non ci sono estensioni.

Sia "ResponderID" che "Extensions" sono strutture codificate DER nel campo OCSPStatusRequest definito sopra. Per chiarezza, ecco un esempio di codifica DER per un ResponderID:

ResponderID ::= CHOICE {
   byName               [1] Name,
   byKey                [2] KeyHash }

KeyHash ::= OCTET STRING -- hash SHA-1 della chiave pubblica del risponditore
                          -- (cioè, l'hash SHA-1 del valore della
                          -- BIT STRING subjectPublicKey [escludendo
                          -- il tag, la lunghezza e il numero di bit
                          -- non utilizzati] nel certificato del risponditore)

La codifica DER del ResponderID viene quindi posizionata in un vettore opaco nel campo responder_id_list.

I server che ricevono un'estensione client hello "status_request" POSSONO restituire un'estensione server hello "status_request" appropriata se il server sceglie di restituire lo stato del certificato nell'handshake. Se un server restituisce un'estensione "status_request" nel server hello, allora il server DEVE aver incluso un'estensione di tipo "status_request" con un elemento "extension_data" vuoto. Il server ha diverse scelte per restituire le informazioni sullo stato del certificato:

  • Può richiedere lo stato del certificato e restituirlo nel messaggio CertificateStatus (esteso) come descritto nella Sezione 8.2.

  • Può scegliere di non richiedere lo stato del certificato e non includere un'estensione "status_request" nel server hello.

  • Può scegliere di non richiedere lo stato del certificato anche se ha incluso l'estensione "status_request" nel server hello. In questo caso, il server non restituisce il messaggio CertificateStatus (esteso).

Nel caso in cui il server scelga di non restituire lo stato del certificato nell'handshake, il client PUÒ scegliere di richiedere direttamente lo stato del certificato a un risponditore OCSP esterno.

8.2. Stato del certificato​

Il server PUÒ restituire un messaggio "CertificateStatus" nell'handshake TLS se il client ha richiesto uno stato del certificato includendo un'estensione "status_request" nel client hello. Se il server sceglie di inviare un CertificateStatus, questo messaggio DEVE essere inviato immediatamente dopo il messaggio Certificate (e prima di qualsiasi messaggio ServerKeyExchange o CertificateRequest, se applicabile).

La struttura del messaggio CertificateStatus è:

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPResponse;
    } response;
} CertificateStatus;

opaque OCSPResponse<1..2^24-1>;

Un "OCSPResponse" contiene una struttura OCSPResponse completa codificata DER (come definita in [RFC2560]). Solo una risposta OCSP PUÒ essere inviata.

Il "CertificateStatus" DEVE contenere una risposta OCSP con un valore OCSPResponseStatus di "successful" (0).

Il server DEVE inviare il messaggio "CertificateStatus" se:

  • Riceve un'estensione "status_request" valida nel client hello e sceglie di onorare la richiesta, E
  • Ottiene una risposta OCSP valida per il suo certificato.

Se una risposta OCSP valida non è disponibile, il server NON DOVREBBE inviare il messaggio "CertificateStatus".

Il client che richiede uno stato del certificato DEVE verificare la risposta OCSP se ne riceve una. Se la risposta OCSP non è soddisfacente, il client PUÒ decidere di abortire l'handshake. Le considerazioni che il client utilizza per determinare se la risposta OCSP è soddisfacente sono al di fuori dell'ambito di questo documento. Il client NON DEVE trattare un'assenza di risposta OCSP (cioè, che il server non ha inviato un messaggio CertificateStatus) come il significato di un fallimento della richiesta di stato, e DOVREBBE continuare l'handshake normalmente in questo caso.

8.3. Implicazioni per la memorizzazione nella cache delle risposte OCSP​

I server che implementano questa estensione DOVREBBERO memorizzare nella cache le risposte OCSP per i certificati che utilizzano. Il server DOVREBBE anche ottenere regolarmente (prima della scadenza di thisUpdate o nextUpdate) nuove risposte OCSP per mantenere la freschezza delle informazioni sullo stato.

I server POSSONO mantenere una cache di risposte OCSP aggregate per gestire efficacemente più certificati. In questo caso, il server deve assicurarsi che le risposte OCSP siano fresche e corrispondenti al certificato del server.

Un server che non può ottenere o aggiornare una risposta OCSP in modo tempestivo PUÒ continuare a utilizzare una risposta OCSP scaduta fino a quando una nuova risposta è disponibile. Tuttavia, DOVREBBE cercare di ottenere una nuova risposta OCSP il prima possibile.

8.4. Considerazioni sulla sicurezza per la richiesta di stato del certificato​

L'estensione "status_request" consente a un client di richiedere al server di fornire informazioni sullo stato del certificato (generalmente tramite OCSP) durante l'handshake TLS. Ciò ha importanti implicazioni sulla sicurezza:

Vantaggi per la sicurezza:

  • Privacy migliorata: Il client non deve contattare direttamente un risponditore OCSP, il che impedisce al risponditore OCSP di tracciare le attività del client.

  • Prestazioni: Riduce la latenza della connessione evitando un round-trip aggiuntivo a un risponditore OCSP esterno.

  • Affidabilità: Il server può memorizzare nella cache le risposte OCSP, rendendo il servizio più affidabile anche se il risponditore OCSP è temporaneamente non disponibile.

Rischi per la sicurezza:

  • Freschezza delle risposte OCSP: Il server può servire risposte OCSP obsolete. I client devono verificare i campi thisUpdate e nextUpdate nella risposta OCSP.

  • Risposte OCSP falsificate: Un server compromesso potrebbe fornire false risposte OCSP. I client DEVONO verificare la firma della risposta OCSP.

  • Attacchi denial-of-service: Un server potrebbe intenzionalmente non fornire una risposta OCSP per un certificato revocato. I client DOVREBBERO avere una politica di fallback (ad esempio, contattare direttamente il risponditore OCSP o rifiutare la connessione).

  • Privacy del server: Il server rivela l'identità del risponditore OCSP che utilizza, il che potrebbe rivelare informazioni sull'infrastruttura del server.

I client che implementano questa estensione DEVONO eseguire una validazione completa della risposta OCSP, inclusa la verifica della firma, la verifica che il risponditore sia autorizzato e la verifica che la risposta sia fresca secondo la politica del client.

Ultimo aggiornamento il