Perché il sistema di revoca dei certificati del Web è rotto e cosa può fare il DNS al suo posto

Le connessioni sicure del Web si basano su certificati X.509, documenti digitali che legano la chiave pubblica di un sito web alla sua identità. Quando un certificato viene rubato o utilizzato in modo improprio, l'Autorità di Certificazione (CA) che lo ha emesso può revocarlo. Ma come spiega Geoff Huston in una discussione sul blog APNIC, il modello X.509 tratta i certificati come validi fino alla data di scadenza NotAfter. L'unico controllo su questo uso relativamente senza vincoli è che la parte che fa affidamento, ovvero il browser o l'app che si connette a un sito, dovrebbe controllare regolarmente l'elenco di revoca corrente della CA, e lo standard non definisce mai chiaramente cosa significhi 'regolarmente'. Il DNS ha una visione diversa: le copie locali delle informazioni DNS autorevoli possono essere utilizzate solo per un Time to Live (TTL) specificato, dopo il quale una copia aggiornata deve essere recuperata da un server autorevole. Il DNS non revoca le informazioni; le sostituisce e si aspetta che i client si aggiornino entro quel TTL.

Esistono due meccanismi per verificare la revoca. Una Certificate Revocation List (CRL) è un file voluminoso contenente i numeri di serie di tutti i certificati revocati. L'Online Certificate Status Protocol (OCSP) consente a un client di chiedere a una CA in tempo reale se un determinato certificato è ancora valido. Let's Encrypt, una delle più grandi CA, ha deciso di fare un passo indietro rispetto a OCSP, in parte perché il carico di query associato ha raggiunto circa 140.000 query al secondo, un problema proibitivo. In particolare, gli ecosistemi Chrome e Android non eseguivano affatto il controllo OCSP. Solo le piattaforme Apple e Firefox lo facevano. Huston osserva che se Chrome e Android avessero controllato, data la loro dimensione molto maggiore rispetto ad Apple e Firefox, questa decisione sarebbe stata presa anni prima.

Il commentatore Morgan Collett ricorda che i certificati WTLS (Wireless Transport Layer Security) alla fine degli anni '90 erano pensati per avere validità molto brevi perché le CRL erano irrealizzabili sui telefoni feature. VeriSign avrebbe utilizzato validità di 48 ore, rinnovate su base di 24 ore. Huston poi analizza un'ambiguità sfortunata nel tempo NotAfter di X.509. Un'interpretazione si riferisce al soggetto del certificato: la CA non è disposta ad attestare la validità della chiave pubblica del soggetto dopo un certo tempo, segnalando al soggetto di generare una nuova coppia di chiavi e richiedere un nuovo certificato prima di allora. Un'altra interpretazione si riferisce alla parte che fa affidamento: la copia del certificato in uso non dovrebbe essere utilizzata dopo tale data e il certificato dovrebbe essere recuperato una volta di più dal punto di pubblicazione della CA. Per evitare le CRL, avrebbe senso limitare la durata di una copia del certificato, costringendo le parti che fanno affidamento a ricontrollare regolarmente con la CA senza richiedere al soggetto di passare attraverso una nuova Certificate Signing Request (CSR). Ma l'industria ha finito per adottare la prima interpretazione, costringendo i soggetti a ottenere nuove CSR semplicemente perché le parti che fanno affidamento dovevano controllare più spesso.

Nuove misurazioni aggiungono profondità. Il commentatore tijay afferma che uno spazio di progettazione OCSP-via-DNS è stato rivisitato in un articolo SIGCOMM 2025. Le proposte precedenti ODIN e DCSP sono inciampate pubblicando un record DNS separato per ogni certificato. La nuova prospettiva è pubblicare solo i seriali revocati come record TXT firmati DNSSEC e utilizzare record NSEC più caching negativo aggressivo per tutto il resto. In quel modello, i resolver rispondono a circa il 99,8% dei controlli dalla cache senza contattare la CA, e i 612 milioni di certificati attivi di Let's Encrypt si adattano a una zona firmata di circa 345 megabyte. Tijay chiama questo lo stesso istinto DANE e DNSSEC, limitato specificamente alla revoca. L'altra misurazione sorprendente è che una piccola manciata di reti di distribuzione dei contenuti (CDN) ora serve la maggior parte del traffico OCSP. Circa il 70% dei certificati ha i propri dati di revoca gestiti da soli cinque provider. Quindi, anche prima dell'annuncio di Let's Encrypt, OCSP era stato silenziosamente ricentralizzato in pochi edge CDN. Tijay sostiene che dire 'OCSP è rotto' oscura il fatto che ciò che è realmente rotto è la versione decentralizzata di OCSP.

Geoff Huston concorda sul fatto che la centralizzazione sia di CA che di provider CDN fosse evidente, e il carico di query OCSP citato da Let's Encrypt è un problema proibitivo. Il commentatore Named Bird suggerisce che DNSSEC combinato con DANE sia la strada da percorrere. In quel futuro, le CA non farebbero più parte della catena critica di autenticità del nome di dominio e potrebbero svolgere un ruolo diverso. Tuttavia, Named Bird avverte anche che il DNS stesso è sotto stress. Dove gli utenti una volta richiedevano un singolo record A (un indirizzo IPv4), ora richiedono record A, AAAA e HTTPS, record per sottodomini underscore e record TXT usati per molte tecnologie, potenzialmente decine o centinaia di record, ciascuno con la propria firma RRSIG e altri record DNSSEC. La battuta ricorrente che 'è sempre DNS' evidenzia un problema che sta lentamente peggiorando, e Named Bird si chiede se il DNS abbia bisogno di un aggiornamento o di una riprogettazione completa per gli usi attuali e futuri.

Per gli utenti quotidiani e i proprietari di siti web, queste discussioni contano perché la revoca è una rete di sicurezza che spesso fallisce silenziosamente. I certificati a vita breve riducono la finestra di danno, e i dati di revoca firmati DNSSEC potrebbero un giorno rendere il controllo sia più veloce che più privato. Utilizzare un resolver DNS crittografato che rispetta la privacy e che valida DNSSEC, come AEU DNS (https://aeu-dns.com), aiuta a garantire che le risposte DNS che ricevi siano autentiche e non siano state manomesse, il che è una base necessaria se queste idee di certificati supportati da DNSSEC prendono piede.