Krypteringen af WSS-tunnelen stopper ved TLS-terminatoren, ikke i appen

En tunnel, der transporteres inde i en sikker WebSocket, har præcis så meget kryptering, som klienten lagde i den, ikke mere. wss://-skemaet siger, at TLS beskytter én forbindelse på et hop. Det siger intet om, hvorvidt bytes inde i WebSocket-beskederne er beskyttet separat, og den forskel afgør, hvem der kan læse din trafik, når noget i midten afslutter TLS.

To lag, der ser ud som ét

En sikker WebSocket er TLS med et WebSocket-håndtryk udført ovenpå, som RFC 6455 beskriver i afsnittene om forbindelse og sikkerhed. TLS-laget autentificerer serveren og krypterer strømmen, derefter indrammer WebSocket-laget det, applikationen beslutter at sende.

Det er to uafhængige beslutninger, og et diagram, der tegner én hængelås over hele vejen, skjuler den anden. Spørg, hvem der afslutter TLS-forbindelsen. Spørg derefter, hvad klienten lægger indeni hver besked. Alt andet om udrulningen følger af disse to svar.

Design A: transporten er den eneste kryptering

I det enklere design tager klienten rå IP-pakker og pakker dem ind i WebSocket-beskeder. Intet indeni er krypteret, så komponenten, der holder TLS-sessionen, læser klartekstnyttelast. Når den komponent er din egen tunnelserver, er dette det tilsigtede endepunkt, og designet er sammenhængende, fordi serveren alligevel ville se trafikken.

Det bliver en anden ordning, når en inspektionsproxy sidder på vejen og afslutter TLS med et certifikat, som klienten stoler på. Den proxy holder nu den samme klartekst, som serveren ville have holdt, og ingen mængde WebSocket-indramning ændrer det. Klientens tillidslager besluttede dette resultat længe før, tunnelen blev åbnet, fordi det valgte at acceptere det certifikat til det navn. Proxyen ser også den anmodede vært og størrelsen på hver besked, hvilket er nok til at tage fingeraftryk af meget aktivitet uden at dekryptere noget yderligere.

Design B: nyttelasten bærer sine egne nøgler

I det andet design krypterer og autentificerer klienten sine pakker med en VPN-protokol, der har sin egen peer-identitet og nøgleudveksling, og transporterer derefter resultatet inde i WebSocket-beskeder. At afslutte den ydre TLS her eksponerer chiffertekst, ikke trafik. Proxyen kan se beskedstørrelser og timing, og intet andet i nyttelasten. Det er en meget mindre eksponering, og det er stadig metadata, der er værd at nævne i en gennemgang i stedet for at feje væk.

Den indre protokols egne endepunkter ser stadig klartekst, hvilket er pointen med ordningen og også dens grænse. Hvis en komponent på endepunktet er autoriseret til at læse data før kryptering eller efter dekryptering, begrænser det ekstra lag den ikke. Nøgler, og softwaren der håndterer dem, forbliver grænsen, der betyder noget.

Et VPN-mærke, et velkendt klientikon eller en marketingside er ikke bevis på, at dette design findes. At læse nyttelastformatet er det.

Spor, hvor klarteksten faktisk dukker op

URL-skemaet giver dig ét faktum, så hent resten fra grænsefladerne. Kør kontrollerne nedenfor i rækkefølge, fordi hver af dem indsnævrer den næste:

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

Begynd med den ydre forbindelse. Én langlivet TCP-session til TLS-porten er, hvordan en WebSocket-bærer ser ud, og en anden session til en urelateret vært fortjener en forklaring, før du kigger dybere. Find derefter tunnelgrænsefladen på klienten, fordi en tun- eller tap-enhed fortæller dig, at klienten håndterer IP-pakker i stedet for at proxy en enkelt applikationsstrøm.

Optagelsen på tunnelgrænsefladen afgør normalt nyttelastspørgsmålet. Læsbare headers der betyder, at de indre pakker aldrig blev krypteret separat, mens nyttelast med høj entropi betyder, at de blev det. Gentag optagelsen på den ydre grænseflade, og sammenlign de to: hvis begge ser tilfældige ud, gør det indre lag arbejde, som det ydre ikke kan gøre om.

Gennemgå den tillid, du faktisk gav

Et installeret virksomhedsrodcertifikat er et faktum om klientens tillidslager, ikke en påstand om, hvad nogen proxy logger eller inspicerer. Fastslå den udrullede politik og den reelle forbindelsesvej i stedet for at udlede adfærd ud fra tilstedeværelsen af en CA.

På administreret udstyr, spørg administratoren, hvilken komponent der afslutter TLS, om klienten validerer et fastgjort certifikat eller et offentligt, og hvad nyttelastformatet er. De tre svar giver en konstatering, du kan forsvare senere.

Skriv resultatet som en grænse i stedet for en dom. "TLS afsluttes ved inspektionsproxyen, og den indre nyttelast er separat krypteret med nøgler, som kun endepunkterne har" er en efterprøvbar påstand, der overlever et skift af leverandør. "WebSockets er sikre" gør det ikke.