HTTPS, DoH, ECH en een VPN verbergen verschillende dingen

Een VPN toevoegen aan een browser die al HTTPS, DoH en ECH gebruikt stapelt niet drie beschermingen in één; het verandert wie in de positie is om wat waar te nemen. Elk mechanisme verwijdert een andere partij uit een andere uitwisseling, en elk laat iets achter. De nuttige vraag is niet welke het sterkst is, maar welke waarnemer u probeert te verwijderen, want het antwoord bepaalt of een tunnel überhaupt helpt. Een vergelijking van de overgebleven waarnemers is nuttiger dan een functielijst.

Vier mechanismen, vier waarnemers

Begin met de vier relaties en de partij die elk ervan buiten de deur moet houden. De tabel hieronder is degene die ik bij beoordelingen gebruik, omdat hij het gesprek dwingt een waarnemer te noemen in plaats van een technologie.

De waarde van de tabel is wat hij weigert te zeggen. Hij rangschikt de mechanismen niet, en hij beweert niet dat het gebruik van alle vier alle vier waarnemers verwijdert. Een cloudwebapplicatie die TLS al aan zijn eigen rand beëindigt, is voor die uitwisseling beschermd tegen het toegangsnetwerk, en geen enkele tunnel verbetert die eigenschap. Wat een tunnel kan veranderen, is welk netwerk de buitenste pakketten ziet en welke operator nu op het pad zit.

Wat HTTPS werkelijk verbergt

HTTPS beschermt de uitwisseling van de applicatie tussen de client en het eindpunt dat het certificaat noemt. Het verbergt niet het bestemmingsadres, het verbergt niet dat er een verbinding was, en het verbergt de naam niet tenzij ECH in het spel is. Certificaatvalidatie is deel van de bescherming, geen formaliteit eromheen.

Een VPN hoeft die TLS niet te beëindigen, en een doorsturende uitgang moet niet als het geauthenticeerde eindpunt van de applicatie worden behandeld. Als een ontwerp de uitgang laat ontsleutelen, is dat een andere architectuur met een andere vertrouwensverklaring.

Wat DoH en ECH verplaatsen, en wat ze laten

DoH verplaatst de DNS-uitwisseling naar een HTTPS-resolver, wat betekent dat die resolver uw query's ziet in plaats van de resolver van het lokale netwerk. Dat is een echte en begrensde verandering: de gekozen resolver wordt een partij die query's kan correleren met de adressen waarmee u daarna verbindt, en dat is precies de correlatie die RFC 8484 bespreekt. Versleuteld transport maakt de ontvanger niet onwetend van de query's die hij beantwoordt.

ECH beschermt het gevoelige deel van de ClientHello zodat een passieve waarnemer op het pad de bedoelde servernaam niet kan lezen. Het hangt af van een ondersteunende uitrol en van acceptatie door de server en het netwerk, en het laat andere kanalen in stand: bestemmingsadressen blijven zichtbaar, en DNS kan de naam nog steeds onthullen.

Het andere dat ECH niet doet, is zichzelf bewijzen. Een verbinding die TLS 1.3 gebruikt is geen bewijs dat ECH is geaccepteerd, en een browser die ECH aanbiedt aan een server zonder ondersteuning valt stil terug. Controleer de werkelijke staat van de verbinding in plaats van die af te leiden uit de protocolversie.

Dat is de algemene vorm van deze hele vergelijking: elk mechanisme wordt op zijn eigen laag geverifieerd, en geen ervan wordt door het succes van een ander geverifieerd.

Wat een VPN verplaatst, en wat hij toevoegt

Wanneer webverkeer een VPN binnenkomt, ziet het toegangsnetwerk de buitenste uitwisseling met de VPN-peer in plaats van de afzonderlijke applicatieverbindingen, en de VPN-operator neemt een positie in op het verdere pad. Dat is een verplaatsing van de vertrouwensgrens, niet het wegnemen ervan. De operator ziet nu welke bestemmingen u bereikt, zelfs als de inhoud end-to-end versleuteld blijft. Of dat een verbetering is, hangt volledig af van welke van die twee partijen u minder vertrouwt.

Houd de HTTPS van de applicatie en de bedoelde resolverbescherming op hun plaats terwijl u dit doet. Een tunnel vervangt certificaatvalidatie niet, en het uitschakelen van de beschermingen van een resolver omdat het verkeer via een tunnel loopt, verwijdert een controle zonder die te vervangen.

Kiezen vanuit de eis

Formuleer de werkelijke eis, want die bepaalt het ontwerp. Toegang tot privéresources, een beheerd uitgangspunt, een specifieke dreiging van het toegangsnetwerk en apparaatautorisatie zijn vier verschillende behoeften met vier verschillende antwoorden, en een bedrijf dat alleen openbare cloudapplicaties gebruikt, moet nog steeds autorisatie en gegevensverwerking beslissen. Extra lagen kunnen passend zijn zonder uitwisselbaar te zijn. Een ingewikkelder verbinding is geen anonimiteitsmaat en is op zichzelf geen beveiligingsargument.

De ECH-specificatie, RFC 9849, is de moeite waard om te lezen voor wat het mechanisme wel en niet dekt, en zij is eerlijk over de kanalen die zij met rust laat. Vergelijk de mechanismen op de waarnemer die elk verwijdert, schrijf die waarnemer op en beslis dan of de extra laag hem adresseert. Als het antwoord is dat de waarnemer al buiten uw dreigingsmodel lag, is de tunnel kosten zonder voordeel.