Шыфраванне тунеля WSS спыняецца на тэрмінатары TLS, а не ў праграме

Тунель, які пераносіцца ўнутры абароненага WebSocket, мае роўна столькі шыфравання, колькі кліент у яго паклаў, і ні кроплі больш. Схема wss:// кажа, што TLS абараняе адно злучэнне на адным пераходзе. Яна нічога не кажа пра тое, ці байты ўнутры паведамленняў WebSocket абаронены асобна, і менавіта гэтае адрозненне вырашае, хто зможа чытаць ваш трафік, калі нешта пасярэдзіне завяршае TLS.

Два ўзроўні, якія выглядаюць як адзін

Абаронены WebSocket — гэта TLS, паверх якога выконваецца рукапацісканне WebSocket, як апісвае RFC 6455 у раздзелах пра злучэнне і бяспеку. Узровень TLS аўтэнтыфікуе сервер і шыфруе паток, затым узровень WebSocket фармуе ў кадры тое, што праграма вырашыць адаслаць.

Гэта два незалежныя рашэнні, а схема, якая малюе адзін замочак на ўсім шляху, хавае другое. Спытайцеся, хто завяршае злучэнне TLS. Затым спытайцеся, што кліент кладзе ўнутр кожнага паведамлення. Усё астатняе пра разгортванне вынікае з гэтых двух адказаў.

Дызайн A: транспарт — адзінае шыфраванне

У прасцейшым дызайне кліент бярэ сырыя IP-пакеты і заварочвае іх у паведамленні WebSocket. Унутры нічога не шыфруецца, таму кампанент, які трымае сеанс TLS, чытае адкрытыя карысныя нагрузкі. Калі гэты кампанент — ваш уласны сервер тунеля, гэта і ёсць задуманая канчатковая кропка, і дызайн узгоднены, бо сервер усё роўна бачыў бы трафік.

Гэта становіцца іншай схемай, калі на шляху стаіць праксі праверкі і завяршае TLS сертыфікатам, якому кліент давярае. Гэтае праксі цяпер трымае той самы адкрыты тэкст, які трымаў бы сервер, і ніякая колькасць кадравання WebSocket гэтага не зменіць. Сховішча даверу кліента вырашыла гэты вынік задоўга да адкрыцця тунеля, бо выбрала прыняць гэты сертыфікат для гэтага імені. Праксі таксама бачыць запытаны хост і памер кожнага паведамлення, і гэтага дастаткова, каб зняць адбітак вялікай колькасці актыўнасці, нічога болей не расшыфроўваючы.

Дызайн B: карысная нагрузка нясе ўласныя ключы

У другім дызайне кліент шыфруе і аўтэнтыфікуе свае пакеты пратаколам VPN, які мае ўласную ідэнтычнасць партнёра і абмен ключамі, а затым пераносіць вынік унутры паведамленняў WebSocket. Завяршэнне знешняга TLS тут паказвае шыфраваны тэкст, а не трафік. Праксі бачыць памеры паведамленняў і час, і нічога болей у карыснай нагрузцы. Гэта значна меншая экспазіцыя, і ўсё ж гэта метаданыя, якія варта назваць пры аглядзе, а не адмахнуцца ад іх.

Уласныя канчатковыя кропкі ўнутранага пратакола ўсё яшчэ бачаць адкрыты тэкст — у гэтым сэнс схемы і адначасова яе мяжа. Калі кампанент на канчатковай кропцы мае права чытаць даныя да шыфравання або пасля расшыфроўкі, дадатковы ўзровень яго не стрымлівае. Ключы і праграмнае забеспячэнне, якое імі займаецца, застаюцца мяжой, што мае значэнне.

Этыкетка VPN, знаёмая іконка кліента або маркетынгавая старонка не ёсць доказам існавання гэтага дызайну. Чытанне фармату карыснай нагрузкі — ёсць.

Прасочыце, дзе насамрэч з'яўляецца адкрыты тэкст

Схема URL дае вам адзін факт, астатняе бярыце з інтэрфейсаў. Выканайце прыведзеныя ніжэй праверкі па парадку, бо кожная звужвае наступную:

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

Пачніце са знешняга злучэння. Адзін доўгатэрміновы сеанс TCP да порта TLS — менавіта так выглядае носьбіт WebSocket, а другі сеанс да непаўнавартаснага хоста варта патлумачыць, перш чым глядзець глыбей. Затым знайдзіце інтэрфейс тунеля на кліенце, бо прылада tun або tap кажа, што кліент апрацоўвае IP-пакеты, а не праксіруе адзін паток праграмы.

Захоп на інтэрфейсе тунеля звычайна вырашае пытанне карыснай нагрузкі. Чытэльныя загалоўкі там азначаюць, што ўнутраныя пакеты ніколі асобна не шыфраваліся, а нагрузкі з высокай энтрапіяй азначаюць, што шыфраваліся. Паўтарыце захоп на знешнім інтэрфейсе і параўнайце абодва: калі абодва выглядаюць выпадковымі, унутраны ўзровень робіць працу, якую знешні не можа адмяніць.

Перагледзьце давер, які вы насамрэч далі

Усталяваны карпаратыўны каранёвы сертыфікат — гэта факт пра сховішча даверу кліента, а не сцвярджэнне пра тое, што любое праксі запісвае ці правярае. Устанавіце разгорнутую палітыку і рэальны шлях злучэння замест таго, каб выводзіць паводзіны з наяўнасці CA.

На кіруемай тэхніцы спытайце ў адміністратара, які кампанент завяршае TLS, ці правярае кліент замацаваны сертыфікат або публічны, і які фармат карыснай нагрузкі. Гэтыя тры адказы даюць выснову, якую вы зможаце абараніць пазней.

Запішыце вынік як мяжу, а не як вердыкт. "TLS завяршаецца на праксі праверкі, а ўнутраная карысная нагрузка асобна шыфраваная ключамі, якія трымаюць толькі канчатковыя кропкі" — гэта правяральнае сцвярджэнне, якое перажыве змену пастаўшчыка. "WebSockets бяспечныя" — не.