De versleuteling van de WSS-tunnel stopt bij de TLS-terminator, niet in de app

Een tunnel die in een beveiligde WebSocket wordt vervoerd, heeft precies zoveel versleuteling als de client erin heeft gestopt, niet meer. Het wss://-schema zegt dat TLS één verbinding op één hop beschermt. Het zegt niets over de vraag of de bytes in de WebSocket-berichten apart zijn beschermd, en dat onderscheid bepaalt wie uw verkeer kan lezen wanneer iets in het midden de TLS beëindigt.

Twee lagen die er als één uitzien

Een beveiligde WebSocket is TLS met een WebSocket-handshake eroverheen, zoals RFC 6455 beschrijft in zijn secties over verbinding en beveiliging. De TLS-laag authenticeert de server en versleutelt de stream, en dan kadert de WebSocket-laag wat de applicatie besluit te versturen.

Dat zijn twee onafhankelijke beslissingen, en een diagram dat één slot over het hele pad tekent, verbergt de tweede. Vraag wie de TLS-verbinding beëindigt. Vraag dan wat de client in elk bericht stopt. Al het andere over de uitrol volgt uit die twee antwoorden.

Ontwerp A: het transport is de enige versleuteling

In het eenvoudigere ontwerp neemt de client ruwe IP-pakketten en wikkelt ze in WebSocket-berichten. Niets binnenin is versleuteld, dus het onderdeel dat de TLS-sessie heeft, leest payloads als platte tekst. Wanneer dat onderdeel uw eigen tunnelserver is, is dit het bedoelde eindpunt en is het ontwerp samenhangend, want de server zou het verkeer toch zien.

Het wordt een andere opstelling wanneer een inspectieproxy op het pad zit en de TLS beëindigt met een certificaat dat de client vertrouwt. Die proxy heeft nu dezelfde platte tekst als de server zou hebben gehad, en geen enkele hoeveelheid WebSocket-kadrering verandert dat. De vertrouwensopslag van de client besliste dit resultaat lang voordat de tunnel openging, omdat hij ervoor koos dat certificaat voor die naam te accepteren. De proxy ziet ook de gevraagde host en de grootte van elk bericht, wat genoeg is om veel activiteit te vingerafdrukken zonder verder nog iets te ontsleutelen.

Ontwerp B: de payload draagt zijn eigen sleutels

In het tweede ontwerp versleutelt en authenticeert de client zijn pakketten met een VPN-protocol dat zijn eigen peer-identiteit en sleuteluitwisseling heeft, en vervoert vervolgens het resultaat in WebSocket-berichten. Het beëindigen van de buitenste TLS hier legt cijfertekst bloot, geen verkeer. De proxy kan berichtgroottes en timing zien, en niets anders in de payload. Dat is een veel kleinere blootstelling, en het zijn nog steeds metadata die het vermelden waard zijn in een beoordeling in plaats van weg te wuiven.

De eigen eindpunten van het binnenste protocol zien nog steeds platte tekst, wat het punt van de opstelling is en ook de grens ervan. Als een onderdeel op het eindpunt bevoegd is om gegevens te lezen vóór versleuteling of na ontsleuteling, beperkt de extra laag dat niet. Sleutels, en de software die ze beheert, blijven de grens die ertoe doet.

Een VPN-label, een vertrouwd clientpictogram of een marketingpagina is geen bewijs dat dit ontwerp bestaat. Het payloadformaat lezen is dat wel.

Volg waar de platte tekst echt verschijnt

Het URL-schema geeft u één feit, dus haal de rest uit de interfaces. Voer de controles hieronder in volgorde uit, want elk ervan vernauwt de volgende:

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

Begin met de buitenste verbinding. Eén langdurige TCP-sessie naar de TLS-poort is hoe een WebSocket-drager eruitziet, en een tweede sessie naar een niet-verwante host verdient uitleg voordat u dieper kijkt. Zoek dan de tunnelinterface op de client, want een tun- of tap-apparaat vertelt u dat de client IP-pakketten verwerkt in plaats van één applicatiestroom te proxyen.

De capture op de tunnelinterface beslecht meestal de payloadvraag. Leesbare headers daar betekenen dat de binnenste pakketten nooit apart zijn versleuteld, terwijl payloads met hoge entropie betekenen dat ze dat wel zijn. Herhaal de capture op de buitenste interface en vergelijk de twee: als beide willekeurig lijken, doet de binnenste laag werk dat de buitenste niet ongedaan kan maken.

Beoordeel het vertrouwen dat u werkelijk hebt gegeven

Een geïnstalleerd bedrijfswortelcertificaat is een feit over de vertrouwensopslag van de client, geen bewering over wat een proxy logt of inspecteert. Stel het uitgerolde beleid en het werkelijke verbindingspad vast in plaats van gedrag af te leiden uit de aanwezigheid van een CA.

Op beheerde apparatuur, vraag de beheerder welk onderdeel de TLS beëindigt, of de client een vastgepind certificaat of een openbaar certificaat valideert, en wat het payloadformaat is. Die drie antwoorden leveren een bevinding op die u later kunt verdedigen.

Schrijf het resultaat als een grens in plaats van een oordeel. "TLS eindigt bij de inspectieproxy, en de binnenste payload is apart versleuteld met sleutels die alleen de eindpunten hebben" is een controleerbare uitspraak die een leverancierswissel overleeft. "WebSockets zijn veilig" niet.