WSS enkripcija tunela završava na TLS terminatoru, ne u aplikaciji
wss:// URL dokazuje TLS na jednom skoku. Ima li korisni teret vlastito šifriranje ovisi o tome što klijent stavlja unutra i tko prekida taj TLS.
Tunel prenesen unutar sigurnog WebSocketa ima točno onoliko šifriranja koliko je klijent stavio u njega, ni više. Shema wss:// kaže da TLS štiti jednu vezu na jednom skoku. Ne kaže ništa o tome jesu li bajtovi unutar WebSocket poruka zasebno zaštićeni, a ta razlika odlučuje tko može čitati vaš promet kada nešto u sredini prekine TLS.
Dva sloja koja izgledaju kao jedan
Sigurni WebSocket je TLS preko kojeg se izvodi WebSocket rukovanje, kako RFC 6455 opisuje u odjeljcima o vezi i sigurnosti. TLS sloj autentificira poslužitelj i šifrira tok, a zatim WebSocket sloj uokviruje sve što aplikacija odluči poslati.
To su dvije neovisne odluke, a dijagram koji crta jedan lokot preko cijelog puta skriva drugu. Pitajte tko prekida TLS vezu. Zatim pitajte što klijent stavlja unutar svake poruke. Sve ostalo o postavljanju proizlazi iz ta dva odgovora.
Dizajn A: prijenos je jedino šifriranje
U jednostavnijem dizajnu klijent uzima sirove IP pakete i umotava ih u WebSocket poruke. Unutra ništa nije šifrirano, pa komponenta koja drži TLS sesiju čita otvorene korisne terete. Kada je ta komponenta vaš vlastiti tunelski poslužitelj, to je predviđena krajnja točka i dizajn je koherentan, jer je poslužitelj ionako trebao vidjeti promet.
To postaje drugačiji raspored kada se na putu nađe proksi za inspekciju i prekine TLS certifikatom kojem klijent vjeruje. Taj proksi sada drži isti otvoreni tekst koji bi držao poslužitelj, i nikakva količina WebSocket uokvirivanja to ne mijenja. Skladište povjerenja klijenta odlučilo je ovaj ishod mnogo prije nego što se tunel otvorio, jer je odlučilo prihvatiti taj certifikat za to ime. Proksi također vidi traženi host i veličinu svake poruke, što je dovoljno da se uzme otisak mnogih aktivnosti bez daljnjeg dešifriranja.
Dizajn B: teret nosi vlastite ključeve
U drugom dizajnu klijent šifrira i autentificira svoje pakete VPN protokolom koji ima vlastiti identitet partnera i razmjenu ključeva, a zatim prenosi rezultat unutar WebSocket poruka. Prekidanje vanjskog TLS-a ovdje izlaže šifrirani tekst, a ne promet. Proksi može vidjeti veličine poruka i vrijeme, i ništa drugo u teretu. To je mnogo manja izloženost, i to su još uvijek metapodaci koje vrijedi imenovati u pregledu umjesto odmahivanja rukom.
Vlastite krajnje točke unutarnjeg protokola još uvijek vide otvoreni tekst, što je smisao rasporeda i ujedno njegova granica. Ako je komponenta na krajnjoj točki ovlaštena čitati podatke prije šifriranja ili nakon dešifriranja, dodatni sloj je ne ograničava. Ključevi i softver koji njima upravlja ostaju granica koja je važna.
VPN oznaka, poznata ikona klijenta ili marketinška stranica nisu dokaz da ovaj dizajn postoji. Čitanje formata tereta jest.
Pratite gdje se otvoreni tekst zapravo pojavljuje
Shema URL-a daje vam jednu činjenicu, pa ostatak uzmite iz sučelja. Pokrenite provjere ispod redom, jer svaka sužava sljedeću:
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
Počnite s vanjskom vezom. Jedna dugotrajna TCP sesija na TLS port izgleda kao WebSocket nosač, a druga sesija na nepovezani host zaslužuje objašnjenje prije nego što pogledate dublje. Zatim pronađite tunelsko sučelje na klijentu, jer tun ili tap uređaj govori da klijent obrađuje IP pakete umjesto da proksira jedan aplikacijski tok.
Snimanje na tunelskom sučelju obično rješava pitanje tereta. Čitljiva zaglavlja tamo znače da unutarnji paketi nikada nisu bili zasebno šifrirani, dok tereti visoke entropije znače da jesu. Ponovite snimanje na vanjskom sučelju i usporedite oba: ako oba izgledaju nasumično, unutarnji sloj radi posao koji vanjski ne može poništiti.
Pregledajte povjerenje koje ste doista dali
Instalirani korporativni korijenski certifikat činjenica je o skladištu povjerenja klijenta, a ne izjava o tome što bilo koji proksi bilježi ili pregledava. Utvrdite primijenjenu politiku i stvarni put veze umjesto da zaključujete ponašanje iz prisutnosti CA.
Na upravljanim uređajima pitajte administratora koja komponenta prekida TLS, provjerava li klijent prikvačeni certifikat ili javni, i koji je format tereta. Ta tri odgovora daju nalaz koji možete kasnije braniti.
Zapišite rezultat kao granicu, a ne kao presudu. "TLS se prekida na proksiju za inspekciju, a unutarnji teret je zasebno šifriran ključevima koje drže samo krajnje točke" provjerljiva je tvrdnja koja preživljava promjenu dobavljača. "WebSockets su sigurni" ne.