O cifrado do túnel WSS remata no terminador TLS, non na aplicación

Un túnel transportado dentro dun WebSocket seguro ten exactamente o cifrado que o cliente lle puxo, nin máis. O esquema wss:// di que TLS protexe unha conexión nun salto. Non di nada sobre se os bytes dentro das mensaxes de WebSocket están protexidos por separado, e esa distinción decide quen pode ler o seu tráfico cando algo no medio termina o TLS.

Dúas capas que parecen unha soa

Un WebSocket seguro é TLS cunha aperta de mans de WebSocket executada por riba, como describe RFC 6455 nas súas seccións de conexión e seguridade. A capa TLS autentica o servidor e cifra o fluxo, e despois a capa WebSocket emmarca o que a aplicación decida enviar.

Son dúas decisións independentes, e un diagrama que debuxa un só cadeado sobre todo o camiño agocha a segunda. Pregunte quen termina a conexión TLS. Despois pregunte que pon o cliente dentro de cada mensaxe. Todo o demais sobre o despregamento séguese desas dúas respostas.

Deseño A: o transporte é o único cifrado

No deseño máis simple, o cliente toma paquetes IP en bruto e envolveos en mensaxes de WebSocket. Nada dentro está cifrado, así que o compoñente que mantén a sesión TLS le cargas en texto plano. Cando ese compoñente é o seu propio servidor de túnel, este é o punto final previsto e o deseño é coherente, porque o servidor sempre ía ver o tráfico.

Convértese noutra disposición cando un proxy de inspección se sitúa no camiño e termina o TLS cun certificado no que o cliente confía. Ese proxy agora ten o mesmo texto plano que tería o servidor, e ningunha cantidade de emmarcado de WebSocket o cambia. O almacén de confianza do cliente decidiu este resultado moito antes de que se abrise o túnel, porque escolleu aceptar ese certificado para ese nome. O proxy tamén ve o host solicitado e o tamaño de cada mensaxe, o que abonda para tomar a impresión de moita actividade sen descifrar nada máis.

Deseño B: a carga leva as súas propias claves

No segundo deseño, o cliente cifra e autentica os seus paquetes cun protocolo VPN que ten a súa propia identidade de par e intercambio de claves, e despois transporta o resultado dentro de mensaxes de WebSocket. Terminar o TLS exterior aquí expón texto cifrado, non tráfico. O proxy pode ver tamaños e tempos das mensaxes, e nada máis na carga. É unha exposición moito menor, e aínda así son metadatos que paga a pena nomear nunha revisión en lugar de descartalos.

Os propios puntos finais do protocolo interior seguen vendo texto plano, que é o sentido da disposición e tamén o seu límite. Se un compoñente do punto final está autorizado a ler datos antes do cifrado ou despois do descifrado, a capa extra non o limita. As claves, e o software que as manexa, seguen sendo a fronteira que importa.

Unha etiqueta VPN, unha icona de cliente coñecida ou unha páxina de márketing non son proba de que este deseño exista. Ler o formato da carga si o é.

Rastrexen onde aparece realmente o texto plano

O esquema do URL dálles un só feito, así que obteñan o resto das interfaces. Executen as comprobacións de abaixo en orde, porque cada unha estreita a seguinte:

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

Comecen pola conexión exterior. Unha sesión TCP de longa duración ao porto TLS é o aspecto dun portador WebSocket, e unha segunda sesión a un host non relacionado merece explicación antes de mirar máis fondo. Despois atopen a interface de túnel no cliente, porque un dispositivo tun ou tap dilles que o cliente manexa paquetes IP en lugar de facer de proxy para un único fluxo de aplicación.

A captura na interface de túnel adoita resolver a cuestión da carga. Cabeceiras lexibles alí significan que os paquetes interiores nunca se cifraron por separado, mentres que cargas de alta entropía significan que si. Repitan a captura na interface exterior e comparen as dúas: se ambas parecen aleatorias, a capa interior fai un traballo que a exterior non pode desfacer.

Revisen a confianza que realmente outorgaron

Un certificado raíz corporativo instalado é un feito sobre o almacén de confianza do cliente, non unha afirmación sobre o que ningún proxy rexistra ou inspecciona. Establezan a política despregada e o camiño de conexión real en lugar de inferir comportamento da presenza dunha CA.

En equipos xestionados, pregunten ao administrador que compoñente termina o TLS, se o cliente valida un certificado fixado ou un público, e cal é o formato da carga. Esas tres respostas producen unha conclusión que poderán defender máis adiante.

Escriban o resultado como unha fronteira e non como un veredicto. "O TLS termina no proxy de inspección, e a carga interior está cifrada por separado con claves que só teñen os puntos finais" é unha afirmación comprobable que sobrevive a un cambio de provedor. "Os WebSockets son seguros" non.