Šifrovanie tunela WSS sa končí na terminátore TLS, nie v aplikácii
Adresa wss:// dokazuje TLS na jednom skoku. Či má užitočné zaťaženie vlastné šifrovanie, závisí od toho, čo klient vloží dovnútra a kto ten TLS ukončí.
Tunel prenášaný vnútri zabezpečeného WebSocketu má presne toľko šifrovania, koľko doňho klient vložil, nie viac. Schéma wss:// hovorí, že TLS chráni jedno spojenie na jednom skoku. Nehovorí nič o tom, či sú bajty vnútri správ WebSocket chránené oddelene, a práve tento rozdiel rozhoduje, kto môže čítať vašu prevádzku, keď niečo v strede ukončí TLS.
Dve vrstvy, ktoré vyzerajú ako jedna
Zabezpečený WebSocket je TLS s podaním ruky WebSocket vykonaným navrchu, ako opisuje RFC 6455 v častiach o spojení a bezpečnosti. Vrstva TLS autentifikuje server a šifruje tok, potom vrstva WebSocket rámuje to, čo sa aplikácia rozhodne poslať.
Sú to dve nezávislé rozhodnutia a diagram, ktorý kreslí jeden zámok na celú cestu, skrýva druhé. Spýtajte sa, kto ukončuje spojenie TLS. Potom sa spýtajte, čo klient vkladá do každej správy. Všetko ostatné o nasadení vyplýva z týchto dvoch odpovedí.
Dizajn A: transport je jediné šifrovanie
V jednoduchšom dizajne klient berie surové IP pakety a zabalí ich do správ WebSocket. Vo vnútri nič nie je šifrované, takže komponent, ktorý drží reláciu TLS, číta obsah v čistom texte. Keď je tým komponentom váš vlastný tunelový server, je to zamýšľaný koncový bod a dizajn je konzistentný, pretože server by prevádzku aj tak videl.
Stane sa z toho iné usporiadanie, keď na ceste sedí inšpekčný proxy a ukončí TLS certifikátom, ktorému klient dôveruje. Ten proxy má teraz ten istý čistý text, aký by mal server, a žiadne množstvo rámovania WebSocket to nezmení. Úložisko dôvery klienta rozhodlo o tomto výsledku dávno pred otvorením tunela, pretože sa rozhodlo prijať ten certifikát pre ten názov. Proxy tiež vidí požadovaný hostiteľ a veľkosť každej správy, čo stačí na odtlačok veľa aktivity bez ďalšieho dešifrovania.
Dizajn B: obsah nesie vlastné kľúče
V druhom dizajne klient šifruje a autentifikuje svoje pakety protokolom VPN, ktorý má vlastnú identitu partnera a výmenu kľúčov, a potom prenáša výsledok v správach WebSocket. Ukončenie vonkajšieho TLS tu odhaľuje šifrovaný text, nie prevádzku. Proxy môže vidieť veľkosti a časy správ a nič iné v obsahu. Je to oveľa menšia expozícia a stále sú to metadáta, ktoré sa oplatí pomenovať v recenzii namiesto odbitia.
Vlastné koncové body vnútorného protokolu stále vidia čistý text, čo je zmysel usporiadania a zároveň jeho hranica. Ak je komponent na koncovom bode oprávnený čítať údaje pred šifrovaním alebo po dešifrovaní, dodatočná vrstva ho neobmedzuje. Kľúče a softvér, ktorý ich spravuje, zostávajú hranicou, na ktorej záleží.
Označenie VPN, známa ikona klienta alebo marketingová stránka nie sú dôkazom, že tento dizajn existuje. Čítanie formátu obsahu je.
Vystopujte, kde sa čistý text skutočne objavuje
Schéma URL vám dáva jeden fakt, takže zvyšok získajte z rozhraní. Spustite kontroly nižšie v poradí, pretože každá zúži nasledujúcu:
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čnite vonkajším spojením. Jedna dlhotrvajúca relácia TCP na port TLS je podoba nosiča WebSocket a druhá relácia na nesúvisiaceho hostiteľa si zaslúži vysvetlenie pred hlbším pohľadom. Potom nájdite tunelové rozhranie na klientovi, pretože zariadenie tun alebo tap hovorí, že klient spracúva IP pakety namiesto proxyovania jedného toku aplikácie.
Zachytávanie na tunelovom rozhraní zvyčajne vyrieši otázku obsahu. Čitateľné hlavičky tam znamenajú, že vnútorné pakety nikdy neboli šifrované oddelene, zatiaľ čo obsah s vysokou entropiou znamená, že boli. Zopakujte zachytávanie na vonkajšom rozhraní a porovnajte obe: ak obe vyzerajú náhodne, vnútorná vrstva robí prácu, ktorú vonkajšia nemôže vrátiť.
Prehodnoťte dôveru, ktorú ste skutočne udelili
Nainštalovaný podnikový koreňový certifikát je fakt o úložisku dôvery klienta, nie tvrdenie o tom, čo akýkoľvek proxy zaznamenáva alebo kontroluje. Stanovte nasadenú politiku a skutočnú cestu spojenia namiesto odvodzovania správania z prítomnosti CA.
Na spravovanom zariadení sa opýtajte správcu, ktorý komponent ukončuje TLS, či klient overuje pripnutý certifikát alebo verejný, a aký je formát obsahu. Tie tri odpovede dávajú zistenie, ktoré môžete neskôr obhájiť.
Napíšte výsledok ako hranicu, nie ako verdikt. „TLS sa končí na inšpekčnom proxy a vnútorný obsah je oddelene šifrovaný kľúčmi, ktoré majú iba koncové body“ je overiteľné tvrdenie, ktoré prežije zmenu dodávateľa. „WebSockets sú bezpečné“ nie.