WSS enkripcija tunela prestaje na TLS terminatoru, ne u aplikaciji
wss:// URL dokazuje TLS na jednom skoku. Ima li korisni teret vlastitu enkripciju zavisi od toga šta klijent stavlja unutra i ko prekida taj TLS.
Tunel prenesen unutar sigurnog WebSocketa ima tačno onoliko enkripcije koliko je klijent u njega stavio, ni više. Shema wss:// kaže da TLS štiti jednu vezu na jednom skoku. Ne govori ništa o tome da li su bajtovi unutar WebSocket poruka posebno zaštićeni, a upravo ta razlika odlučuje ko može čitati vaš saobraćaj kada nešto u sredini prekine TLS.
Dva sloja koja izgledaju kao jedan
Sigurni WebSocket je TLS preko kojeg se obavlja WebSocket rukovanje, kako RFC 6455 opisuje u odjeljcima o vezi i sigurnosti. TLS sloj autentificira server i šifrira tok, a zatim WebSocket sloj uokviruje sve što aplikacija odluči poslati.
To su dvije nezavisne odluke, a dijagram koji crta jedan katanac preko cijelog puta skriva drugu. Pitajte ko prekida TLS vezu. Zatim pitajte šta klijent stavlja unutar svake poruke. Sve ostalo o postavljanju proizlazi iz ta dva odgovora.
Dizajn A: transport je jedina enkripcija
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 server, to je predviđena krajnja točka i dizajn je koherentan, jer je server ionako trebao vidjeti saobraćaj.
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 server, 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 daljeg dešifriranja.
Dizajn B: korisni 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, ne saobraćaj. 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 odmahnuti rukom.
Vlastite krajnje točke unutrašnjeg 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 enkripcije ili poslije 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 zaista pojavljuje
Shema URL-a daje vam jednu činjenicu, pa ostatak uzmite iz interfejsa. 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 tunelski interfejs na klijentu, jer tun ili tap uređaj govori da klijent obrađuje IP pakete umjesto da proksira jedan aplikacijski tok.
Snimanje na tunelskom interfejsu obično rješava pitanje tereta. Čitljiva zaglavlja tamo znače da unutrašnji paketi nikada nisu bili posebno šifrirani, dok tereti visoke entropije znače da jesu. Ponovite snimanje na vanjskom interfejsu i uporedite oba: ako oba izgledaju nasumično, unutrašnji sloj radi posao koji vanjski ne može poništiti.
Pregledajte povjerenje koje ste zaista dali
Instalirani korporativni korijenski certifikat je činjenica o skladištu povjerenja klijenta, a ne izjava o tome šta bilo koji proksi bilježi ili pregleda. Utvrdite primijenjenu politiku i stvarnu putanju veze umjesto da izvodite ponašanje iz prisustva CA.
Na upravljanim uređajima pitajte administratora koja komponenta prekida TLS, da li klijent provjerava prikovani 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 unutrašnji teret je posebno šifriran ključevima koje drže samo krajnje točke" je provjerljiva tvrdnja koja preživljava promjenu dobavljača. "WebSockets su sigurni" ne.