Шифровање WSS тунела зауставља се на TLS терминатору, не у апликацији

Адреса wss:// доказује TLS на једном скоку. Да ли корисни терет има сопствено шифровање зависи од тога шта клијент ставља унутра и ко завршава тај 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 су безбедни“ не.

Повезани чланци