Resumen

  • La máscara de WebSocket no ofrece confidencialidad: sus cuatro bytes de clave viajan en la trama, pero la imprevisibilidad impide que la aplicación determine antes del envío la imagen binaria que circulará.
  • La regla nació de un fallo real de intermediarios. El cliente debe enmascarar con una clave nueva, el servidor no debe hacerlo y la aplicación pierde la facultad de modificar una trama cuando empieza la transmisión.

Las primeras tramas confiaban en sus fronteras

El borrador IETF de mayo de 2010 proponía un canal bidireccional después de una apertura HTTP. Su formato inicial era pequeño: 0x00 abría una trama de texto y 0xff la cerraba; otra forma declaraba una longitud. Para dos extremos conformes, la gramática separaba bien los mensajes.

No podía, sin embargo, gobernar cada aparato desplegado en el camino. Un proxy de interceptación podía dejar pasar Upgrade y continuar buscando una petición HTTP entre los bytes posteriores. WebSocket ya había cambiado de lenguaje; el analizador intermedio seguía creyendo que hablaba HTTP.

El dispositivo no tenía que ser malicioso. Bastaba con que aplicara con seguridad la gramática equivocada. Navegador y servidor podían cumplir su acuerdo mientras un tercer componente producía un efecto de caché que ninguno había autorizado.

Un disfraz constante devolvía el control

En enero de 2011, el borrador -04 ya obligaba al cliente a enmascarar las tramas dirigidas al servidor. La clave se derivaba de valores del saludo y permanecía constante durante la conexión.

La transformación cambiaba los bytes visibles, pero no conseguía la propiedad necesaria. Si la regla es estable y conocida, la aplicación puede escoger una entrada que produzca la salida deseada. El resultado sólo parece extraño para quien desconoce el mecanismo.

La defensa requería una decisión nueva por trama: la aplicación podía escoger el mensaje lógico o conocer la próxima transformación, pero no disponer de ambas cosas antes de que quedara fijada la representación en el cable.

El proxy puso un nombre falso a una respuesta

El trabajo de 2011 Talking to Yourself for Fun and Profit estudió las interfaces de socket del navegador cuando en la ruta había proxies llamados transparentes, aunque en realidad interceptaban el tráfico. Algunos reenviaban el consentimiento o el cambio de protocolo sin comprenderlo y después interpretaban el flujo como HTTP.

El fallo atravesaba varias competencias. Un sitio hostil hacía que el navegador conectara con un servidor bajo su control. El intermediario atribuía a los bytes siguientes la identidad de otro recurso. El servidor atacante entregaba una respuesta y el caché la guardaba bajo ese nombre falso. Usuarios posteriores podían recibir contenido que nunca procedió del origen nombrado.

El experimento publicitario de marzo de 2011 observó condiciones de envenenamiento en una proporción pequeña pero distinta de cero de las rutas Java y Flash medidas. En los saludos experimentales de WebSocket basados en Upgrade hubo ocho casos entre 47.338 que llegaron a la prueba. Son resultados de aquella muestra, no una medición de los proxies actuales.

La conclusión más duradera no fue el porcentaje. Un prefijo que no parece HTTP no demuestra que todos los analizadores defectuosos vayan a respetarlo. Alguno puede saltarlo y reanudar el análisis en la carga útil. Había que impedir que el código hostil construyera deliberadamente la representación binaria peligrosa.

La clave entró en cada trama

El borrador -05 de febrero de 2011 incorporó una clave de 32 bits a cada trama enmascarada. El cliente debía obtenerla de una fuente fuerte de entropía y no permitir que las claves anteriores revelaran la siguiente. La RFC 4086 explica la diferencia entre apariencia estadística e imprevisibilidad frente a un adversario: relojes, contadores y semillas pequeñas pueden parecer variados y seguir siendo adivinables.

La RFC 6455 conservó el diseño. El bit MASK anuncia la presencia de cuatro bytes; el byte útil i se combina mediante XOR con el byte de clave i mod 4. La longitud no cambia y no cuenta la propia clave.

Cualquier receptor puede deshacer la operación. Esa publicidad es intencional. La aplicación debía comprometer el contenido antes de conocer una transformación imprevisible; el servidor necesitaba la clave para recuperar el mensaje. El objetivo era controlar la elección previa, no esconder datos.

La trama se volvía inmutable al salir

Una clave nueva no basta si la aplicación puede deducirla a partir del inicio de una trama larga y cambiar la parte todavía no transmitida. La RFC plantea un prefijo conocido, por ejemplo ceros: los primeros bytes enmascarados revelan el XOR repetido y una cola mutable podría adaptarse para parecer una petición HTTP.

Por eso, cuando empieza la transmisión de una trama del cliente, la aplicación ya no puede modificar su carga útil. Los datos nuevos o cambiados deben ir en otra trama y recibir otra clave.

La construcción se convierte así en un límite temporal. Antes del envío, la aplicación decide el sentido del mensaje. Después del primer byte, el cliente custodia una secuencia comprometida. Sin esa entrega, observar el principio permitiría controlar el final.

La dirección exponía el modelo de amenaza

Toda trama del cliente al servidor está enmascarada; ninguna trama del servidor al cliente puede estarlo. Una dirección incorrecta obliga a cerrar la conexión y puede producir el código de error de protocolo 1002.

La asimetría sigue la mecánica del incidente. Para asignar una identidad falsa a una respuesta almacenada, primero hacen falta bytes con aspecto de petición en sentido navegador-servidor. Un servidor hostil ya puede producir bytes con aspecto de respuesta, pero sin la solicitud falsa falta la identidad que completa el envenenamiento.

Esto no convierte en fiable lo que envía el servidor. Autenticación, autorización, política de Origin, validación del contenido y protección del canal siguen siendo capas distintas. La máscara inversa sencillamente no era el remedio para esta falla.

TLS no anuló la obligación

El enmascaramiento se aplica también a wss. Un flujo TLS correcto impide que un intermediario que no termina TLS vea el contenido, pero la afirmación es otra. TLS protege confidencialidad e integridad entre sus extremos; la máscara limita los bytes que una aplicación no confiable puede ordenar a un cliente WebSocket conforme que emita.

La separación evita que la validez de la trama dependa del punto donde termine TLS, de una ruta interna o de si el cliente es un navegador. Una protección inferior no da permiso implícito para descartar la gramática superior.

HTTP/2 y HTTP/3 mantuvieron la regla

La RFC 8441 pasó la apertura a un CONNECT extendido sobre un flujo HTTP/2. En ese camino dejó de procesar Sec-WebSocket-Key y Sec-WebSocket-Accept, porque :protocol ofrecía la señal de establecimiento. Sin embargo, mantuvo las consideraciones de seguridad de la RFC 6455 salvo la discusión de SHA-1 propia del saludo anterior.

La RFC 9220 adaptó el mecanismo a HTTP/3 sin crear otra excepción. Cambió el transporte de la apertura, no el contrato direccional de la trama WebSocket.

La continuidad indica que la máscara no fue un arreglo para una cabecera concreta. Codificó una relación entre elección de la aplicación, compromiso del cliente y confusión del intermediario que sobrevivió al cambio de transporte.

Lo que demuestra una clave pública

Una clave fresca no demuestra identidad, autoría, permiso ni integridad. Verla en una captura es normal. Repetirla o predecir la siguiente sí puede revelar que se perdió el supuesto de seguridad.

Tampoco arregla por sí sola los proxies. Clientes y servidores no conformes todavía pueden exponer un intermediario vulnerable. La norma redujo lo que un trayecto WebSocket correcto podía ser obligado a producir; no adquirió control sobre cada caché de Internet.

La lección histórica es limitada y útil. Si una infraestructura antigua puede analizar bytes con la gramática equivocada, anunciar el nuevo protocolo no siempre basta. El protocolo también puede tener que limitar los patrones peligrosos que un participante no fiable coloca a voluntad en el camino compartido.

Fuentes y límites de la evidencia

Los borradores y RFC establecen la evolución y la norma. El estudio informa sobre un experimento limitado de 2011, no sobre la vulnerabilidad actual de un producto. Ninguna fuente prueba el comportamiento de un navegador, proxy, CDN o servidor moderno concreto. La máscara no cifra, no autentica, no añade integridad y no demuestra que una respuesta almacenada pertenezca a su supuesto origen.