WSS-tunnelens kryptering stopper ved TLS-terminatoren, ikke i appen

En tunnel som fraktes inne i en sikker WebSocket har nøyaktig så mye kryptering som klienten la inn i den, ikke mer. wss://-skjemaet sier at TLS beskytter én forbindelse på ett hopp. Det sier ingenting om hvorvidt bytene inne i WebSocket-meldingene er beskyttet separat, og den forskjellen avgjør hvem som kan lese trafikken din når noe i midten avslutter TLS.

To lag som ser ut som ett

En sikker WebSocket er TLS med et WebSocket-håndtrykk utført over, slik RFC 6455 beskriver i avsnittene om tilkobling og sikkerhet. TLS-laget autentiserer serveren og krypterer strømmen, og deretter rammer WebSocket-laget inn det applikasjonen bestemmer seg for å sende.

Det er to uavhengige beslutninger, og et diagram som tegner én hengelås over hele veien skjuler den andre. Spør hvem som avslutter TLS-forbindelsen. Spør deretter hva klienten legger inni hver melding. Alt annet om utrullingen følger av disse to svarene.

Design A: transporten er den eneste krypteringen

I det enklere designet tar klienten rå IP-pakker og pakker dem inn i WebSocket-meldinger. Ingenting inni er kryptert, så komponenten som holder TLS-økten leser klartekstnyttelast. Når den komponenten er din egen tunnelserver, er dette det tiltenkte endepunktet og designet er konsistent, fordi serveren uansett ville sett trafikken.

Det blir en annen ordning når en inspeksjonsproxy sitter på veien og avslutter TLS med et sertifikat klienten stoler på. Den proxyen holder nå den samme klarteksten som serveren ville holdt, og ingen mengde WebSocket-innramming endrer det. Klientens tillitslager bestemte dette utfallet lenge før tunnelen åpnet, fordi det valgte å godta det sertifikatet for det navnet. Proxyen ser også den forespurte verten og størrelsen på hver melding, noe som er nok til å ta fingeravtrykk av mye aktivitet uten å dekryptere noe mer.

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

I det andre designet krypterer og autentiserer klienten pakkene sine med en VPN-protokoll som har sin egen peer-identitet og nøkkelutveksling, og frakter deretter resultatet inne i WebSocket-meldinger. Å avslutte den ytre TLS-en her eksponerer chiffertekst, ikke trafikk. Proxyen kan se meldingsstørrelser og timing, og ingenting annet i nyttelasten. Det er en mye mindre eksponering, og det er fortsatt metadata som er verdt å nevne i en gjennomgang i stedet for å vinke det bort.

Den indre protokollens egne endepunkter ser fortsatt klartekst, som er poenget med ordningen og også dens grense. Hvis en komponent på endepunktet er autorisert til å lese data før kryptering eller etter dekryptering, begrenser ikke det ekstra laget den. Nøkler, og programvaren som håndterer dem, forblir grensen som betyr noe.

En VPN-etikett, et kjent klientikon eller en markedsføringsside er ikke bevis på at dette designet finnes. Å lese nyttelastformatet er det.

Spor hvor klarteksten faktisk dukker opp

URL-skjemaet gir deg ett faktum, så hent resten fra grensesnittene. Kjør kontrollene nedenfor i rekkefølge, fordi hver av dem snevrer inn den neste:

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

Start med den ytre forbindelsen. Én langvarig TCP-økt til TLS-porten er hvordan en WebSocket-bærer ser ut, og en andre økt til en urelatert vert fortjener en forklaring før du ser dypere. Finn deretter tunnelgrensesnittet på klienten, fordi en tun- eller tap-enhet forteller deg at klienten håndterer IP-pakker i stedet for å proxy én enkelt applikasjonsstrøm.

Opptaket på tunnelgrensesnittet avgjør vanligvis nyttelastspørsmålet. Lesbare headere der betyr at de indre pakkene aldri ble kryptert separat, mens nyttelast med høy entropi betyr at de ble det. Gjenta opptaket på det ytre grensesnittet og sammenlign de to: hvis begge ser tilfeldige ut, gjør det indre laget arbeid som det ytre ikke kan gjøre om.

Gå gjennom tilliten du faktisk ga

Et installert bedriftsrotssertifikat er et faktum om klientens tillitslager, ikke en påstand om hva noen proxy logger eller inspiserer. Fastslå den utrullede policyen og den reelle tilkoblingsveien i stedet for å utlede atferd fra tilstedeværelsen av en CA.

På administrert utstyr, spør administratoren hvilken komponent som avslutter TLS, om klienten validerer et festet sertifikat eller et offentlig, og hva nyttelastformatet er. De tre svarene gir et funn du kan forsvare senere.

Skriv resultatet som en grense i stedet for en dom. "TLS avsluttes ved inspeksjonsproxyen, og den indre nyttelasten er separat kryptert med nøkler bare endepunktene har" er en etterprøvbar påstand som overlever et bytte av leverandør. "WebSockets er sikre" gjør det ikke.