Ang encryption ng WSS tunnel ay humihinto sa TLS terminator, hindi sa app

Ang tunnel na dala sa loob ng isang secure na WebSocket ay may eksaktong dami ng encryption na inilagay ng kliyente, wala nang higit pa. Sinasabi ng wss:// scheme na pinoprotektahan ng TLS ang isang koneksyon sa isang hop. Wala itong sinasabi tungkol sa kung ang mga byte sa loob ng mga mensahe ng WebSocket ay hiwalay na pinoprotektahan, at ang pagkakaibang iyon ang nagtatakda kung sino ang makakabasa ng iyong trapiko kapag may isang bagay sa gitna na nagtatapos ng TLS.

Dalawang layer na mukhang isa

Ang secure na WebSocket ay TLS na may WebSocket handshake na ginagawa sa ibabaw nito, gaya ng inilalarawan ng RFC 6455 sa mga seksyon nito tungkol sa koneksyon at seguridad. Ang layer ng TLS ay nagpapatunay sa server at nag-encrypt ng stream, pagkatapos ay ini-frame ng layer ng WebSocket ang anumang pasya ng aplikasyon na ipadala.

Ito ay dalawang malayang desisyon, at ang diagram na gumuhit ng isang padlock sa buong landas ay nagtatago ng pangalawa. Itanong kung sino ang nagtatapos ng koneksyon ng TLS. Pagkatapos ay itanong kung ano ang inilalagay ng kliyente sa loob ng bawat mensahe. Ang lahat ng iba pa tungkol sa deployment ay sumusunod mula sa dalawang sagot na iyon.

Disenyo A: ang transportasyon ang tanging encryption

Sa mas simpleng disenyo, kinukuha ng kliyente ang mga raw na IP packet at binabalot ang mga ito sa mga mensahe ng WebSocket. Walang naka-encrypt sa loob, kaya binabasa ng component na may hawak ng TLS session ang mga payload na plaintext. Kapag ang component na iyon ay ang sarili mong tunnel server, ito ang sinadyang endpoint at ang disenyo ay magkakaugnay, dahil makikita pa rin ng server ang trapiko.

Ito ay nagiging ibang kaayusan kapag may inspection proxy na nakaupo sa landas at nagtatapos ng TLS gamit ang certificate na pinagkakatiwalaan ng kliyente. Ang proxy na iyon ay may hawak na ngayon ng parehong plaintext na sana ay hawak ng server, at walang dami ng WebSocket framing ang makakabago niyon. Ang trust store ng kliyente ang nagpasya ng resultang ito bago pa man magbukas ang tunnel, dahil pinili nitong tanggapin ang certificate na iyon para sa pangalang iyon. Nakikita rin ng proxy ang hiniling na host at ang laki ng bawat mensahe, na sapat upang kumuha ng fingerprint ng maraming aktibidad nang walang karagdagang decryption.

Disenyo B: dala ng payload ang sarili nitong mga key

Sa ikalawang disenyo, ini-encrypt at pinapatunayan ng kliyente ang mga packet nito gamit ang VPN protocol na may sariling peer identity at key exchange, pagkatapos ay dala ang resulta sa loob ng mga mensahe ng WebSocket. Ang pagtatapos ng panlabas na TLS dito ay naglalantad ng ciphertext, hindi trapiko. Nakikita ng proxy ang mga laki at timing ng mensahe, at wala nang iba pa sa payload. Ito ay mas maliit na exposure, at metadata pa rin ito na dapat pangalanan sa isang review sa halip na ipagwalang-bahala.

Nakikita pa rin ng mga endpoint ng panloob na protocol ang plaintext, na siyang layunin ng kaayusan at siya ring hangganan nito. Kung ang isang component sa endpoint ay awtorisadong magbasa ng data bago ang encryption o pagkatapos ng decryption, hindi ito pinipigilan ng karagdagang layer. Ang mga key, at ang software na humahawak sa mga ito, ay nananatiling hangganan na mahalaga.

Ang label ng VPN, pamilyar na icon ng kliyente o marketing page ay hindi patunay na umiiral ang disenyong ito. Ang pagbasa ng format ng payload ang patunay.

Subaybayan kung saan talaga lumilitaw ang plaintext

Ang scheme ng URL ay nagbibigay sa iyo ng isang katotohanan, kaya kunin ang iba pa mula sa mga interface. Patakbuhin ang mga pagsusuri sa ibaba sa pagkakasunud-sunod, dahil ang bawat isa ay nagpapaliit sa susunod:

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

Magsimula sa panlabas na koneksyon. Ang isang pangmatagalang TCP session patungo sa TLS port ay ang hitsura ng isang WebSocket carrier, at ang ikalawang session patungo sa isang walang kaugnayang host ay karapat-dapat ipaliwanag bago ka tumingin nang mas malalim. Pagkatapos ay hanapin ang tunnel interface sa kliyente, dahil ang isang tun o tap device ay nagsasabi sa iyo na ang kliyente ay humahawak ng mga IP packet sa halip na mag-proxy ng isang stream ng aplikasyon.

Ang pagkuha sa tunnel interface ay karaniwang nagtatapos sa tanong ng payload. Ang mga nababasang header doon ay nangangahulugang ang mga panloob na packet ay hindi kailanman hiwalay na na-encrypt, samantalang ang mga payload na may mataas na entropy ay nangangahulugang na-encrypt ang mga ito. Ulitin ang pagkuha sa panlabas na interface at ihambing ang dalawa: kung pareho silang mukhang random, ang panloob na layer ay gumagawa ng trabahong hindi maibabalik ng panlabas.

Repasuhin ang tiwalang ibinigay mo talaga

Ang naka-install na corporate root certificate ay isang katotohanan tungkol sa trust store ng kliyente, hindi isang pahayag tungkol sa kung ano ang nila-log o sinisiyasat ng anumang proxy. Itatag ang naka-deploy na patakaran at ang tunay na landas ng koneksyon sa halip na hulaan ang pag-uugali mula sa pagkakaroon ng CA.

Sa mga managed na kagamitan, itanong sa administrator kung aling component ang nagtatapos ng TLS, kung ang kliyente ay nagpapatunay ng pinned na certificate o pampublikong certificate, at ano ang format ng payload. Ang tatlong sagot na iyon ay gumagawa ng natuklasan na maipagtatanggol mo mamaya.

Isulat ang resulta bilang hangganan at hindi bilang hatol. "Nagtatapos ang TLS sa inspection proxy, at ang panloob na payload ay hiwalay na naka-encrypt gamit ang mga key na hawak lamang ng mga endpoint" ay isang napapatunayan na pahayag na nananatili kapag nagpalit ng vendor. "Ang WebSockets ay secure" ay hindi nananatili.