La maggior parte delle comunicazioni che transitano su Internet viene crittografata, per garantire che il loro contenuto sia comprensibile solo agli endpoint, vale a dire il client e il server. La crittografia, tuttavia, richiede una chiave, per cui gli endpoint devono concordare una chiave crittografica, e devono farlo senza rivelarla a potenziali aggressori. Il protocollo più utilizzato per questo scopo, detto "scambio delle chiavi", è l'handshake Transport Layer Security (TLS).
In questo post approfondiremo ECH Encrypted Client Hello (ECH), una nuova estensione per TLS che promette di migliorare significativamente la privacy di questo fondamentale protocollo Internet. Oggigiorno, numerosi parametri sensibili alla privacy della connessione TLS vengono negoziati in chiaro. Ciò lascia una miniera di metadati a disposizione degli osservatori della rete, tra cui le identità degli endpoint, il modo in cui utilizzano la connessione e via dicendo.
ECH crittografa l'handshake completo, facendo in modo che questi metadati vengano mantenuti segreti. Fondamentalmente questa operazione argina una falla di lunga data nella privacy, proteggendo il Server Name Indication (SNI) da intercettazioni sulla rete. Crittografare il segreto SNI è di primaria importanza, perché esso costituisce il segnale più chiaro di quale server stia comunicando con un determinato client. Tuttavia, e forse in modo più significativo, ECH pone anche le basi per l'aggiunta a TLS di future funzionalità di sicurezza e miglioramenti delle prestazioni, riducendo nel contempo il loro impatto sulla privacy degli utenti finali.
ECH è il prodotto di una stretta collaborazione, agevolata dalla IETF, tra il mondo accademico e i leader del settore tecnologico, che include Cloudflare, i nostri amici di Fastly e Mozilla, e molti altri attori. Questa funzionalità rappresenta un aggiornamento importante al protocollo TLS e si basa su tecnologie all'avanguardia, come DNS-over-HTTPS, che solo ora stanno giungendo a piena maturazione. Di conseguenza, il protocollo non è ancora pronto per essere implementato su Internet. Questo articolo è da intendersi come una "pietra miliare" sulla strada che porta a una crittografia di full handshake.
Background
La storia di TLS è, in buona sostanza, la storia stessa di Internet. Man mano che la nostra dipendenza da Internet si è accresciuta, anche il protocollo si è evoluto per rispondere ai requisiti operativi, ai casi d'uso e ai modelli di minacce in continua evoluzione. Il client e il server non si limitano a scambiare una chiave, ma negoziano un'ampia varietà di funzionalità e di parametri: il metodo esatto di scambio delle chiavi, l'algoritmo di crittografia, chi è autenticato e come, quale protocollo utilizzare a livello applicativo dopo l'handshake, e moltissime altre cose. Tutti questi parametri influenzano in un modo o nell'altro le proprietà di sicurezza del canale di comunicazione.
SNI è un esempio emblematico di parametro che influisce sulla sicurezza del canale. L'estensione SNI viene utilizzata dal client per indicare al server il sito Web che desidera raggiungere. Ciò è essenziale per l'Internet moderno, poiché oggi è frequente che molti server di origine siano serviti da un singolo operatore TLS. In questa impostazione, l'operatore utilizza SNI per stabilire chi autenticherà la connessione: senza di essa, non ci sarebbe modo di sapere quale certificato TLS presentare al client. Il problema è che SNI rivela alla rete l'identità del server di origine a cui il client desidera connettersi, consentendo potenzialmente agli intercettatori di desumere molte informazioni sulla loro comunicazione. (Naturalmente, ci sono altri modi per un osservatore di rete per identificare l'origine — l'indirizzo IP dell'origine, ad esempio. Ma la co-localizzazione con altre origini sullo stesso indirizzo IP rende molto più difficile utilizzare questa metrica per determinare l'origine rispetto a ispezionare semplicemente SNI.)
Sebbene la protezione di SNI sia uno stimolo per ECH, non è affatto l'unico parametro di handshake sensibile alla privacy che il client e il server negoziano. Un'altro è rappresentato dall'estensione ALPN, che viene impiegata per decidere quale protocollo a livello di applicazione utilizzare una volta stabilita la connessione TLS. Il client invia l'elenco delle applicazioni supportate — sia che si tratti di HTTPS, e-mail, messaggistica istantanea o la miriade di altre applicazioni che utilizzano TLS per la sicurezza del trasporto — il server ne seleziona una dall'elenco e invia la sua scelta al client. In questo modo, il client e il server mandano alla rete un chiaro segnale delle loro capacità e dello scopo per cui potrebbe essere utilizzata la connessione.
Alcune funzionalità sono così sensibili alla privacy che la loro inclusione nell'handshake è fuori discussione. Un'idea che è stata accarezzata prevede di sostituire lo scambio delle chiavi nel nucleo di TLS con Password Authenticated Key Exchange (PAKE). Ciò consentirebbe di utilizzare l'autenticazione basata su password insieme a (o al posto di) un'autenticazione basata su certificati, rendendo TLS più robusto e adatto a una gamma più ampia di applicazioni. Il problema della privacy in questo caso è analogo a SNI: i server in genere associano un identificatore univoco a ciascun client (ad es., un nome utente o un indirizzo e-mail) che viene utilizzato per recuperare le credenziali del client; e il client deve, in qualche modo, trasmettere questa identità al server durante la procedura di handshake. Se inviate in chiaro, queste informazioni di identificazione personale sarebbero facilmente accessibili a qualsiasi osservatore della rete.
Un componente necessario per affrontare tutte queste falle nella privacy è la crittografia handshake, vale a dire la crittografia dei messaggi handshake in aggiunta ai dati dell'applicazione. Sembra abbastanza semplice, ma questa soluzione presenta un altro problema: il client e il server come scelgono una chiave di crittografia se, in fin dei conti, l'handshake è un mezzo per scambiare una chiave? Alcuni parametri devono essere inviati in chiaro, ovviamente, per cui l'obiettivo di ECH è quello di crittografare tutti i parametri dell'handshake, ad eccezione di quelli essenziali per completare lo scambio delle chiavi.
Per comprendere ECH e le decisioni alla base della sua progettazione, è di aiuto avere qualche nozione sulla storia della crittografia handshake in TLS.
Crittografia handshake in TLS
TLS non possedeva alcuna crittografia handshake prima dell'ultima versione, TLS 1.3. Sulla scia delle rivelazioni di Snowden nel 2013, la comunità della IETF iniziò a prendere in considerazione dei modi per contrastare la minaccia che la sorveglianza di massa rappresentava per Internet. Quando il processo di standardizzazione di TLS 1.3 prese il via, nel 2014, uno dei suoi obiettivi di progettazione era quello di crittografare al massimo l'handshake. Purtroppo, allo standard finale manca la crittografia di full handshake e diversi parametri, tra cui SNI, vengono ancora inviati in chiaro. Diamo un'occhiata più da vicino per capire perché.
Il flusso del protocollo TLS 1.3 è illustrato in Figura 1. La crittografia handshake inizia non appena il client e il server calcolano un nuovo segreto condiviso. A tale scopo, il client invia una condivisione della chiave nel suo messaggio ClientHello e il server risponde nel suo ServerHello con la propria condivisione della chiave. Dopo aver scambiato queste condivisioni, il client e il server possono derivare un segreto condiviso. Ogni successivo messaggio handshake viene crittografato utilizzando la chiave di traffico handshake derivata dal segreto condiviso. I dati dell'applicazione sono crittografati utilizzando una chiave diversa, chiamata chiave di traffico dell'applicazione, derivata a sua volta dal segreto condiviso. Queste chiavi derivate hanno proprietà di sicurezza diverse: per enfatizzarle, sono illustrate con colori diversi.
Il primo messaggio dell'handshake crittografato è "EncryptedExtensions" del server. Lo scopo di questo messaggio è proteggere i parametri di handshake sensibili del server, tra cui l'estensione ALPN del server, che contiene l'applicazione selezionata dall'elenco ALPN del client. I parametri dello scambio delle chiavi vengono inviati non crittografati nel ClientHello e ServerHello.
Tutti i parametri di handshake del client, sensibili o meno, vengono inviati in ClientHello. Osservando la Figura 1, si potrebbe pensare a dei modi per rielaborare l'handshake in modo che alcuni di essi possano essere crittografati, magari a scapito di un'ulteriore latenza (ad es. più viaggi di andata e ritorno sulla rete). Tuttavia, estensioni come SNI creano un problema simile a quello dell'uovo e la gallina.
Il client non crittografa nulla fino a quando non ha verificato l'identità del server (questa è la funzione dei messaggi Certificate e CertificateVerify) e il server conferma di conoscere il segreto condiviso (la funzione del messaggio Finished). Queste misure assicurano che lo scambio delle chiavi sia autenticato, prevenendo così attacchi monster-in-the-middle (MITM) in cui l'avversario impersona il server al client in un modo che gli consente di decodificare i messaggi inviati dal client. Poiché SNI è necessario al server per selezionare il certificato, deve essere trasmesso prima che lo scambio delle chiavi venga autenticato.
In generale, garantire la riservatezza dei parametri di handshake utilizzati per l'autenticazione è possibile solo se il client e il server condividono già una chiave di crittografia. Ma da dove potrebbe venire questa chiave?
La crittografia di full handshake agli albori di TLS 1.3. È interessante notare che la crittografia di full handshake veniva proposta come funzionalità principale di TLS 1.3. Nelle prime versioni del protocollo (draft-10, circa 2015), il server offriva al client una chiave pubblica di lunga durata durante l'handshake, che il client utilizzava per la crittografia nei successivi handshake. (Questo progetto proveniva da un protocollo chiamato OPTLS, che a sua volta era stato preso in prestito dalla proposta QUIC originale.) Chiamato "0-RTT", lo scopo principale di questa modalità era quello di consentire al client di iniziare a inviare i dati dell'applicazione prima di completare un handshake. Inoltre, avrebbe permesso al client di crittografare il suo primo invio di messaggi di handshake dopo ClientHello, inclusi i propri EncryptedExtensions, che avrebbero potuto essere utilizzati per proteggere i parametri di handshake sensibili del client.
Alla fine, questa funzionalità non venne inclusa nello standard finale (RFC 8446, pubblicato nel 2018), principalmente perché la sua utilità era surclassata dalla sua complessità. In particolare, non fa nulla per proteggere l'handshake iniziale, in cui il client apprende la chiave pubblica del server. I parametri necessari per l'autenticazione del server per l'handshake iniziale, come SNI, verrebbero comunque trasmessi in chiaro.
Tuttavia, questo schema è importante come precursore di altri meccanismi di crittografia handshake, come ECH, che utilizzano la crittografia a chiave pubblica per proteggere i parametri ClientHello sensibili. Il problema principale che questi meccanismi devono risolvere è la distribuzione delle chiavi.
Prima di ECH c'era (e c'è!) ESNI
Il predecessore immediato di ECH era l'estensione Encrypted SNI (ESNI). Come suggerisce il nome, l'obiettivo di ESNI era quello di garantire la riservatezza del protocollo SNI. Per fare ciò, il client crittografava la sua estensione SNI con la chiave pubblica del server e inviava il testo cifrato al server. Il server tentava di decodificare il testo cifrato utilizzando la chiave segreta corrispondente alla sua chiave pubblica. Se la decodifica aveva esito positivo, il server procedeva con la connessione utilizzando SNI decrittografato. In caso contrario, si limitava a interrompere l'handshake. Il flusso di livello avanzato di questo semplice protocollo è illustrato in Figura 2.
Per la distribuzione delle chiavi, ESNI faceva affidamento su un altro protocollo fondamentale: Domain Name Service (DNS). Al fine di utilizzare ESNI per connettersi a un sito Web, il client agganciava alle sue query standard A/AAAA una richiesta di record TXT con la chiave pubblica ESNI. Ad esempio, per ottenere la chiave di crypto.dance il client richiederebbe il record TXT di _esni.crypto.dance:
$ dig _esni.crypto.dance TXT +short
"/wGuNThxACQAHQAgXzyda0XSJRQWzDG7lk/r01r1ZQy+MdNxKg/mAqSnt0EAAhMBAQQAAAAAX67XsAAAAABftsCwAAA="
Il blob codificato base64-encoded contiene una chiave pubblica ESNI e parametri correlati come l'algoritmo di crittografia.
Ma perché crittografare SNI se vogliamo solo far trapelare il nome del server agli osservatori di rete tramite una query DNS in chiaro? L'implementazione di ESNI in questo modo è diventata fattibile con l'introduzione di DNS-over-HTTPS (DoH), che consente la crittografia delle query DNS ai resolver che forniscono il servizio DoH (1.1.1.1 è un esempio di tale servizio). Un'altra funzionalità importantissima di DoH è che fornisce un canale autenticato per la trasmissione della chiave pubblica ESNI dal server DoH al client. Questo impedisce attacchi di cache-poisoning provenienti dalla rete locale del client: in assenza di DoH, un aggressore locale potrebbe impedire al client di offrire l'estensione ESNI, restituendo un record TXT vuoto, oppure obbligare il client a utilizzare ESNI con una chiave che controlla.
Anche se ESNI ha fatto un discreto passo avanti, non è all'altezza del nostro obiettivo di ottenere una crittografia di full handshake. Oltre a essere incompleto — protegge solo l'estensione SNI — è vulnerabile a diversi attacchi sofisticati che, sebbene difficili da realizzare, puntano a debolezze teoriche nella progettazione del protocollo che devono essere affrontate.
ESNI è stato distribuito da Cloudflare e abilitato da Firefox, su richiesta, nel 2018, un'esperienza che ha messo a nudo alcune sfide legate all'affidamento sul DNS per la distribuzione delle chiavi. Cloudflare ruota ogni ora la propria chiave ESNI per ridurre al minimo i danni collaterali nell'eventualità in cui una chiave venisse compromessa. Gli artefatti DNS vengono talvolta memorizzati nella cache molto più a lungo, con il risultato che c'è una discreta possibilità che un client si ritrovi con una chiave pubblica obsoleta. Sebbene ciò sia in una certa misura tollerato dal servizio ESNI di Cloudflare, tutte le chiavi sono destinate a scadere. La domanda che il protocollo ESNI ha lasciato aperta è come dovrebbe procedere il client nel caso in cui la decodifica non andasse a buon fine e non potesse accedere alla chiave pubblica corrente tramite DNS o con un altro mezzo.
Un altro problema nell'affidarsi al DNS per la distribuzione delle chiavi è rappresentato dal fatto che diversi endpoint potrebbero essere autoritativi per lo stesso server di origine, ma con funzionalità diverse. Ad esempio, una richiesta per il record A di "esempio.com" potrebbe restituire uno dei due indirizzi IP diversi, ognuno gestito da una diversa CDN. Il record TXT per "_esni.example.com" conterrà la chiave pubblica per uno di questi CDN, ma certamente non entrambi. Il protocollo DNS non offre un modo per legare atomicamente i record di risorse che corrispondono allo stesso endpoint. In particolare, è possibile che un client offra inavvertitamente l'estensione ESNI a un endpoint che non lo supporta, causando l'interruzione dell'handshake. La correzione di questo problema richiede modifiche al protocollo DNS. (Maggiori informazioni su questo argomento più sotto.)
Il futuro di ESNI. Nella prossima sezione descriveremo le specifiche di ECH e il modo in cui risolve i problemi di ESNI. Nonostante le sue limitazioni, tuttavia, il vantaggio pratico in termini di privacy che ESNI fornisce è significativo. Cloudflare intende continuare a supportare ESNI fino a quando ECH non sarà messo in produzione.
Pro e contro di ECH
L'obiettivo di ECH è crittografare l'intero ClientHello, colmando così la lacuna rimasta in TLS 1.3 e ESNI mediante la protezione di tutti i parametri di handshake sensibili alla privacy. Analogamente a ESNI, il protocollo utilizza una chiave pubblica, distribuita tramite DNS e ottenuta utilizzando DoH, per la crittografia durante il primo invio del client. Tuttavia, ECH presenta dei miglioramenti nella distribuzione delle chiavi che rendono il protocollo più robusto di fronte alle incongruenze della cache DNS. Mentre il server ESNI interrompe la connessione se la decodifica non va a buon fine, il server ECH tenta di completare l'handshake e fornire al client una chiave pubblica che può utilizzare per riprovare la connessione.
Ma come può il server completare l'handshake se non è in grado di decodificare ClientHello? Come illustrato in Figura 3, il protocollo ECH interessa in realtà due messaggi ClientHello: ClientHelloOuter, che viene inviato in chiaro, come al solito, e ClientHelloInner, che viene crittografato e inviato come estensione di ClientHelloOuter. Il server completa l'handshake con uno solo di questi ClientHello: se la decodifica ha esito positivo, allora procede con ClientHelloInner; in caso contrario, procede con ClientHelloOuter.
ClientHelloInner è composto dai parametri di handshake che il client desidera utilizzare per la connessione. Essi includono valori sensibili, come l'SNI del server di origine che vuole raggiungere (chiamato server back-end nel linguaggio ECH), l'elenco ALPN e così via. ClientHelloOuter, sebbene sia a sua volta un messaggio ClientHello a tutti gli effetti, non viene utilizzato per la connessione prevista. L'handshake viene invece completato dallo stesso provider di servizi ECH (detto server client-facing), segnalando al client che la destinazione prevista non può essere raggiunta a causa di un errore di decodifica. In questo caso, il provider di servizi invia anche la chiave pubblica ECH corretta con la quale il client può riprovare l'handshake, "correggendo" così la configurazione del client. (Questo meccanismo è simile al modo in cui il server ha distribuito la sua chiave pubblica per la modalità 0-RTT nei primi tempi di TLS 1.3.)
Come minimo, entrambi i ClientHello devono contenere i parametri di handshake necessari per uno scambio delle chiavi autenticato dal server. In particolare, mentre ClientHelloInner contiene la vera SNI, ClientHelloOuter contiene anche un valore SNI, che il client prevede di verificare in caso di errore nella decodifica ECH (ad esempio, il server client-facing). Se la connessione viene stabilita tramite ClientHelloOuter, il client dovrebbe interrompere immediatamente la connessione e riprovare l'handshake con la chiave pubblica fornita dal server. Non è necessario che il client specifichi un elenco ALPN in ClientHelloOuter, né qualsiasi altra estensione utilizzata per guidare la gestione dopo l'handshake. Tutti questi parametri sono incapsulati da ClientHelloInner crittografato.
Questa soluzione progettuale risolve — ritengo anche in maniera piuttosto elegante — la maggior parte delle difficoltà relative all'implementazione sicura della crittografia dell'handshake riscontrate nei meccanismi precedenti. È importante sottolineare che la progettazione di ECH non è avvenuta in maniera slegata dal suo contesto. Il protocollo riflette le diverse prospettive della comunità della IETF, e il suo sviluppo si abbina ad altri standard IETF che sono cruciali per il successo di ECH.
Il primo è una nuova importante funzionalità DNS nota come tipo di record di risorse HTTPS. A un livello avanzato, questo tipo di record ha lo scopo di consentire più endpoint HTTPS autoritativi per lo stesso nome di dominio per pubblicizzare diverse funzionalità per TLS. Ciò rende possibile fare affidamento sul DNS per la distribuzione delle chiavi, risolvendo una delle sfide di distribuzione rilevate dalla distribuzione ESNI iniziale. Per un approfondimento su questo nuovo tipo di record, e su cosa significa più in generale per Internet, consultare il recente post del blog di Alessandro Ghedini al riguardo.
Il secondo è lo standard HPKE (Hybrid Public Key Encryption) di CFRG, che specifica un framework estensibile per la creazione di schemi di crittografia a chiave pubblica adatti a una vasta gamma di applicazioni. In particolare, ECH delega tutti i dettagli del suo meccanismo di crittografia handshake a HPKE, ottenendo una specifica molto più semplificata e facile da analizzare. (Per inciso, HPKE è anche il componente principale di Oblivious DNS-over-HTTPS.)
La strada da percorrere
L'attuale specifica ECH è il risultato finale di una collaborazione pluriennale. In questo momento la struttura complessiva del protocollo è abbastanza stabile. Di fatto, l'attuale bozza della specifica sarà la prima delle implementazioni a essere oggetto di test di interoperabilità. Tuttavia, rimangono da risolvere una serie di dettagli. Concludiamo questo post con una breve panoramica della strada da percorrere.
Resistenza all'analisi del traffico
In definitiva, l'obiettivo di ECH è quello di garantire che le connessioni TLS su server di origine diversi con lo stesso provider di servizi ECH siano indistinguibili l'una dall'altra. In altre parole, quando ci si connette a un'origine nel perimetro, ad esempio, di Cloudflare, nessuno sulla rete tra l'utente e Cloudflare dovrebbe essere in grado di individuare quale origine è stata raggiunta o quali parametri di handshake sensibili alla privacy l'utente e l'origine hanno negoziato. Oltre a un potenziamento immediato della privacy, questa proprietà, se ottenuta, spiana la strada alla distribuzione di nuove funzionalità per TLS senza compromettere la privacy.
Crittografare ClientHello è un passo importante verso il raggiungimento di questo obiettivo, ma dobbiamo fare ancora qualcosina in più. Un importante vettore di attacco di cui non abbiamo ancora discusso è l'analisi del traffico. Essa si riferisce alla raccolta e all'analisi delle proprietà del canale di comunicazione che tradiscono parte del contenuto del testo cifrato, ma senza corrompere lo schema di crittografia sottostante. Ad esempio, la lunghezza di ClientHello crittografato potrebbe rivelare all'avversario informazioni sufficienti su SNI da permettergli di formulare un'ipotesi ragionevole sul suo valore (questo rischio è elevato sopratutto per i nomi di dominio particolarmente corti o particolarmente lunghi). È quindi fondamentale che la lunghezza di ciascun testo cifrato sia indipendente dai valori dei parametri sensibili alla privacy. L'attuale specifica ECH fornisce alcune mitigazioni, ma la loro copertura è incompleta. Pertanto, migliorare la resistenza di ECH all'analisi del traffico rappresenta un'indicazione importante per il lavoro futuro.
Lo spettro dell'ossificazione
Un'importante domanda aperta per ECH è l'impatto che avrà sulle operazioni di rete.
Una delle lezioni apprese dalla distribuzione di TLS 1.3 è che l'aggiornamento di un protocollo Internet di base può innescare comportamenti di rete imprevisti. Cloudflare è stato uno dei primi, tra i principali operatori TLS, a distribuire TLS 1.3 su scala; quando browser come Firefox e Chrome iniziarono ad abilitarlo su base sperimentale, osservarono un tasso di errori di connessione significativamente più elevato rispetto a TLS 1.2. La causa principale di questi errori si doveva all'ossificazione della rete, ovvero la tendenza dei middlebox — dispositivi di rete tra client e server che monitorano e talvolta intercettano il traffico — a scrivere software che si aspettano che il traffico appaia e si comporti in un certo modo. Cambiare il protocollo prima che i middlebox avessero la possibilità di aggiornare il loro software portò i middlebox a cercare di analizzare pacchetti che non riconoscevano, innescando bug nel software che, in alcuni casi, causavano l'interruzione completa delle connessioni.
Questo problema era talmente diffuso che, invece di aspettare che gli operatori di rete aggiornassero il loro software, il design di TLS 1.3 venne modificato al fine di prevenire l'impatto dell'ossificazione della rete. L'ingegnosa soluzione era quella di "far sembrare" TLS 1.3 un altro protocollo che i middlebox sono noti per tollerare. In particolare, il formato della rete e persino il contenuto dei messaggi di handshake vennero fatti a somiglianza di TLS 1.2. Questi due protocolli non sono identici, ovviamente — un curioso osservatore di rete riesce comunque a distinguerli — ma sembrano e si comportano in modo abbastanza simile da garantire che la maggior parte dei middlebox esistenti non li tratti in modo diverso. Empiricamente, si è constatato che questa strategia ha ridotto in modo significativo il tasso di errori di connessione, abbastanza da rendere fattibile l'implementazione di TLS 1.3.
Ancora una volta, ECH rappresenta un aggiornamento significativo per TLS, per il quale lo spettro di ossificazione della rete è grande. ClientHello contiene parametri, come SNI, che esistono nell'handshake da molto tempo, e non sappiamo ancora quale sarà l'impatto della loro crittografia. In previsione dei problemi di implementazione che l'ossificazione potrebbe comportare, il protocollo ECH è stato progettato per assomigliare il più possibile a un normale handshake TLS 1.3. La differenza più importante è la stessa estensione ECH: se i middlebox la ignorano — come dovrebbero fare, se sono conformi allo standard TLS 1.3 — allora il resto dell'handshake apparirà e si comporterà pressoché come al solito.
Resta da vedere se questa strategia sarà sufficiente a garantire un impiego su larga scala di ECH. In tal caso, è importante notare che questa nuova funzionalità contribuirà a mitigare l'impatto dei futuri aggiornamenti di TLS sulle operazioni di rete. La crittografia di full handshake riduce il rischio di ossificazione, poiché significa che ci sono meno funzionalità del protocollo visibili su cui il software possa ossificarsi. Riteniamo che ciò sia positivo per la salute di Internet in generale.
Conclusione
Il vecchio handshake TLS è (involontariamente) debole. I requisiti operativi sia del client che del server hanno portato parametri sensibili alla privacy, come SNI, ad essere negoziati completamente in chiaro e a disposizione degli osservatori di rete. L'estensione ECH mira a colmare questa lacuna abilitando una crittografia di full handshake. Questo rappresenta un aggiornamento importante a TLS, che contribuirà a preservare la privacy dell'utente finale a misura che il protocollo continua a evolversi.
Lo standard ECH è un work-in-progress. Man mano che il lavoro procede, Cloudflare si impegna a fare la sua parte per garantire che questo importante aggiornamento per TLS giunga ad essere implementato su Internet.