El cifrado del túnel WSS termina en el terminador TLS, no en la aplicación

Un túnel transportado dentro de un WebSocket seguro tiene exactamente el cifrado que el cliente le puso, ni más. El esquema wss:// dice que TLS protege una conexión en un salto. No dice nada sobre si los bytes dentro de los mensajes de WebSocket están protegidos por separado, y esa distinción decide quién puede leer su tráfico cuando algo en medio termina el TLS.

Dos capas que parecen una sola

Un WebSocket seguro es TLS con un apretón de manos de WebSocket realizado encima, como describe RFC 6455 en sus secciones de conexión y seguridad. La capa TLS autentica el servidor y cifra el flujo, y luego la capa WebSocket enmarca lo que la aplicación decida enviar.

Son dos decisiones independientes, y un diagrama que dibuja un solo candado sobre todo el camino oculta la segunda. Pregunte quién termina la conexión TLS. Luego pregunte qué pone el cliente dentro de cada mensaje. Todo lo demás sobre el despliegue se sigue de esas dos respuestas.

Diseño A: el transporte es el único cifrado

En el diseño más simple, el cliente toma paquetes IP en bruto y los envuelve en mensajes de WebSocket. Nada dentro está cifrado, así que el componente que mantiene la sesión TLS lee cargas útiles en texto plano. Cuando ese componente es su propio servidor de túnel, este es el punto final previsto y el diseño es coherente, porque el servidor siempre iba a ver el tráfico.

Se convierte en otra disposición cuando un proxy de inspección se sitúa en el camino y termina el TLS con un certificado en el que el cliente confía. Ese proxy ahora tiene el mismo texto plano que habría tenido el servidor, y ninguna cantidad de enmarcado de WebSocket lo cambia. El almacén de confianza del cliente decidió este resultado mucho antes de que se abriera el túnel, porque eligió aceptar ese certificado para ese nombre. El proxy también ve el host solicitado y el tamaño de cada mensaje, lo que basta para tomar la huella de mucha actividad sin descifrar nada más.

Diseño B: la carga lleva sus propias claves

En el segundo diseño, el cliente cifra y autentica sus paquetes con un protocolo VPN que tiene su propia identidad de par e intercambio de claves, y luego transporta el resultado dentro de mensajes de WebSocket. Terminar el TLS exterior aquí expone texto cifrado, no tráfico. El proxy puede ver tamaños y tiempos de los mensajes, y nada más de la carga. Es una exposición mucho menor, y aun así son metadatos que vale la pena nombrar en una revisión en lugar de descartarlos.

Los propios puntos finales del protocolo interno siguen viendo texto plano, que es el sentido de la disposición y también su límite. Si un componente del punto final está autorizado a leer datos antes del cifrado o después del descifrado, la capa extra no lo limita. Las claves, y el software que las maneja, siguen siendo la frontera que importa.

Una etiqueta VPN, un icono de cliente conocido o una página de marketing no son prueba de que este diseño exista. Leer el formato de la carga sí lo es.

Rastree dónde aparece realmente el texto plano

El esquema de la URL le da un solo hecho, así que obtenga el resto de las interfaces. Ejecute las comprobaciones de abajo en orden, porque cada una estrecha la siguiente:

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

Empiece por la conexión exterior. Una sesión TCP de larga duración al puerto TLS es el aspecto de un portador WebSocket, y una segunda sesión a un host no relacionado merece explicación antes de mirar más a fondo. Luego encuentre la interfaz de túnel en el cliente, porque un dispositivo tun o tap le dice que el cliente maneja paquetes IP en lugar de hacer de proxy para un único flujo de aplicación.

La captura en la interfaz de túnel suele resolver la cuestión de la carga. Cabeceras legibles allí significan que los paquetes internos nunca se cifraron por separado, mientras que cargas de alta entropía significan que sí. Repita la captura en la interfaz exterior y compare las dos: si ambas parecen aleatorias, la capa interna hace un trabajo que la exterior no puede deshacer.

Revise la confianza que realmente otorgó

Un certificado raíz corporativo instalado es un hecho sobre el almacén de confianza del cliente, no una afirmación sobre lo que registra o inspecciona ningún proxy. Establezca la política desplegada y la ruta de conexión real en lugar de inferir comportamiento de la presencia de una CA.

En equipos gestionados, pregunte al administrador qué componente termina el TLS, si el cliente valida un certificado fijado o uno público, y cuál es el formato de la carga. Esas tres respuestas producen una conclusión que podrá defender más adelante.

Escriba el resultado como una frontera y no como un veredicto. "El TLS termina en el proxy de inspección, y la carga interna está cifrada por separado con claves que solo tienen los puntos finales" es una afirmación comprobable que sobrevive a un cambio de proveedor. "Los WebSockets son seguros" no.