HTTPS, DoH, ECH i una VPN amaguen coses diferents
Cada mecanisme elimina un observador diferent del camí, i cap no els elimina tots. Compareu què queda protegit abans d'afegir un altre túnel.
Afegir una VPN a un navegador que ja fa servir HTTPS, DoH i ECH no apila tres proteccions en una; canvia qui és a la posició d'observar què. Cada mecanisme elimina una part diferent d'un intercanvi diferent, i cadascun deixa alguna cosa enrere. La pregunta útil no és quin és el més fort, sinó quin observador voleu eliminar, perquè la resposta decideix si un túnel ajuda de debò. Una comparació dels observadors que queden és més útil que una llista de funcions.
Quatre mecanismes, quatre observadors
Comenceu per les quatre relacions i per la part que cadascuna està dissenyada a deixar fora. La taula de sota és la que faig servir a les revisions, perquè obliga la conversa a nomenar un observador en lloc d'una tecnologia.
| Mecanisme | Relació que protegeix | Observador que no elimina |
|---|---|---|
| HTTPS | La connexió TLS de l'aplicació amb el seu punt final anomenat | La xarxa d'accés encara veu l'adreça de destinació |
| DoH | L'intercanvi DNS amb el resolutor HTTPS triat | Aquest resolutor veu cada consulta |
| ECH | Els camps sensibles del ClientHello, quan es donen suport i s'accepten | Les adreces de destinació, i el DNS si no queda cobert |
| VPN | Els paquets coberts portats fins al parell de VPN | L'operador de la VPN veu les destinacions |
El valor de la taula és el que es nega a dir. No classifica els mecanismes ni afirma que fer servir tots quatre elimini tots quatre observadors. Una aplicació web al núvol que ja acaba el TLS a la seva pròpia vora queda protegida de la xarxa d'accés per a aquell intercanvi, i cap túnel millora aquesta propietat concreta. El que un túnel pot canviar és quina xarxa veu els paquets exteriors i quin operador és ara al camí.
Què amaga realment HTTPS
HTTPS protegeix l'intercanvi de l'aplicació entre el client i el punt final que el certificat anomena. No amaga l'adreça de destinació, no amaga que s'ha produït una connexió i no amaga el nom tret que ECH hi sigui present. La validació del certificat és part de la protecció, no una formalitat al seu voltant.
Una VPN no necessita acabar aquell TLS, i una sortida de reenviament no s'ha de tractar com el punt final autenticat de l'aplicació. Si un disseny fa que la sortida desxifri, és una altra arquitectura amb una altra declaració de confiança.
Què mouen DoH i ECH, i què deixen
DoH mou l'intercanvi DNS a un resolutor HTTPS, cosa que vol dir que aquest resolutor veu les vostres consultes en lloc del resolutor de la xarxa local. És un canvi real i limitat: el resolutor triat esdevé una part que pot correlacionar les consultes amb les adreces a què us connecteu després, que és precisament la correlació que tracta RFC 8484. El transport xifrat no fa que el destinatari desconegui les consultes que respon.
ECH protegeix la part sensible del ClientHello perquè un observador passiu al camí no pugui llegir el nom de servidor previst. Depèn d'un desplegament compatible i de l'acceptació del servidor i de la xarxa, i deixa altres canals al seu lloc: les adreces de destinació continuen visibles i el DNS encara pot revelar el nom.
L'altra cosa que ECH no fa és demostrar-se a si mateix. Una connexió que fa servir TLS 1.3 no és prova que ECH s'hagi acceptat, i un navegador que ofereix ECH a un servidor que no el suporta recula en silenci. Comproveu l'estat real de la connexió en lloc d'inferir-lo de la versió del protocol.
Aquesta és la forma general de tota la comparació: cada mecanisme es verifica a la seva capa, i cap d'ells no es verifica per l'èxit d'un altre.
Què mou una VPN, i què afegeix
Quan el trànsit web entra en una VPN, la xarxa d'accés veu l'intercanvi exterior amb el parell de VPN en lloc de les connexions individuals de les aplicacions, i l'operador de la VPN pren posició al camí posterior. És un desplaçament de la frontera de confiança, no la seva eliminació. L'operador ara veu a quines destinacions arribeu, encara que el contingut continuï xifrat d'extrem a extrem. Si això és una millora depèn del tot de quina d'aquestes dues parts confieu menys.
Manteniu l'HTTPS de l'aplicació i la protecció del resolutor prevista mentre feu això. Un túnel no substitueix la validació del certificat, i desactivar les proteccions d'un resolutor perquè el trànsit va per un túnel elimina un control sense substituir-lo.
Triar a partir del requisit
Enuncieu el requisit real, perquè és el que decideix el disseny. Admissió a recursos privats, un punt de sortida gestionat, una amenaça concreta de la xarxa d'accés i l'autorització de dispositius són quatre necessitats diferents amb quatre respostes diferents, i una empresa que només fa servir aplicacions de núvol públic encara ha de decidir l'autorització i el tractament de dades. Les capes addicionals poden ser adequades sense ser intercanviables. Una connexió més complicada no és una mesura d'anonimat i no és un argument de seguretat per si mateixa.
L'especificació d'ECH, RFC 9849, val la pena llegir-la pel que el mecanisme cobreix i pel que no, i és honesta sobre els canals que deixa tranquils. Compareu els mecanismes per l'observador que cadascun elimina, escriviu aquest observador i després decidiu si la capa extra hi respon. Si la resposta és que l'observador ja era fora del vostre model d'amenaces, el túnel és cost sense benefici.