HTTPS, DoH, ECH och ett VPN döljer olika saker
Varje mekanism tar bort en annan observatör från vägen och ingen tar bort alla. Jämför vad som skyddas innan du lägger till ännu en tunnel.
Att lägga till ett VPN i en webbläsare som redan använder HTTPS, DoH och ECH staplar inte tre skydd till ett; det ändrar vem som är i stånd att observera vad. Varje mekanism tar bort en annan part från ett annat utbyte, och varje lämnar något kvar. Den användbara frågan är inte vilken som är starkast utan vilken observatör du försöker ta bort, eftersom svaret avgör om en tunnel hjälper alls. En jämförelse av de kvarvarande observatörerna är mer användbar än en funktionslista.
Fyra mekanismer, fyra observatörer
Börja med de fyra relationerna och den part som var och en är konstruerad att hålla utanför. Tabellen nedan är den jag använder vid granskning, eftersom den tvingar samtalet att namnge en observatör i stället för en teknik.
| Mechanism | Relationship it protects | Observer it does not remove |
|---|---|---|
| HTTPS | The application's TLS connection to its named endpoint | The access network still sees the destination address |
| DoH | The DNS exchange to the selected HTTPS resolver | That resolver sees every query |
| ECH | The sensitive ClientHello fields, where supported and accepted | Destination addresses, and DNS if it is not covered |
| VPN | Covered packets carried to the VPN peer | The VPN operator sees the destinations |
Tabellens värde är det den vägrar säga. Den rangordnar inte mekanismerna och hävdar inte att användning av alla fyra tar bort alla fyra observatörerna. En molnbaserad webbapplikation som redan avslutar TLS vid sin egen kant är skyddad från åtkomstnätet för det utbytet, och ingen tunnel förbättrar den egenskapen. Vad en tunnel kan ändra är vilket nätverk som ser de yttre paketen och vilken operatör som nu finns på vägen.
Vad HTTPS faktiskt döljer
HTTPS skyddar applikationsutbytet mellan klienten och den slutpunkt som certifikatet namnger. Det döljer inte destinationsadressen, det döljer inte att en anslutning skedde och det döljer inte namnet om inte ECH är inblandat. Certifikatvalidering är en del av skyddet, inte en formalitet runt det.
Ett VPN behöver inte avsluta den TLS, och en vidarebefordrande utgång bör inte behandlas som applikationens autentiserade slutpunkt. Om en design låter utgången dekryptera är det en annan arkitektur med ett annat förtroendeutlåtande.
Vad DoH och ECH flyttar, och vad de lämnar kvar
DoH flyttar DNS-utbytet till en HTTPS-upplösare, vilket betyder att den upplösaren ser dina frågor i stället för det lokala nätverkets upplösare. Det är en verklig och avgränsad förändring: den valda upplösaren blir en part som kan korrelera frågor med de adresser du sedan ansluter till, vilket är precis den korrelation som dokumentet RFC 8484 diskuterar. Krypterad transport gör inte mottagaren omedveten om de frågor den besvarar.
ECH skyddar den känsliga delen av ClientHello så att en passiv observatör på vägen inte kan läsa det avsedda servernamnet. Det beror på en stödjande driftsättning och på att servern och nätverket accepterar det, och det lämnar andra kanaler på plats: destinationsadresser förblir synliga och DNS kan fortfarande avslöja namnet.
Det andra som ECH inte gör är att bevisa sig självt. En anslutning som använder TLS 1.3 är inte bevis för att ECH accepterades, och en webbläsare som erbjuder ECH till en server som inte stöder det faller tillbaka tyst. Kontrollera anslutningens faktiska tillstånd i stället för att sluta dig till det från protokollversionen.
Det är den allmänna formen av hela jämförelsen: varje mekanism verifieras i sitt eget lager, och ingen av dem verifieras av en annans framgång.
Vad ett VPN flyttar, och vad det tillför
När webbtrafik går in i ett VPN ser åtkomstnätet det yttre utbytet med VPN-peerens i stället för de enskilda applikationsanslutningarna, och VPN-operatören tar en position på den vidare vägen. Det är en förflyttning av förtroendegränsen, inte ett borttagande av en sådan. Operatören ser nu vilka destinationer du når, även om innehållet förblir krypterat hela vägen. Om det är en förbättring beror helt på vilken av dessa två parter du litar mindre på.
Behåll applikationens HTTPS och det avsedda upplösarskyddet på plats medan du gör detta. En tunnel är ingen ersättning för certifikatvalidering, och att stänga av en upplösares skydd för att trafiken är tunnlad tar bort en kontroll utan att ersätta den.
Att välja utifrån kravet
Ange det faktiska kravet, eftersom det avgör designen. Tillträde till privata resurser, en hanterad utgångspunkt, ett specifikt hot mot åtkomstnätet och enhetsauktorisering är fyra olika behov med fyra olika svar, och ett företag som bara använder offentliga molnapplikationer måste ändå avgöra auktorisering och datahantering. Extra lager kan vara lämpliga utan att vara utbytbara. En mer komplicerad anslutning är inte en anonymitetsmätning och är inte i sig ett säkerhetsargument.
ECH-specifikationen, RFC 9849, är värd att läsa för vad mekanismen täcker och inte täcker, och den är ärlig om de kanaler den lämnar ifred. Jämför mekanismerna efter vilken observatör var och en tar bort, skriv ned den observatören och avgör sedan om det extra lagret adresserar den. Om svaret är att observatören redan låg utanför din hotmodell är tunneln kostnad utan nytta.