A WSS-alagút titkosítása a TLS-terminátornál ér véget, nem az alkalmazásnál

A biztonságos WebSocketben szállított alagút pontosan annyi titkosítással rendelkezik, amennyit a kliens beletett, és nem többel. A wss:// séma azt mondja, hogy a TLS egy kapcsolatot véd egy ugrásban. Semmit sem mond arról, hogy a WebSocket-üzeneteken belüli bájtok külön védettek-e, és ez a különbség dönti el, ki tudja olvasni a forgalmat, amikor valami középen befejezi a TLS-t.

Két réteg, amely egynek látszik

A biztonságos WebSocket TLS, amelyen WebSocket-kézfogás történik, ahogy az RFC 6455 a kapcsolatról és a biztonságról szóló szakaszaiban leírja. A TLS-réteg hitelesíti a szervert és titkosítja a folyamot, majd a WebSocket-réteg keretezi azt, amit az alkalmazás küldeni dönt.

Ez két független döntés, és az a diagram, amely egyetlen lakatot rajzol az egész útra, elrejti a másodikat. Kérdezze meg, ki fejezi be a TLS-kapcsolatot. Aztán kérdezze meg, mit tesz a kliens az egyes üzenetekbe. Minden más az üzembe helyezésről ebből a két válaszból következik.

A terv: a szállítás az egyetlen titkosítás

Az egyszerűbb tervben a kliens nyers IP-csomagokat vesz és WebSocket-üzenetekbe csomagolja őket. Belül semmi nincs titkosítva, így a TLS-munkamenetet tartó komponens nyílt szövegű terheket olvas. Amikor ez a komponens a saját alagútszerver, ez a szándékolt végpont, és a terv koherens, mert a szerver úgyis látta volna a forgalmat.

Ez más elrendezéssé válik, amikor egy vizsgáló proxy ül az útvonalon, és olyan tanúsítvánnyal fejezi be a TLS-t, amelyben a kliens megbízik. Ez a proxy most ugyanazt a nyílt szöveget tartja, amelyet a szerver tartott volna, és a WebSocket-keretezés semmilyen mennyisége nem változtat ezen. A kliens bizalmi tárolója jóval az alagút megnyitása előtt eldöntötte ezt az eredményt, mert úgy döntött, hogy elfogadja azt a tanúsítványt ahhoz a névhez. A proxy azt is látja, milyen gazdagépet kértek, és mekkora az egyes üzenetek mérete, ami elég ahhoz, hogy sok tevékenységről ujjlenyomatot vegyen anélkül, hogy bármi továbbit visszafejtené.

B terv: a teher a saját kulcsait hordozza

A második tervben a kliens VPN-protokollal titkosítja és hitelesíti csomagjait, amelynek saját partnere-identitása és kulcscseréje van, majd az eredményt WebSocket-üzenetekben szállítja. A külső TLS befejezése itt titkosított szöveget tár fel, nem forgalmat. A proxy láthatja az üzenetméreteket és az időzítést, és semmi mást a teherből. Ez sokkal kisebb kitettség, és még mindig olyan metaadat, amelyet egy felülvizsgálatban meg kell nevezni ahelyett, hogy félresöpörnék.

A belső protokoll saját végpontjai továbbra is nyílt szöveget látnak, ez az elrendezés lényege és egyben a korlátja. Ha a végponton egy komponens jogosult adatot olvasni a titkosítás előtt vagy a visszafejtés után, a kiegészítő réteg nem korlátozza. A kulcsok és az őket kezelő szoftver marad az a határ, amely számít.

A VPN-címke, egy ismerős kliensikon vagy egy marketingoldal nem bizonyíték arra, hogy ez a terv létezik. A teher formátumának elolvasása az.

Kövesse nyomon, hol jelenik meg valójában a nyílt szöveg

Az URL-séma egy tényt ad, a többit az interfészekből szerezze be. Futtassa az alábbi ellenőrzéseket sorrendben, mert mindegyik szűkíti a következőt:

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

Kezdje a külső kapcsolattal. Egy hosszú életű TCP-munkamenet a TLS-porthoz az, ahogy egy WebSocket-hordozó kinéz, és egy második munkamenet egy nem kapcsolódó gazdagéphez magyarázatot érdemel, mielőtt mélyebbre nézne. Aztán keresse meg az alagút-interfészt a kliensen, mert egy tun vagy tap eszköz azt mondja, hogy a kliens IP-csomagokat kezel, nem pedig egyetlen alkalmazásfolyamot proxizik.

Az alagút-interfészen végzett rögzítés általában eldönti a teher kérdését. Az ott olvasható fejlécek azt jelentik, hogy a belső csomagokat soha nem titkosították külön, míg a nagy entrópiájú terhek azt, hogy igen. Ismételje meg a rögzítést a külső interfészen, és hasonlítsa össze a kettőt: ha mindkettő véletlenszerűnek tűnik, a belső réteg olyan munkát végez, amelyet a külső nem tud visszafordítani.

Vizsgálja felül a ténylegesen adott bizalmat

A telepített vállalati főtanúsítvány tény a kliens bizalmi tárolójáról, nem állítás arról, hogy bármely proxy mit naplóz vagy vizsgál. Állapítsa meg a telepített szabályzatot és a valódi kapcsolati útvonalat, ahelyett hogy viselkedést következtetne ki egy hitelesítésszolgáltató jelenlétéből.

Kezelt eszközökön kérdezze meg az admint, melyik komponens fejezi be a TLS-t, a kliens rögzített vagy nyilvános tanúsítványt ellenőriz-e, és mi a teher formátuma. Ez a három válasz olyan megállapítást ad, amelyet később meg tud védeni.

Az eredményt határként írja le, nem ítéletként. „A TLS a vizsgáló proxynál ér véget, és a belső teher külön titkosított, olyan kulcsokkal, amelyek csak a végpontoknál vannak” ellenőrizhető állítás, amely túlél egy szállítóváltást. „A WebSocketek biztonságosak” nem.