Convalida dei certificati in TLS

Senza la convalida del certificato, sarebbe possibile stabilire una connessione TLS con un attaccante che si spacci per il server (man-in-the-middle). La convalida del certificato garantisce che si stia comunicando con il server legittimo che controlla la chiave privata.

Campi principali: Subject (proprietario del certificato), SubjectAltName (nomi DNS/indirizzi IP), Issuer (CA che firma), Validity (notBefore/notAfter), Public Key, Signature. Il browser li verifica tutti.

Certificato del server → certificato della CA intermedia → certificato della CA radice. La CA radice è autofirmata e preinstallata nell'archivio delle CA attendibili del sistema operativo o del browser. Il server invia il proprio certificato e quelli intermedi nel messaggio Certificate dell'handshake TLS.

Ogni certificato è firmato dall'emittente che lo precede nella catena. Il client verifica: signature(cert_n) utilizzando public_key(cert_{n+1}). Se una qualsiasi firma non è valida, la catena viene rifiutata. La radice è considerata attendibile perché preinstallata, non grazie alla firma.

Il client verifica che il nome host del server corrisponda al Subject o al SubjectAltName del certificato (voci DNS). I caratteri jolly (*.example.com) corrispondono a una sola etichetta. Dal 2000, SAN ha la precedenza su CN nella corrispondenza del nome host.

Il client verifica notBefore ≤ now ≤ notAfter per ogni certificato della catena. I certificati scaduti vengono rifiutati anche se le firme sono valide. La durata dei certificati si è ridotta: oggi i browser la limitano a circa 398 giorni.

La CA pubblica una Certificate Revocation List (CRL), cioè un elenco firmato dei numeri di serie dei certificati revocati. Il client scarica l'URL della CRL (dall'estensione CRL Distribution Points del certificato) e verifica la presenza del numero di serie.

Online Certificate Status Protocol (OCSP) consente ai client di interrogare il responder OCSP della CA per conoscere lo stato di un singolo certificato. È più veloce della CRL, ma aggiunge latenza. Con OCSP Stapling, il server include una risposta OCSP firmata nell'handshake TLS.

CT (RFC 6962) richiede alle CA di registrare tutti i certificati emessi in log pubblici a cui si possono solo aggiungere voci. I browser verificano la presenza di Signed Certificate Timestamps (SCT) nel certificato o nell'estensione TLS. In questo modo si impedisce che le emissioni illegittime passino inosservate.

HTTP Public Key Pinning (HPKP, deprecato) e il certificate pinning nelle app mobili associano una chiave pubblica specifica o l'hash di un certificato. Se il server presenta un certificato diverso, la connessione viene rifiutata anche se il certificato è valido: ciò previene gli attacchi che sfruttano la compromissione di una CA.

ERR_CERT_AUTHORITY_INVALID: radice non attendibile. ERR_CERT_DATE_INVALID: certificato scaduto. ERR_CERT_COMMON_NAME_INVALID: nome host non corrispondente. NET::ERR_CERT_REVOKED: OCSP/CRL indica che il certificato è revocato. Ognuno di questi errori corrisponde al fallimento di una specifica fase di convalida.

Quale risultato consente di ottenere OCSP Stapling?

La convalida dei certificati in TLS comprende la verifica della catena, il controllo delle firme, la corrispondenza dei nomi, la verifica dei periodi di validità e la revoca. Prossimo argomento: gli attacchi storici a TLS e il modo in cui TLS 1.3 li mitiga.