Krypteringen av WSS-tunneln slutar vid TLS-avslutaren, inte i appen

En tunnel som transporteras inne i en säker WebSocket har exakt så mycket kryptering som klienten la in i den, inte mer. wss://-schemat säger att TLS skyddar en anslutning på ett hopp. Det säger ingenting om huruvida byten inne i WebSocket-meddelandena är skyddade separat, och den skillnaden avgör vem som kan läsa din trafik när något i mitten avslutar TLS.

Två lager som ser ut som ett

En säker WebSocket är TLS med en WebSocket-handskakning utförd ovanpå, som RFC 6455 beskriver i avsnitten om anslutning och säkerhet. TLS-lagret autentiserar servern och krypterar strömmen, sedan ramar WebSocket-lagret in det applikationen bestämmer sig för att skicka.

Det är två oberoende beslut, och ett diagram som ritar ett enda hänglås över hela vägen döljer det andra. Fråga vem som avslutar TLS-anslutningen. Fråga sedan vad klienten lägger inuti varje meddelande. Allt annat om driftsättningen följer av dessa två svar.

Design A: transporten är den enda krypteringen

I den enklare designen tar klienten råa IP-paket och lindar in dem i WebSocket-meddelanden. Inget inuti är krypterat, så komponenten som håller TLS-sessionen läser klartextnyttolast. När den komponenten är din egen tunnelserver är detta den avsedda slutpunkten och designen är sammanhängande, eftersom servern ändå skulle se trafiken.

Det blir en annan ordning när en inspektionsproxy sitter på vägen och avslutar TLS med ett certifikat som klienten litar på. Den proxyn håller nu samma klartext som servern skulle ha hållit, och ingen mängd WebSocket-inramning ändrar det. Klientens förtroendelager avgjorde detta utfall långt innan tunneln öppnades, eftersom det valde att acceptera det certifikatet för det namnet. Proxyn ser också den begärda värden och storleken på varje meddelande, vilket räcker för att ta fingeravtryck på mycket aktivitet utan att dekryptera något mer.

Design B: nyttolasten bär sina egna nycklar

I den andra designen krypterar och autentiserar klienten sina paket med ett VPN-protokoll som har sin egen peer-identitet och nyckelutbyte, och transporterar sedan resultatet inne i WebSocket-meddelanden. Att avsluta den yttre TLS:en här exponerar chiffertext, inte trafik. Proxyn kan se meddelandestorlekar och timing, och ingenting annat i nyttolasten. Det är en mycket mindre exponering, och det är fortfarande metadata som är värt att namnge i en granskning i stället för att vifta bort.

Det inre protokollets egna slutpunkter ser fortfarande klartext, vilket är poängen med ordningen och också dess gräns. Om en komponent på slutpunkten är behörig att läsa data före kryptering eller efter dekryptering, begränsar inte det extra lagret den. Nycklar, och programvaran som hanterar dem, förblir gränsen som spelar roll.

En VPN-etikett, en välbekant klientikon eller en marknadsföringssida är inte bevis för att den här designen finns. Att läsa nyttolastformatet är det.

Spåra var klartexten faktiskt dyker upp

URL-schemat ger dig ett faktum, så hämta resten från gränssnitten. Kör kontrollerna nedan i ordning, eftersom var och en smalnar av nästa:

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

Börja med den yttre anslutningen. En långlivad TCP-session till TLS-porten är hur en WebSocket-bärare ser ut, och en andra session till en orelaterad värd förtjänar en förklaring innan du tittar djupare. Hitta sedan tunnelgränssnittet på klienten, eftersom en tun- eller tap-enhet säger att klienten hanterar IP-paket i stället för att proxy:a en enda applikationsström.

Infångningen på tunnelgränssnittet avgör vanligtvis nyttolastfrågan. Läsbara huvuden där betyder att de inre paketen aldrig krypterades separat, medan nyttolaster med hög entropi betyder att de gjorde det. Upprepa infångningen på det yttre gränssnittet och jämför de två: om båda ser slumpmässiga ut gör det inre lagret arbete som det yttre inte kan ångra.

Granska det förtroende du faktiskt gav

Ett installerat företagsrotcertifikat är ett faktum om klientens förtroendelager, inte ett påstående om vad någon proxy loggar eller inspekterar. Fastställ den utrullade policyn och den verkliga anslutningsvägen i stället för att härleda beteende från närvaron av en CA.

På hanterad utrustning, fråga administratören vilken komponent som avslutar TLS, om klienten validerar ett fäst certifikat eller ett offentligt, och vad nyttolastformatet är. De tre svaren ger en iakttagelse du kan försvara senare.

Skriv resultatet som en gräns i stället för en dom. "TLS avslutas vid inspektionsproxyn, och den inre nyttolasten är separat krypterad med nycklar som bara slutpunkterna har" är ett kontrollerbart påstående som överlever ett byte av leverantör. "WebSockets är säkra" gör det inte.