Ĉifrado de WSS-tunelo finiĝas ĉe la TLS-terminilo, ne ĉe la aplikaĵo

Tunelo portata ene de sekura WebSocket havas ĝuste tiom da ĉifrado, kiom la kliento metis en ĝin, ne pli. La skemo wss:// diras, ke TLS protektas unu konekton en unu salto. Ĝi diras nenion pri tio, ĉu la bitokoj ene de la WebSocket-mesaĝoj estas aparte protektitaj, kaj ĝuste tiu distingo decidas, kiu povas legi vian trafikon, kiam io meze finas TLS.

Du tavoloj, kiuj aspektas kiel unu

Sekura WebSocket estas TLS kun WebSocket-manpremo farata sur ĝi, kiel RFC 6455 priskribas en siaj sekcioj pri konekto kaj sekureco. La TLS-tavolo aŭtentigas la servilon kaj ĉifras la fluon, poste la WebSocket-tavolo kadras tion, kion la aplikaĵo decidas sendi.

Tiuj estas du sendependaj decidoj, kaj diagramo, kiu desegnas unu seruron super la tuta vojo, kaŝas la duan. Demandu, kiu finas la TLS-konekton. Poste demandu, kion la kliento metas ene de ĉiu mesaĝo. Ĉio alia pri la deplojo sekvas el tiuj du respondoj.

Dezajno A: la transporto estas la sola ĉifrado

En la pli simpla dezajno, la kliento prenas krudajn IP-paketojn kaj volvas ilin en WebSocket-mesaĝojn. Nenio ene estas ĉifrita, do la komponanto, kiu tenas la TLS-sesion, legas klartekstajn ŝarĝojn. Kiam tiu komponanto estas via propra tunela servilo, tio estas la intencita finpunkto kaj la dezajno estas kohera, ĉar la servilo ĉiam vidus la trafikon.

Ĝi fariĝas alia aranĝo, kiam inspektada prokura servilo sidas sur la vojo kaj finas TLS per atestilo, kiun la kliento fidas. Tiu prokura servilo nun tenas la saman klartekston, kiun la servilo tenus, kaj neniu kvanto da WebSocket-kadrado ŝanĝas tion. La fida konservejo de la kliento decidis tiun rezulton longe antaŭ ol la tunelo malfermiĝis, ĉar ĝi elektis akcepti tiun atestilon por tiu nomo. La prokura servilo ankaŭ vidas la petitan gastiganton kaj la grandecon de ĉiu mesaĝo, kio sufiĉas por preni fingrospuron de multa agado sen deĉifri ion plu.

Dezajno B: la ŝarĝo portas siajn proprajn ŝlosilojn

En la dua dezajno, la kliento ĉifras kaj aŭtentigas siajn paketojn per VPN-protokolo, kiu havas propran samrangulan identecon kaj ŝlosilinterŝanĝon, poste portas la rezulton ene de WebSocket-mesaĝoj. Fini la eksteran TLS ĉi tie elmontras ĉifrotekston, ne trafikon. La prokura servilo povas vidi mesaĝgrandecojn kaj tempon, kaj nenion alian en la ŝarĝo. Tio estas multe pli malgranda elmeto, kaj ĝi tamen estas metadatenoj menciindaj en revizio anstataŭ forgestaj.

La propraj finpunktoj de la interna protokolo ankoraŭ vidas klartekston, kio estas la senco de la aranĝo kaj ankaŭ ĝia limo. Se komponanto sur la finpunkto rajtas legi datumojn antaŭ ĉifrado aŭ post malĉifrado, la plia tavolo ne limigas ĝin. Ŝlosiloj, kaj la programaro, kiu ilin traktas, restas la limo, kiu gravas.

VPN-etikedo, konata klientsimbolo aŭ merkatada paĝo ne estas pruvo, ke ĉi tiu dezajno ekzistas. Legi la ŝarĝformon estas.

Spuru, kie la klarteksto vere aperas

La URL-skemo donas al vi unu fakton, do prenu la reston el la interfacoj. Rulu la subajn kontrolojn laŭ ordo, ĉar ĉiu mallarĝigas la sekvan:

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

Komencu per la ekstera konekto. Unu longdaŭra TCP-sesio al la TLS-pordo estas kiel aspektas WebSocket-portilo, kaj dua sesio al nerilata gastiganto indas klarigon antaŭ ol rigardi pli profunde. Poste trovu la tunelan interfacon sur la kliento, ĉar aparato tun aŭ tap diras al vi, ke la kliento traktas IP-paketojn anstataŭ prokuri unu aplikaĵan fluon.

La kapto sur la tunela interfaco kutime solvas la ŝarĝdemandon. Legeblaj kaplinioj tie signifas, ke la internaj paketoj neniam estis aparte ĉifritaj, dum alta-entropiaj ŝarĝoj signifas, ke ili estis. Ripetu la kapton sur la ekstera interfaco kaj komparu la du: se ambaŭ aspektas hazardaj, la interna tavolo faras laboron, kiun la ekstera ne povas malfari.

Reviziu la fidon, kiun vi vere donis

Instalita entreprena radika atestilo estas fakto pri la fida konservejo de la kliento, ne aserto pri tio, kion iu prokura servilo registras aŭ inspektas. Starigu la deplojitan politikon kaj la realan konektan vojon anstataŭ konkludi konduton el la ĉeesto de CA.

Sur administrata ekipaĵo, demandu la administranton, kiu komponanto finas TLS, ĉu la kliento validigas fiksitan atestilon aŭ publikan, kaj kia estas la ŝarĝformo. Tiuj tri respondoj produktas konstaton, kiun vi povos defendi poste.

Skribu la rezulton kiel limo, ne kiel verdikto. "TLS finiĝas ĉe la inspektada prokura servilo, kaj la interna ŝarĝo estas aparte ĉifrita per ŝlosiloj tenataj nur de la finpunktoj" estas kontrolebla aserto, kiu postvivas ŝanĝon de vendisto. "WebSockets estas sekuraj" ne.