Šifrování tunelu WSS končí na terminátoru TLS, ne v aplikaci
Adresa wss:// dokazuje TLS na jednom skoku. Zda má užitečné zatížení vlastní šifrování, závisí na tom, co klient vloží dovnitř a kdo ten TLS ukončí.
Tunel přenášený uvnitř zabezpečeného WebSocketu má přesně tolik šifrování, kolik do něj klient vložil, ne více. Schéma wss:// říká, že TLS chrání jedno spojení na jednom skoku. Neříká nic o tom, zda jsou bajty uvnitř zpráv WebSocket chráněny odděleně, a právě tento rozdíl rozhoduje, kdo může číst váš provoz, když něco uprostřed ukončí TLS.
Dvě vrstvy, které vypadají jako jedna
Zabezpečený WebSocket je TLS s podáním ruky WebSocket provedeným navrchu, jak popisuje RFC 6455 v částech o spojení a bezpečnosti. Vrstva TLS autentizuje server a šifruje tok, potom vrstva WebSocket rámuje to, co se aplikace rozhodne poslat.
Jsou to dvě nezávislá rozhodnutí a diagram, který kreslí jeden zámek na celou cestu, skrývá druhé. Zeptejte se, kdo ukončuje spojení TLS. Potom se zeptejte, co klient vkládá do každé zprávy. Vše ostatní o nasazení vyplývá z těchto dvou odpovědí.
Návrh A: přenos je jediné šifrování
V jednodušším návrhu klient bere surové IP pakety a zabalí je do zpráv WebSocket. Uvnitř není nic šifrováno, takže komponenta, která drží relaci TLS, čte obsah v čistém textu. Když je touto komponentou váš vlastní tunelový server, je to zamýšlený koncový bod a návrh je konzistentní, protože server by provoz stejně viděl.
Stane se z toho jiné uspořádání, když na cestě sedí inspekční proxy a ukončí TLS certifikátem, kterému klient důvěřuje. Ta proxy má nyní stejný čistý text, jaký by měl server, a žádné množství rámování WebSocket to nezmění. Úložiště důvěry klienta rozhodlo o tomto výsledku dávno před otevřením tunelu, protože se rozhodlo přijmout ten certifikát pro to jméno. Proxy také vidí požadovaný hostitel a velikost každé zprávy, což stačí k otisku mnoha aktivit bez dalšího dešifrování.
Návrh B: obsah nese vlastní klíče
Ve druhém návrhu klient šifruje a autentizuje své pakety protokolem VPN, který má vlastní identitu partnera a výměnu klíčů, a potom přenáší výsledek ve zprávách WebSocket. Ukončení vnějšího TLS zde odhaluje šifrovaný text, ne provoz. Proxy může vidět velikosti a časy zpráv a nic jiného v obsahu. To je mnohem menší expozice, a přesto jsou to metadata, která stojí za to pojmenovat v recenzi místo odbytí.
Vlastní koncové body vnitřního protokolu stále vidí čistý text, což je smysl uspořádání a zároveň jeho hranice. Pokud je komponenta na koncovém bodu oprávněna číst data před šifrováním nebo po dešifrování, dodatečná vrstva ji neomezuje. Klíče a software, který je spravuje, zůstávají hranicí, na které záleží.
Označení VPN, známá ikona klienta nebo marketingová stránka nejsou důkazem, že tento návrh existuje. Čtení formátu obsahu je.
Vystopujte, kde se čistý text skutečně objevuje
Schéma URL vám dává jeden fakt, takže zbytek získejte z rozhraní. Spusťte níže uvedené kontroly v pořadí, protože každá zužuje následující:
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
Začněte vnějším spojením. Jedna dlouhotrvající relace TCP na port TLS je podoba nosiče WebSocket a druhá relace na nesouvisejícího hostitele si zaslouží vysvětlení před hlubším pohledem. Potom najděte tunelové rozhraní na klientovi, protože zařízení tun nebo tap říká, že klient zpracovává IP pakety namísto proxyování jednoho toku aplikace.
Zachytávání na tunelovém rozhraní obvykle vyřeší otázku obsahu. Čitelné hlavičky tam znamenají, že vnitřní pakety nikdy nebyly šifrovány odděleně, zatímco obsah s vysokou entropií znamená, že byly. Zopakujte zachytávání na vnějším rozhraní a porovnejte oba: pokud oba vypadají náhodně, vnitřní vrstva dělá práci, kterou vnější nemůže vrátit.
Přezkoumejte důvěru, kterou jste skutečně udělili
Nainstalovaný podnikový kořenový certifikát je fakt o úložišti důvěry klienta, ne tvrzení o tom, co jakákoli proxy zaznamenává nebo kontroluje. Stanovte nasazenou politiku a skutečnou cestu spojení místo odvozování chování z přítomnosti CA.
Na spravovaném zařízení se zeptejte správce, která komponenta ukončuje TLS, zda klient ověřuje připnutý certifikát nebo veřejný, a jaký je formát obsahu. Ty tři odpovědi dávají zjištění, které můžete později obhájit.
Napište výsledek jako hranici, ne jako verdikt. „TLS končí na inspekční proxy a vnitřní obsah je odděleně šifrovaný klíči, které mají jen koncové body" je ověřitelné tvrzení, které přežije změnu dodavatele. „WebSockets jsou bezpečné" ne.