Contribuire alla creazione della prossima generazione di protocolli per la tutela della privacy

Negli ultimi dieci anni, Cloudflare è diventato una parte importante dell'infrastruttura di Internet, aiutando siti, API e servizi Web a diventare più sicuri ed efficienti. Internet non sta solo crescendo in termini di capacità e di persone che lo usano, ma si sta anche evolvendo per quanto concerne l'architettura e le funzionalità. Come attore nell'ecosistema di Internet, Cloudflare ha la responsabilità di aiutarlo a crescere in un modo che rispetti i suoi utenti e crei valore per loro. Oggi faremo diversi annunci sul miglioramento dei protocolli Internet relativamente a un aspetto che è importante per i nostri clienti e gli utenti Internet di tutto il mondo: la privacy.

Le iniziative sono le seguenti:

• Fissare una delle ultime falle nelle informazioni in HTTPS tramite Encrypted Client Hello (ECH), precedentemente noto come Encrypted SNI

• Rendere il DNS ancora più privato supportando Oblivious DNS-over-HTTPS (ODoH)

• Sviluppare un protocollo superiore per l'autenticazione con password, OPAQUE, che renda meno probabile che si verifichino violazioni delle password

Ognuno di questi progetti impatta su un aspetto di Internet capace di influire sulla nostra vita online e sulle nostre "impronte digitali". Che ne siamo o meno consapevoli, ci sono moltissime informazioni private su di noi e sulle nostre vite che fluttuano online. Questo è un problema che possiamo contribuire a risolvere.

Da oltre un anno lavoriamo con organismi di certificazione, quali la IETF, e collaboriamo con i più grandi nomi della tecnologia Internet (tra cui Mozilla, Google, Equinix e altri) per progettare, implementare e testare questi nuovi protocolli di tutela della privacy su Internet. Ciascuno di questi tre protocolli riguarda un aspetto fondamentale della nostra vita online e ci aspettiamo che, man mano che vengono adottati, contribuiscano a migliorare sostanzialmente la privacy online.

Una delle missioni principali di Cloudflare consiste nel supportare e sviluppare una tecnologia che contribuisca a costruire un Internet migliore. A livello di settore, inoltre, abbiamo compiuto progressi eccezionali e reso Internet più sicuro e solido. Cloudflare è orgogliosa di aver avuto un ruolo in questo progresso attraverso molteplici iniziative attuate nel corso degli anni.

Ecco alcuni punti salienti:

• Universal SSL™. Siamo stati una delle forze trainanti per la crittografia del Web. Abbiamo lanciato Universal SSL nel 2014 per offrire gratuitamente ai nostri clienti la crittografia dei siti, e abbiamo collaborato attivamente con le autorità di certificazione, come Let's Encrypt, coi browser Web e con gli operatori di siti per aiutare a rimuovere i contenuti misti. Prima che venisse lanciato Universal SSL, con l'obiettivo di offrire gratuitamente HTTPS a tutti i clienti Cloudflare, solo il 30% delle connessioni ai siti era crittografato. Grazie agli sforzi profusi dall'intero settore, quel numero ha raggiunto ora l'80% — e rappresenta una quota molto maggiore del traffico Internet complessivo. Oltre a fare la nostra parte per crittografare il Web, abbiamo supportato il progetto Certificate Transparency tramite Nimbus e Merkle Town, che presenta una migliore affidabilità per l'ecosistema di certificati su cui si basa HTTPS per l'attendibilità.

• TLS 1.3 e QUIC. Siamo stati anche grandi sostenitori dell'aggiornamento dei protocolli di sicurezza attualmente in uso. Si prenda ad esempio TLS (Transport Layer Security), il protocollo sottostante che protegge HTTPS. Gli ingegneri di Cloudflare hanno contribuito alla progettazione di TLS 1.3, l'ultima versione dello standard e, nel 2016, abbiamo lanciato il supporto per una versione iniziale del protocollo. Questa implementazione iniziale ha contribuito non poco a migliorarne la versione finale, e TLS 1.3 è ora il protocollo di crittografia più utilizzato sul Web, nonché un componente chiave dell'emergente standard QUIC, che siamo ancora una volta stati tra i primi ad adottare.

• Proteggere il routing, il naming e il timing. Abbiamo compiuto sforzi importanti per proteggere altri componenti critici di Internet. I nostri sforzi per aiutare a proteggere il routing su Internet, attraverso il nostro toolkit RPKI uno studio di misurazione e il nostro strumento "Is BGP Safe Yet", hanno migliorato in modo significativo la resilienza di Internet di fronte ai route leak che causano interruzioni. Il nostro servizio di timing (time.cloudflare.com) ha contribuito a mantenere sincronizzati gli orologi delle persone e rendere i protocolli, come NTS e Roughtime, più sicuri. Abbiamo anche reso il DNS più sicuro supportando DNS-over-HTTPS e DNS-over-TLS in 1.1.1.1 al lancio, insieme a DNSSEC con un solo clic nel nostro servizio DNS autoritativo e registrar.

Continuare a migliorare la sicurezza dei sistemi di attendibilità online è estremamente importante per la crescita di Internet. Tuttavia, è in gioco un principio di progettazione ancor più fondamentale: il rispetto. L'infrastruttura alla base di Internet dovrebbe essere concepita in modo da rispettare i suoi utenti.

Quando si accede a uno specifico sito o a un servizio dotati di un'informativa sulla privacy, si è a conoscenza di come quel sito dovrebbe trattare i dati. È un dato esplicito. Un accordo di questo tipo non esiste, invece, tra gli utenti e gli operatori di Internet. Si potrebbe avere un accordo con il provider di servizi Internet (ISP) e il sito che si sta visitando, ma è molto improbabile che si conoscano anche solo le reti su cui transitano i dati. La maggior parte delle persone non ha un concetto di Internet che vada al di là di quello che vedono sul loro schermo, per cui è difficile immaginare che accettino, o anche solo che comprendano, il significato dell'informativa sulla privacy di un transit wholesaler o di un inspection middlebox.

Senza crittografia, le informazioni di navigazione su Internet vengono implicitamente condivise con innumerevoli terze parti online, dato che le informazioni passano tra le reti. Senza un routing sicuro, il traffico degli utenti può essere dirottato e interrotto. Senza protocolli a tutela della privacy, la vita online degli utenti non è così privata come potrebbero pensare o aspettarsi. L'infrastruttura di Internet non è stata costruita in un modo che rispecchia le loro aspettative.

Diagramma di come il traffico si muove tra le reti, con e senza route leak

La buona notizia è che Internet è in continua evoluzione. Uno dei gruppi che guidano l'evoluzione è l'Internet Architecture Board (IAB), che fornisce una supervisione architettonica dell'Internet Engineering Task Force (IETF), il principale organismo per l'impostazione degli standard per Internet. L'IAB di recente ha pubblicato RFC 8890, che spiega perché gli utenti finali dovrebbero essere prioritari durante la progettazione dei protocolli Internet. In esso si afferma che, in caso di conflitto tra gli interessi degli utenti finali e quelli dei provider di servizi, delle società o dei governi, le decisioni dell'IETF devono privilegiare gli utenti finali. Uno dei principali interessi degli utenti finali è il diritto alla privacy e l'IAB ha pubblicato RFC 6973 per indicare in che modo i protocolli Internet devono tenere conto della privacy.

Oggi i post tecnici del blog riguardano i miglioramenti a Internet progettati per rispettare la privacy degli utenti . La privacy è un argomento complesso che abbraccia più discipline, per cui è importante essere chiari su cosa intendiamo per "migliorare la privacy". Stiamo parlando specificamente di modificare i protocolli che gestiscono le informazioni sensibili alla privacy ora esposte "sulla rete", e modificarle in maniera tale che questi dati siano esposti a un minor numero di soggetti. Questi dati continuano ad esistere, semplicemente non sono più disponibili o visibili a terzi senza la creazione di un meccanismo che li raccolga a uno strato superiore dello stack Internet, il livello applicativo. Questi cambiamenti vanno oltre la crittografia del sito Web: vanno in profondità nella progettazione dei sistemi che sono fondamentali per rendere Internet ciò che è.

Due strumenti per garantire che i dati possano essere utilizzati senza essere visti sono la crittografia e i proxy sicuri.

La crittografia consente di trasformare le informazioni in un formato che solo un numero molto limitato di persone (quelle in possesso della chiave) può comprendere. Alcuni descrivono la crittografia come uno strumento che trasforma i problemi di sicurezza dei dati in problemi di gestione delle chiavi. Si tratta di una descrizione ironica, ma sostanzialmente corretta. La crittografia rende più facile ragionare sulla privacy perché solo i titolari di chiavi possono visualizzare i dati.

Un altro strumento per proteggere l'accesso ai dati è l'isolamento/segmentazione. Limitando fisicamente i soggetti con accesso ai dati, si costruiscono in modo efficace barriere per la privacy. Un'architettura comune consiste nel fare affidamento su proxy consapevoli dei criteri per passare i dati da un luogo all'altro. Tali proxy possono essere configurati per rimuovere dati sensibili o bloccare i trasferimenti di dati tra le parti in base a quanto stabilito dall'informativa sulla privacy.

Entrambi questi strumenti sono efficaci, presi singolarmente, ma possono esserlo ancor di più se combinati. Onion routing (la tecnica crittografica alla base di Tor) è un esempio di come proxy e crittografia possono essere utilizzati in tandem per tutelare efficacemente la privacy. In generale, se il soggetto A desidera inviare dati al soggetto B, può crittografare i dati con la chiave del soggetto B, crittografare i metadati con la chiave di un proxy e inviarli al proxy.

Le piattaforme e i servizi costruiti su Internet possono integrare sistemi di consenso, come le informative sulla privacy presentate attraverso le interfacce utente. L'infrastruttura di Internet si basa su livelli di protocolli sottostanti, e poiché questi livelli di Internet sono finora al di sotto del punto in cui l'utente interagisce con loro, è praticamente impossibile creare un concetto di consenso dell'utente. Allo scopo di rispettare gli utenti e proteggerli da problemi di privacy, i protocolli che mettono insieme Internet dovrebbero essere progettati con la tutela della privacy abilitata per impostazione predefinita.

La transizione da un Web per lo più non crittografato a un Web crittografato ha migliorato molto la privacy degli utenti finali. Ad esempio, il "coffeeshop stalker" non è più un problema per la maggior parte dei siti. Quando accedono alla maggior parte dei siti online, gli utenti non trasmettono più ogni aspetto della loro esperienza di navigazione (query di ricerca, versioni del browser, cookie di autenticazione, ecc.) su Internet rendendolo visibile a qualsiasi partecipante sul percorso. Se un sito è configurato correttamente per utilizzare HTTPS, gli utenti possono essere sicuri che i propri dati sono protetti dai curiosi e che raggiungeranno solo il destinatario desiderato, in quanto le loro connessioni sono sia crittografate che autenticate.

Tuttavia, HTTPS protegge solo i contenuti delle richieste Web. Anche se si naviga solo tramite HTTPS, ciò non significa che i modelli di navigazione siano privati. Ciò avviene perché HTTPS non crittografa un aspetto importante dello scambio: i metadati. Quando si effettua una chiamata telefonica, i metadati sono il numero di telefono, non il contenuto della chiamata. I metadati sono i dati relativi ai dati.

Per illustrare la differenza e perché è importante, ecco un diagramma di ciò che accade quando si visita un sito Web, come ad es. una scheda di immagini. Supponiamo che si stia andando su una pagina specifica della scheda (https://.com/room101/) che presenta specifiche immagini incorporate ospitate su .com.

Lo spazio all'interno della linea tratteggiata rappresenta il soggetto di Internet attraverso il quale i dati devono transitare. Esso include la rete locale o il bar all'angolo, un ISP, oppure potrebbe essere un provider di transito Internet, oppure quella la porzione di rete del provider di servizi cloud che ospita il server. Gli utenti spesso non hanno una relazione con queste entità, o un contratto che impedisca a questi soggetti di fare ciò che meglio credono con i dati dell'utente. Anche se queste entità non guardassero i dati, un osservatore ben posizionato che intercetti il traffico Internet potrebbe vedere qualsiasi informazione che venga inviata senza crittografia: sarebbe preferibile che nessuno vedesse nulla. In questo esempio, il fatto che l'utente abbia visitato .com può essere visualizzato da un osservatore, cosa che è prevista. Tuttavia, nonostante il contenuto della pagina sia crittografato, è possibile sapere quale pagina specifica l'utente ha visitato — può essere visualizzato poiché .com è a sua volta visibile.

La regola generale prevede che, se i dati sono disponibili per dei soggetti on-path su Internet, alcuni di questi soggetti li utilizzeranno. È anche vero che i soggetti on-path hanno bisogno di alcuni metadati per facilitare il trasporto di questi dati. Questo equilibrio viene esplorato nel documento RFC 8558, che spiega in che modo i protocolli devono essere progettati in modo ponderato rispetto all'equilibrio tra troppi metadati (deleterio per la privacy) e metadati troppo scarsi (deleterio per le operazioni).

In un mondo ideale, i protocolli Internet verrebbero progettati con il principio del minimo privilegio. Fornirebbero la quantità minima di informazioni necessarie ai soggetti on-path (pipe) per trasportare i dati nel posto giusto e manterrebbero confidenziale tutto il resto per impostazione predefinita. I protocolli attuali, tra cui TLS 1.3 e QUIC, rappresentano dei passi importanti verso questo ideale, ma non sono in grado di rispettare la privacy dei metadati.

Gli annunci odierni riflettono due livelli di protezione dei metadati: il primo riguarda la limitazione della quantità di metadati disponibili per gli osservatori esterni (come gli ISP), mentre il secondo prevede la limitazione della quantità di metadati condivisi dagli utenti con gli stessi provider di servizi.

I nomi host sono un esempio di metadati che devono essere protetti da osservatori terzi, che è ciò che DoH e ECH intendono fare. Tuttavia, non ha senso nascondere il nome host dal sito che si sta visitando. Né ha senso nasconderlo da un servizio di directory come DNS. Un server DNS deve sapere quale nome host si sta risolvendo per risolverlo!

Un problema di privacy si presenta quando un provider di servizi è a conoscenza sia dei siti che si stanno visitando che dell'identità dell'utente. I singoli siti Web non dispongono di questa rischiosa combinazione di informazioni (tranne nel caso dei cookie di terze parti, che presto spariranno dai browser), ma i provider DNS sì. Fortunatamente, non è in realtà necessario che un risolutore DNS conosca *sia* il nome host del servizio a cui si è diretti che l'IP da cui si proviene. Scorporare i due, che è l'obiettivo di ODoH,è un bene per la privacy.

Le strade dovrebbero essere ben asfaltate, ben illuminate, avere una segnaletica precisa ed essere collegate in modo ottimale. Non sono state progettate per fermare le auto in base a chi c'è dentro. Né dovrebbero esserlo! Come un'infrastruttura di trasporto, è responsabilità dell'infrastruttura Internet ottenere i dati su dove andare, ma non guardare all'interno dei pacchetti e formulare giudizi. Ma Internet è fatto di computer e software, e il software ha la tendenza a essere scritto per prendere decisioni basate sui dati che ha a disposizione.

I protocolli che preservano la privacy cercano di eliminare la tentazione dei provider di infrastrutture e di altri soggetti di "dare una sbirciata" e prendere decisioni basate sui dati personali. Un protocollo che non tutela la privacy come HTTP, mantiene i dati e i metadati, come le password, indirizzi IP e nomi host come parti esplicite dei dati inviati attraverso la rete. Il fatto che siano espliciti significa che qualsiasi osservatore può raccoglierli e trattarli. Un protocollo come HTTPS migliora questo scenario rendendo alcuni dati (come password e contenuti del sito) invisibili sulla rete tramite la crittografia.

I tre protocolli che stiamo esplorando oggi ampliano questo concetto.

• ECH prende la maggior parte dei metadati non crittografati in TLS (incluso il nome host) e li crittografa con una chiave recuperata in anticipo.

• ODoH (una nuova variante di DoH progettata da Apple e dagli ingegneri Cloudflare) utilizza proxy e una crittografia "a cipolla" per rendere invisibile l'origine di una query DNS al resolver DNS. Questo protegge l'indirizzo IP dell'utente durante la risoluzione dei nomi host.

• OPAQUE impiega una nuova tecnica di crittografia per mantenere le password nascoste anche al server. Utilizzando una costruzione chiamata "Oblivious Pseudo-Random Function" (come visto nel Privacy Pass), il server non apprende la password, ma solo se l'utente la conosce o meno.

Facendo in modo che l'infrastruttura Internet si comporti più come un'infrastruttura materiale, la privacy degli utenti viene salvaguardata più facilmente. Internet è più privato se i dati privati possono essere raccolti solo se l'utente ha la possibilità di acconsentire alla loro raccolta.

Per quanto siamo entusiasti di lavorare su nuove modalità per rendere Internet più privato, l'innovazione su scala globale non avviene in maniera slegata dal suo contesto. Ognuno di questi progetti è opera di un gruppo collaborativo di individui che lavorano alla luce del sole in organizzazioni come IETF e IRTF. È fondamentale che i protocolli vengano realizzati attraverso un processo di consenso che coinvolga tutte le parti che compongono l'insieme interconnesso dei sistemi che alimentano Internet. Dai costruttori di browser, ai crittografi, agli operatori DNS e agli amministratori di siti Web, questo è davvero uno sforzo di squadra globale.

Riconosciamo anche che le ampie modifiche tecniche di Internet avranno inevitabilmente anche un impatto anche al di là della comunità tecnica. L'adozione di questi nuovi protocolli può avere implicazioni legali e politiche. Stiamo lavorando attivamente con i governi e i gruppi civili della società per aiutarli a capire l'impatto di questi potenziali cambiamenti.

Oggi non vediamo l'ora di condividere il nostro lavoro e speriamo che più soggetti interessati si uniscano allo sviluppo di questi protocolli. I progetti che stiamo annunciando oggi sono stati progettati da esperti del mondo accademico, dell'industria e dagli hobbisti, e sono stati costruiti da ingegneri di Cloudflare Research (incluso il lavoro dei tirocinanti, che metteremo in evidenza) con il supporto di ogni membro di Cloudflare.

Se siete interessati a questo tipo di lavoro, stiamo assumendo!