Krypteringa av WSS-tunnelen stoppar ved TLS-terminatoren, ikkje i appen

Ein tunnel som blir frakta inne i ein sikker WebSocket har nøyaktig så mykje kryptering som klienten la inn i han, ikkje meir. wss://-skjemaet seier at TLS vernar éi tilkobling på eitt hopp. Det seier ingenting om byta inne i WebSocket-meldingane er verna separat, og den skilnaden avgjer kven som kan lese trafikken din når noko i midten avsluttar TLS.

To lag som ser ut som eitt

Ein sikker WebSocket er TLS med eit WebSocket-handtrykk utført over, slik RFC 6455 skildrar i avsnitta om tilkobling og tryggleik. TLS-laget autentiserer tenaren og krypterer straumen, og deretter rammar WebSocket-laget inn det applikasjonen bestemmer seg for å sende.

Det er to uavhengige avgjerder, og eit diagram som teiknar éin hengelås over heile vegen skjuler den andre. Spør kven som avsluttar TLS-tilkoblinga. Spør deretter kva klienten legg inni kvar melding. Alt anna om utrullinga følgjer av desse to svara.

Design A: transporten er den einaste krypteringa

I det enklare designet tar klienten rå IP-pakkar og pakkar dei inn i WebSocket-meldingar. Ingenting inni er kryptert, så komponenten som held TLS-økta les klartekstnyttelast. Når den komponenten er din eigen tunnelserver, er dette det tiltenkte endepunktet og designet er konsistent, fordi tenaren uansett ville sett trafikken.

Det blir ei anna ordning når ein inspeksjonsproxy sit på vegen og avsluttar TLS med eit sertifikat klienten stolar på. Den proxyen held no den same klarteksten som tenaren ville halde, og inga mengd WebSocket-innramming endrar det. Tillitslageret til klienten bestemte dette utfallet lenge før tunnelen opna, fordi det valde å godta det sertifikatet for det namnet. Proxyen ser også den førespurde verten og storleiken på kvar melding, noko som er nok til å ta fingeravtrykk av mykje aktivitet utan å dekryptere noko meir.

Design B: nyttelasta ber sine eigne nøklar

I det andre designet krypterer og autentiserer klienten pakkane sine med ein VPN-protokoll som har sin eigen peer-identitet og nøkkelutveksling, og fraktar deretter resultatet inne i WebSocket-meldingar. Å avslutte den ytre TLS-en her eksponerer chiffertekst, ikkje trafikk. Proxyen kan sjå meldingsstorleikar og timing, og ingenting anna i nyttelasta. Det er ei mykje mindre eksponering, og det er framleis metadata som er verdt å nemne i ein gjennomgang i staden for å vinke det bort.

Dei indre protokollendepunkta ser framleis klartekst, som er poenget med ordninga og også grensa hennar. Viss ein komponent på endepunktet er autorisert til å lese data før kryptering eller etter dekryptering, avgrensar ikkje det ekstra laget han. Nøklar, og programvara som handterer dei, blir verande grensa som betyr noko.

Ei VPN-etikett, eit kjent klientikon eller ei marknadsføringsside er ikkje prov på at dette designet finst. Å lese nyttelastformatet er det.

Spor kvar klarteksten faktisk dukkar opp

URL-skjemaet gir deg eitt faktum, så hent resten frå grensesnitta. Køyr kontrollane nedanfor i rekkjefølgje, fordi kvar av dei snevrar 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 tilkoblinga. Éi langvarig TCP-økt til TLS-porten er korleis ein WebSocket-berar ser ut, og ei andre økt til ein urelatert vert fortener ei forklaring før du ser djupare. Finn deretter tunnelgrensesnittet på klienten, fordi ein tun- eller tap-eining fortel deg at klienten handterer IP-pakkar i staden for å proxy éin einaste applikasjonsstraum.

Opptaket på tunnelgrensesnittet avgjer vanlegvis nyttelastspørsmålet. Lesbare headers der betyr at dei indre pakkane aldri vart krypterte separat, medan nyttelast med høg entropi betyr at dei vart det. Gjenta opptaket på det ytre grensesnittet og samanlikn dei to: viss begge ser tilfeldige ut, gjer det indre laget arbeid som det ytre ikkje kan gjere om.

Gå gjennom tilliten du faktisk gav

Eit installert bedriftsrotsertifikat er eit faktum om tillitslageret til klienten, ikkje ein påstand om kva nokon proxy loggar eller inspiserer. Fastset den utrulla politikken og den reelle tilkoblingsvegen i staden for å utleie åtferd frå at ein CA finst.

På administrert utstyr, spør administratoren kva komponent som avsluttar TLS, om klienten validerer eit festa sertifikat eller eit offentleg, og kva nyttelastformatet er. Dei tre svara gir eit funn du kan forsvare seinare.

Skriv resultatet som ei grense i staden for ein dom. "TLS avsluttast ved inspeksjonsproxyen, og den indre nyttelasta er separat kryptert med nøklar berre endepunkta har" er ein etterprøvbar påstand som overlever eit byte av leverandør. "WebSockets er trygge" gjer det ikkje.