Fersifering fan WSS-tunnels einiget by de TLS-terminator, net by de app

In tunnel dy't yn in befeilige WebSocket ferfierd wurdt, hat krekt safolle fersifering as de klient der yn set hat, net mear. It skema wss:// seit dat TLS ien ferbining op ien hop beskermet. It seit neat oer oft de bytes yn 'e WebSocket-berjochten apart beskerme wurde, en dy ûnderskied beslút wa't jo ferkear lêze kin as eat yn 'e midden TLS beëiniget.

Twa lagen dy't as ien lykje

In befeilige WebSocket is TLS mei in WebSocket-hânskodzjen der oer, sa't RFC 6455 it beskriuwt yn syn seksjes oer ferbining en feiligens. De TLS-laach autentisearret de tsjinner en fersiferelet de stream, en dan framed de WebSocket-laach wat de applikaasje beslút te stjoeren.

Dat binne twa ûnôfhinklike beslissingen, en in diagram dat ien slot oer it hiele paad tekenet, ferberget de twadde. Freegje wa't de TLS-ferbining beëiniget. Freegje dan wat de klient yn elk berjocht set. Al it oare oer de ynset folget út dy twa antwurden.

Untwerp A: it ferfier is de iennige fersifering

Yn it ienfâldiger ûntwerp nimt de klient rauwe IP-pakketten en wikkelt se yn WebSocket-berjochten. Neat binnen is fersifere, dus de komponint dy't de TLS-sesje hâldt, lêst platte-tekst-payloads. As dy komponint jo eigen tunnelserver is, is dit it bedoelde einpunt en is it ûntwerp gearhingjend, want de tsjinner soe it ferkear dochs al sjen.

It wurdt in oare regeling as in ynspeksjeproxy op it paad sit en TLS beëiniget mei in sertifikaat dat de klient fertrout. Dy proxy hâldt no deselde platte tekst dy't de tsjinner hâlden hie, en gjin mjitte fan WebSocket-framing feroaret dat. De fertrouwensopslach fan 'e klient besleat dit resultaat lang foar't de tunnel iepene, want hy keas dat sertifikaat foar dy namme te akseptearjen. De proxy sjocht ek de frege host en de grutte fan elk berjocht, wat genôch is om in soad aktiviteit te fingerprinten sûnder fierders eat te ûntsiferjen.

Untwerp B: de payload draacht syn eigen kaaien

Yn it twadde ûntwerp fersiferelet en autentisearret de klient syn pakketten mei in VPN-protokol dat syn eigen peer-identiteit en kaai-útwikseling hat, en ferfierret dan it resultaat yn WebSocket-berjochten. It beëinigjen fan 'e bûtenste TLS hjir bleatleit sifertekst, net ferkear. De proxy kin berjochtsgrutten en tiid sjen, en neat oars yn 'e payload. Dat is in folle lytsere bleatstelling, en it is noch altyd metadata dy't it neamen wurdich is yn in resinsje ynstee fan it fuort te wiuwen.

De eigen einpunten fan it ynderlike protokol sjogge noch platte tekst, dat is it punt fan 'e regeling en ek har grins. As in komponint op it einpunt autorisearre is om gegevens te lêzen foar fersifering of nei ûntsifering, beheint de ekstra laach it net. Kaaien, en de software dy't se behannelt, bliuwe de grins dy't fan belang is.

In VPN-label, in fertroud kliïntpictogram of in marketingpagina binne gjin bewiis dat dit ûntwerp bestiet. It lêzen fan it payload-formaat is dat.

Folgje wêr't de platte tekst echt ferskynt

It URL-skema jout jo ien feit, dus helje de rest út 'e ynterfaces. Rin de kontrôles hjirûnder yn folchoarder, want elk ferpylet de folgjende:

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

Begjin mei de bûtenste ferbining. Ien langlibbene TCP-sesje nei de TLS-poarte is hoe't in WebSocket-drager der útsjocht, en in twadde sesje nei in net-relatearre host fertsjinnet in taljochting foar't jo djipper sjogge. Fyn dan de tunnelinterface op 'e klient, want in tun- of tap-apparaat fertelt jo dat de klient IP-pakketten behannelt ynstee fan ien applikaasjestream te proxyen.

De opname op 'e tunnelinterface beslist meastentiids de payload-fraach. Lêsbere headers dêr betsjutte dat de ynderlike pakketten nea apart fersifere waarden, wylst payloads mei hege entropie betsjutte dat se dat wol waarden. Werhelje de opname op 'e bûtenste interface en fergelykje de twa: as beide willekeurich lykje, docht de ynderlike laach wurk dat de bûtenste net ûngedien meitsje kin.

Resinsje it fertrouwen dat jo eins jûn hawwe

In ynstalleare bedriuwsroot-sertifikaat is in feit oer de fertrouwensopslach fan 'e klient, gjin útspraak oer wat hokker proxy dan ek logt of ynspektearret. Stel it ynsetten belied en it echte ferbiningspaad fêst ynstee fan gedrach ôf te lieden út 'e oanwêzigens fan in CA.

Op beheard apparatuer, freegje de administrator hokker komponint TLS beëiniget, oft de klient in fêstset sertifikaat of in iepenbier sertifikaat falidearret, en wat it payload-formaat is. Dy trije antwurden leverje in befinings dy't jo letter ferdigenje kinne.

Skriuw it resultaat as in grins ynstee fan in útsprutsen oardiel. "TLS beëiniget by de ynspeksjeproxy, en de ynderlike payload is apart fersifere mei kaaien dy't allinnich de einpunten hawwe" is in kontrolearbere útspraak dy't in feroaring fan leveransier oerlibbet. "WebSockets binne feilich" net.