HTTPS, DoH, ECH e una VPN nascondono cose diverse
Ogni meccanismo rimuove dal percorso un osservatore diverso, e nessuno li rimuove tutti. Confronta che cosa è protetto prima di aggiungere un altro tunnel.
Aggiungere una VPN a un browser che già usa HTTPS, DoH ed ECH non impila tre protezioni in una; cambia chi è in posizione di osservare che cosa. Ogni meccanismo rimuove una parte diversa da uno scambio diverso, e ciascuno lascia qualcosa dietro di sé. La domanda utile non è quale sia il più forte, ma quale osservatore stai cercando di rimuovere, perché la risposta decide se un tunnel serve davvero. Un confronto degli osservatori rimasti è più utile di un elenco di funzioni.
Quattro meccanismi, quattro osservatori
Parti dalle quattro relazioni e dalla parte che ciascuna è progettata a tenere fuori. La tabella qui sotto è quella che uso in revisione, perché costringe la conversazione a nominare un osservatore invece di una tecnologia.
| Meccanismo | Relazione che protegge | Osservatore che non rimuove |
|---|---|---|
| HTTPS | La connessione TLS dell'applicazione al suo endpoint nominato | La rete di accesso vede ancora l'indirizzo di destinazione |
| DoH | Lo scambio DNS con il resolver HTTPS scelto | Quel resolver vede ogni query |
| ECH | I campi sensibili del ClientHello, dove sono supportati e accettati | Gli indirizzi di destinazione e il DNS se non è coperto |
| VPN | I pacchetti coperti portati fino al peer VPN | L'operatore della VPN vede le destinazioni |
Il valore della tabella è ciò che si rifiuta di dire. Non classifica i meccanismi e non afferma che usare tutti e quattro rimuova tutti e quattro gli osservatori. Un'applicazione web nel cloud che termina già il TLS sul proprio bordo è protetta dalla rete di accesso per quello scambio, e nessun tunnel migliora quella proprietà specifica. Ciò che un tunnel può cambiare è quale rete vede i pacchetti esterni e quale operatore si trova ora sul percorso.
Che cosa nasconde davvero HTTPS
HTTPS protegge lo scambio dell'applicazione tra il client e l'endpoint che il certificato nomina. Non nasconde l'indirizzo di destinazione, non nasconde che è avvenuta una connessione e non nasconde il nome, a meno che ECH non sia in gioco. La validazione del certificato fa parte della protezione, non è una formalità intorno a essa.
Una VPN non deve terminare quel TLS, e un'uscita di inoltro non va trattata come l'endpoint autenticato dell'applicazione. Se un progetto fa decifrare l'uscita, quella è un'altra architettura con un'altra dichiarazione di fiducia.
Che cosa spostano DoH ed ECH, e che cosa lasciano
DoH sposta lo scambio DNS su un resolver HTTPS, il che significa che quel resolver vede le tue query invece del resolver della rete locale. È un cambiamento reale e circoscritto: il resolver scelto diventa una parte che può correlare le query con gli indirizzi a cui poi ti connetti, ed è esattamente la correlazione di cui tratta RFC 8484. Il trasporto cifrato non rende il destinatario inconsapevole delle query a cui risponde.
ECH protegge la parte sensibile del ClientHello così che un osservatore passivo sul percorso non possa leggere il nome del server previsto. Dipende da una distribuzione che lo supporti e dall'accettazione da parte del server e della rete, e lascia in piedi altri canali: gli indirizzi di destinazione restano visibili e il DNS può ancora rivelare il nome.
L'altra cosa che ECH non fa è dimostrare se stesso. Una connessione che usa TLS 1.3 non è prova che ECH sia stato accettato, e un browser che offre ECH a un server che non lo supporta ripiega in silenzio. Controlla lo stato effettivo della connessione invece di dedurlo dalla versione del protocollo.
Questa è la forma generale di tutto il confronto: ogni meccanismo si verifica al proprio livello, e nessuno di essi è verificato dal successo di un altro.
Che cosa sposta una VPN, e che cosa aggiunge
Quando il traffico web entra in una VPN, la rete di accesso vede lo scambio esterno con il peer VPN invece delle singole connessioni delle applicazioni, e l'operatore della VPN prende posizione sul percorso successivo. È uno spostamento del confine di fiducia, non la sua eliminazione. L'operatore ora vede quali destinazioni raggiungi, anche se il contenuto resta cifrato da estremo a estremo. Se questo sia un miglioramento dipende interamente da quale delle due parti consideri meno affidabile.
Mantieni in piedi l'HTTPS dell'applicazione e la protezione prevista del resolver mentre fai questo. Un tunnel non sostituisce la validazione del certificato, e disattivare le protezioni di un resolver perché il traffico passa da un tunnel rimuove un controllo senza sostituirlo.
Scegliere a partire dal requisito
Enuncia il requisito reale, perché è quello che decide il progetto. L'ammissione a risorse private, un punto di uscita gestito, una minaccia specifica della rete di accesso e l'autorizzazione dei dispositivi sono quattro esigenze diverse con quattro risposte diverse, e un'azienda che usa solo applicazioni cloud pubbliche deve comunque decidere autorizzazione e trattamento dei dati. Gli strati aggiuntivi possono essere appropriati senza essere intercambiabili. Una connessione più complicata non è una misura dell'anonimato e non è un argomento di sicurezza di per sé.
La specifica di ECH, RFC 9849, vale la pena di leggerla per ciò che il meccanismo copre e ciò che non copre, ed è onesta sui canali che lascia in pace. Confronta i meccanismi in base all'osservatore che ciascuno rimuove, annota quell'osservatore e poi decidi se lo strato aggiuntivo lo affronta. Se la risposta è che l'osservatore era già fuori dal tuo modello di minaccia, il tunnel è un costo senza beneficio.