Il 5 giugno 2013 The Guardian pubblica il primo articolo tratto dai documenti consegnati da Edward Snowden, e nei tre anni successivi la comunità che standardizza i protocolli di Internet cambia un’assunzione di fondo: che la rete intermedia sia un canale passivo e non un avversario. Lo spostamento del modello di minaccia ha conseguenze tecniche concrete, leggibili nei documenti IETF, nelle configurazioni dei server e negli standard ritirati.

Contesto

Le rivelazioni rese pubbliche tra giugno e ottobre 2013 — PRISM, la raccolta di massa di metadati, il programma BULLRUN per indebolire gli standard crittografici, l’intercettazione dei cavi sottomarini documentata sotto il nome TEMPORA — hanno un peso politico e giuridico che esce da queste note. Il punto tecnico è più stretto e più verificabile: l’idea che un osservatore con accesso ai cavi dorsali sia una parte realistica del modello di minaccia per un protocollo di uso comune.

Fino al 2013 quell’ipotesi pesava poco nel progetto della maggior parte dei protocolli applicativi. Il traffico in chiaro era la norma per le pagine non transazionali; HTTPS restava confinato a login e pagamenti; il riuso della chiave RSA per lo scambio di sessione era diffuso perché costava poco. Ognuna di queste scelte dà per scontato che chi sta tra client e server non registri il traffico per analizzarlo dopo.

Il cambio di modello di minaccia

La formulazione più netta arriva nel maggio 2014 con RFC 7258, Pervasive Monitoring Is an Attack, pubblicato come Best Current Practice 188. Il documento dice in una sola frase che la sorveglianza pervasiva è un attacco tecnico, da mitigare dove possibile nel progetto dei protocolli IETF. È la parola attacco a pesare: porta l’osservatore di massa dentro il lessico con cui si valuta un avversario attivo quando si esaminano le proposte di standard. Un working group che trascuri la mitigazione della sorveglianza pervasiva oggi deve giustificare la scelta, non darla per acquisita.

RFC 7258 non introduce alcun meccanismo: cambia i criteri di accettabilità. Una proposta che esponga metadati riutilizzabili da un osservatore passivo parte da una posizione più debole nella discussione tecnica. È un vincolo di processo, e i suoi effetti si leggono nelle revisioni dei protocolli pubblicate dopo.

Forward secrecy come configurazione di default

La conseguenza più misurabile riguarda lo scambio di chiavi in TLS. Con lo scambio RSA classico il client cifra il segreto di sessione con la chiave pubblica del server; chi registra il traffico e in seguito ottiene la chiave privata può decifrare a ritroso tutte le sessioni catturate. È esattamente lo scenario dell’osservatore che archivia oggi per decifrare domani.

La forward secrecy — ottenuta con scambio Diffie-Hellman effimero, in pratica ECDHE su curve ellittiche — toglie questa dipendenza: ogni sessione usa un segreto temporaneo che non viaggia mai sul filo e non si ricostruisce dalla sola chiave privata a lungo termine. La proprietà era nota e disponibile in TLS 1.2 (RFC 5246, 2008) molto prima del 2013, ma restava opzionale e spesso bassa nell’ordine delle cipher suite. Nei tre anni successivi diventa la configurazione raccomandata di fatto: ECDHE in cima all’ordine di preferenza, scambio RSA deprecato nelle guide di hardening. Il lavoro IETF sulla revisione successiva di TLS, ancora allo stato di draft a metà 2016, rende la forward secrecy obbligatoria invece che facoltativa.

Dual_EC_DRBG: dal sospetto al ritiro

Il caso più diretto di indebolimento di uno standard riguarda Dual_EC_DRBG, un generatore di numeri pseudocasuali a curve ellittiche standardizzato dal NIST in SP 800-90A. Un possibile difetto strutturale era già documentato nel 2007: Dan Shumow e Niels Ferguson avevano mostrato che le costanti dello standard potevano nascondere una relazione nota solo a chi le aveva generate, sufficiente a prevederne l’output. Restava un sospetto teorico, perché mancavano prove sull’origine di quelle costanti.

I documenti BULLRUN spostano il sospetto verso la conferma operativa. Il NIST riapre la revisione di SP 800-90A, raccoglie i commenti pubblici e nel 2014 toglie Dual_EC_DRBG dallo standard. È l’esempio più nitido del problema sollevato da BULLRUN: uno standard pubblico, adottato in buona fede da implementatori che si fidavano del processo, costruito in modo da essere debole per chi conoscesse il parametro nascosto. La risposta tecnica — ritiro dello standard e revisione del processo che lo aveva prodotto — è documentata negli atti del NIST.

Abbassare il costo di accesso a HTTPS

Se la forward secrecy e il ritiro di Dual_EC_DRBG riguardano la qualità del canale cifrato, un secondo filone riguarda la sua diffusione. Cifrare un canale isolato protegge poco se il resto del web resta in chiaro: l’osservatore passivo legge comunque la maggior parte del traffico. L’ostacolo storico all’HTTPS universale era operativo — costo, rinnovo manuale e configurazione dei certificati X.509 — più che crittografico.

L’Internet Security Research Group avvia Let’s Encrypt come autorità di certificazione gratuita, con emissione e rinnovo automatizzati tramite il protocollo ACME. Dopo una beta pubblica aperta a dicembre 2015, il servizio entra in disponibilità generale il 12 aprile 2016. L’effetto rilevante è economico prima che crittografico: azzera il costo marginale e l’attrito operativo di un certificato valido, e con loro una delle ragioni per cui un sito restava in chiaro. È coerente con il modello di RFC 7258 — ridurre la superficie leggibile da un osservatore di massa — senza chiedere nuovi meccanismi crittografici.

Il finanziamento dell’infrastruttura condivisa

Il 2014 fa emergere anche un problema indipendente da Snowden ma trattato dalla stessa comunità. La vulnerabilità Heartbleed (CVE-2014-0160, aprile 2014) in OpenSSL rende visibile che una libreria su cui poggiava gran parte del traffico cifrato del web era mantenuta da pochissime persone con un finanziamento minimo. La risposta è stata strutturale: la Core Infrastructure Initiative, ospitata dalla Linux Foundation, finanzia le librerie open source critiche; OpenBSD forka LibreSSL per semplificare e ripulire la base di codice; gli audit indipendenti aumentano. Il punto in comune con la reazione a Snowden è semplice: la fiducia in un canale dipende dalla verificabilità del codice che lo implementa, e quella verificabilità costa risorse, non solo licenze aperte.

Limiti

I cambiamenti descritti riguardano il canale di trasporto e la sua diffusione, non gli endpoint. La cifratura forward-secret tra browser e server non protegge i dati una volta arrivati al server, dove i programmi di raccolta presso i provider — come quelli associati a PRISM — operano sui dati in chiaro. Il modello di minaccia formalizzato da RFC 7258 è quello dell’osservatore sulla rete; non copre l’accesso legale o operativo all’endpoint, che resta un problema di governance e giurisdizione più che di protocollo.

Va anche distinta la disponibilità di un meccanismo dalla sua adozione effettiva. A metà 2016 la quota di traffico HTTPS cresce ma è lontana dalla totalità, molti server espongono ancora cipher suite deprecate, e la revisione di TLS che impone la forward secrecy è un draft, non uno standard pubblicato. La traiettoria di tre anni si legge nei documenti; la sua estensione a tutto l’ecosistema è un processo ancora in corso.

Immagine di copertina: Edward Snowden nel 2013, ritratto a mezzo busto mentre parla, fotogramma di un video — foto di The WikiLeaks Channel, CC BY 3.0 — https://commons.wikimedia.org/wiki/File:Edward_Snowden_2013-10-9_(1)_(cropped).jpg