WSS-tonnelversleuteling eindig by die TLS-terminator, nie by die toep nie
'n wss://-URL bewys TLS op een hop. Of die vrag sy eie versleuteling het, hang af van wat die kliënt binne plaas en wie daardie TLS termineer.
'n Tonnel wat in 'n beveiligde WebSocket gedra word, het presies soveel versleuteling as wat die kliënt daarin gesit het, nie meer nie. Die wss://-skema sê dat TLS een verbinding op een hop beskerm. Dit sê niks oor of die grepe binne die WebSocket-boodskappe afsonderlik beskerm word nie, en daardie onderskeid bepaal wie jou verkeer kan lees wanneer iets in die middel TLS termineer.
Twee lae wat soos een lyk
'n Beveiligde WebSocket is TLS waaroor 'n WebSocket-handdruk uitgevoer word, soos RFC 6455 in sy verbinding- en sekuriteitsafdelings beskryf. Die TLS-laag authentiseer die bediener en versleutel die stroom, en dan raam die WebSocket-laag wat die toep ook al besluit om te stuur.
Dit is twee onafhanklike besluite, en 'n diagram wat een slot oor die hele pad teken, verberg die tweede. Vra wie die TLS-verbinding termineer. Vra dan wat die kliënt binne elke boodskap plaas. Alles anders oor die ontplooiing volg uit daardie twee antwoorde.
Ontwerp A: die vervoer is die enigste versleuteling
In die eenvoudiger ontwerp neem die kliënt rou IP-pakkette en wikkel dit in WebSocket-boodskappe. Niks binne is versleutel nie, so die komponent wat die TLS-sessie hou, lees gewone vragte. Wanneer daardie komponent jou eie tonnelbediener is, is dit die bedoelde eindpunt en is die ontwerp samehangend, want die bediener sou die verkeer altyd sien.
Dit word 'n ander reëling wanneer 'n inspeksieproxy op die pad sit en TLS termineer met 'n sertifikaat wat die kliënt vertrou. Daardie proxy hou nou dieselfde gewone teks wat die bediener sou gehou het, en geen mate van WebSocket-raming verander dit nie. Die kliënt se vertrouensbewaarplek het hierdie uitkoms lank voor die tonnel oopgemaak het besluit, want hy het gekies om daardie sertifikaat vir daardie naam te aanvaar. Die proxy sien ook die versoekte gasheer en die grootte van elke boodskap, wat genoeg is om baie aktiwiteit te vingerafdruk sonder om verder enigiets te ontsleutel.
Ontwerp B: die vrag dra sy eie sleutels
In die tweede ontwerp versleutel en authentiseer die kliënt sy pakkette met 'n VPN-protokol met sy eie eweknie-identiteit en sleuteluitruiling, en dra dan die resultaat binne WebSocket-boodskappe. Om die buitenste TLS hier te termineer, stel blote geheimteks bloot, nie verkeer nie. Die proxy kan boodskapgroottes en tydsberekening sien, en niks anders in die vrag nie. Dit is 'n veel kleiner blootstelling, en dit is steeds metadata wat tydens 'n hersiening genoem moet word eerder as weggewuif.
Die binne-protokol se eie eindpunte sien steeds gewone teks, wat die punt van die reëling is en ook sy beperking. As 'n komponent op die eindpunt gemagtig is om data voor versleuteling of na ontsleuteling te lees, beperk die ekstra laag dit nie. Sleutels, en die sagteware wat hulle hanteer, bly die grens wat saak maak.
'n VPN-etiket, 'n bekende kliëntikoon of 'n bemarkingsbladsy is nie bewys dat hierdie ontwerp bestaan nie. Om die vragformaat te lees is.
Spoor waar die gewone teks werklik verskyn
Die URL-skema gee jou een feit, so kry die res uit die koppelvlakke. Voer die kontroles hieronder in volgorde uit, want elkeen vernou die volgende:
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
Begin met die buitenste verbinding. Een langdurige TCP-sessie na die TLS-poort is hoe 'n WebSocket-draer lyk, en 'n tweede sessie na 'n onverwante gasheer is die moeite werd om te verduidelik voordat jy dieper kyk. Vind dan die tonnelkoppelvlak op die kliënt, want 'n tun- of tap-toestel vertel jou die kliënt hanteer IP-pakkette eerder as om 'n enkele toepassingstroom te volmagtig.
Die opname op die tonnelkoppelvlak beslis gewoonlik die vragvraag. Leesbare koptekste daar beteken die binne-pakkette was nooit afsonderlik versleutel nie, terwyl hoë-entropie vragte beteken hulle was. Herhaal die opname op die buitenste koppelvlak en vergelyk die twee: as albei ewekansig lyk, doen die binne-laag werk wat die buitenste een nie kan ongedaan maak nie.
Hersien die vertroue wat jy werklik toegestaan het
'n Geïnstalleerde korporatiewe wortelsertifikaat is 'n feit oor die kliënt se vertrouensbewaarplek, nie 'n stelling oor wat enige proxy teken of inspekteer nie. Stel die ontplooide beleid en die werklike verbindingspad vas eerder as om gedrag af te lei uit die teenwoordigheid van 'n CA.
Op bestuurde toerusting, vra die administrateur watter komponent TLS termineer, of die kliënt 'n vasgepen sertifikaat of 'n openbare een valideer, en wat die vragformaat is. Daardie drie antwoorde lewer 'n bevinding wat jy later kan verdedig.
Skryf die resultaat as 'n grens eerder as 'n uitspraak. "TLS termineer by die inspeksieproxy, en die binne-vrag word afsonderlik versleutel met sleutels wat net die eindpunte hou" is 'n nagaande stelling wat 'n verandering van verskaffer oorleef. "WebSockets is veilig" nie.