El xifrat del túnel WSS s'atura al terminador TLS, no a l'aplicació

Un túnel transportat dins d'un WebSocket segur té exactament tant xifrat com el client hi ha posat, i no més. L'esquema wss:// diu que TLS protegeix una connexió en un salt. No diu res sobre si els bytes dins dels missatges de WebSocket estan protegits per separat, i aquesta distinció decideix qui pot llegir el vostre trànsit quan alguna cosa al mig acaba el TLS.

Dues capes que semblen una de sola

Un WebSocket segur és TLS amb un intercanvi de WebSocket fet a sobre, tal com RFC 6455 descriu a les seccions de connexió i seguretat. La capa TLS autentica el servidor i xifra el flux, i després la capa WebSocket emmarca el que l'aplicació decideixi enviar.

Són dues decisions independents, i un diagrama que dibuixa un sol cadenat sobre tot el camí amaga la segona. Pregunteu qui acaba la connexió TLS. Després pregunteu què posa el client dins de cada missatge. Tota la resta del desplegament es desprèn d'aquestes dues respostes.

Disseny A: el transport és l'únic xifrat

En el disseny més simple, el client agafa paquets IP en cru i els embolcalla en missatges de WebSocket. A dins no hi ha res xifrat, així que el component que manté la sessió TLS llegeix càrregues en text pla. Quan aquest component és el vostre propi servidor de túnel, aquest és el punt final previst i el disseny és coherent, perquè el servidor sempre havia de veure el trànsit.

Es converteix en una altra disposició quan un proxy d'inspecció se situa al camí i acaba el TLS amb un certificat en què el client confia. Aquest proxy ara té el mateix text pla que hauria tingut el servidor, i cap quantitat d'emmarcat de WebSocket ho canvia. El magatzem de confiança del client va decidir aquest resultat molt abans que s'obrís el túnel, perquè va triar acceptar aquell certificat per a aquell nom. El proxy també veu l'amfitrió sol·licitat i la mida de cada missatge, cosa que n'hi ha prou per fer una empremta de molta activitat sense desxifrar res més.

Disseny B: la càrrega útil porta les seves pròpies claus

En el segon disseny, el client xifra i autentica els seus paquets amb un protocol VPN que té la seva pròpia identitat de parell i intercanvi de claus, i després transporta el resultat dins de missatges de WebSocket. Acabar el TLS exterior aquí exposa text xifrat, no trànsit. El proxy pot veure mides i temps dels missatges, i res més de la càrrega. És una exposició molt menor, i tot i així són metadades que val la pena anomenar en una revisió en lloc d'escombrar-les.

Els propis punts finals del protocol interior encara veuen text pla, que és el punt de la disposició i també el seu límit. Si un component del punt final està autoritzat a llegir dades abans del xifrat o després del desxifrat, la capa extra no el limita. Les claus, i el programari que les maneja, continuen sent la frontera que importa.

Una etiqueta VPN, una icona de client coneguda o una pàgina de màrqueting no són proves que aquest disseny existeixi. Llegir el format de la càrrega sí que ho és.

Rastreu on apareix realment el text pla

L'esquema de la URL us dona un sol fet, així que obteniu la resta de les interfícies. Executeu les comprovacions de sota en ordre, perquè cadascuna estreny la següent:

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

Comenceu per la connexió exterior. Una sessió TCP de llarga durada cap al port TLS és com es veu un portador WebSocket, i una segona sessió cap a un amfitrió no relacionat val la pena explicar-la abans de mirar més avall. Després trobeu la interfície de túnel al client, perquè un dispositiu tun o tap us diu que el client tracta paquets IP en lloc de fer de proxy per a un sol flux d'aplicació.

La captura a la interfície de túnel normalment resol la qüestió de la càrrega. Capçaleres llegibles allà volen dir que els paquets interiors mai es van xifrar per separat, mentre que càrregues d'alta entropia volen dir que sí. Repetiu la captura a la interfície exterior i compareu les dues: si totes dues semblen aleatòries, la capa interior fa feina que l'exterior no pot desfer.

Reviseu la confiança que realment heu atorgat

Un certificat arrel corporatiu instal·lat és un fet sobre el magatzem de confiança del client, no una afirmació sobre què registra o inspecciona cap proxy. Establiu la política desplegada i el camí real de connexió en lloc d'inferir comportament de la presència d'una CA.

En equips gestionats, pregunteu a l'administrador quin component acaba el TLS, si el client valida un certificat fixat o un de públic, i quin és el format de la càrrega. Aquestes tres respostes produeixen una conclusió que podeu defensar més endavant.

Escriviu el resultat com una frontera i no com un veredicte. "El TLS acaba al proxy d'inspecció, i la càrrega interior està xifrada per separat amb claus que només tenen els punts finals" és una afirmació comprovable que sobreviu a un canvi de proveïdor. "Els WebSockets són segurs" no.