¿Es realmente necesario enmascarar cuando se envía desde el cliente Websocket?

El RFC actual de Websocket requiere que los clientes de websocket enmascaren todos los datos dentro de los marcos cuando se envían (pero no se requiere que el servidor lo haga). La razón por la cual el protocolo fue diseñado de esta manera es para evitar que los datos maliciosos sean alterados por servicios maliciosos entre el cliente y el servidor (proxies, etc.). Sin embargo, la clave de enmascaramiento aún es conocida por dichos servicios (se envía por cuadro al comienzo de cada cuadro)

¿Me equivoco al suponer que dichos servicios aún pueden usar la clave para desenmascarar, alterar y volver a enmascarar el contenido antes de pasar el marco al siguiente punto? Si no me equivoco, ¿cómo soluciona esto la supuesta vulnerabilidad?

security protocol websockets

— JSON
fuente

Respuestas:

La Sección 10.3 del RFC explica exactamente por qué se requiere el enmascaramiento. Es una respuesta muy específica a una técnica de piratería específica. El problema que está tratando de resolver se describe en un documento de 2010 llamado Talking to Yourself for Fun and Profit por algunas de las personas más seguras en seguridad del transporte por Internet.

El protocolo Websocket utiliza el enmascaramiento de cliente a servidor para evitar que los proxies traten involuntariamente los datos de WebSockets como una solicitud HTTP almacenable en caché. Puede discutir si eso es complacer a los representantes estúpidos (y creo que sí), pero esa es la razón.

— Ross Patterson
fuente

Sí, sin embargo, después de trabajar con un puñado de servicios Websocket (tanto del lado del cliente como del servidor) siento que entiendo bien el protocolo y no veo cómo sería un desafío para un proxy desenmascarar y modificar marcos sobre la marcha. a) La clave de enmascaramiento no se basa en los datos [como un hash], b) la clave de enmascaramiento no es predecible, por lo que un hombre del medio puede cambiar los datos y la clave en sí, c) (creo) un proxy puede es probable que pase marcos completamente nuevos y no solicitados [enmascarados correctamente y todo], como un cliente válido una vez que se crea / permite / oculta una sesión de cliente válida

— JSON

Dicho esto, también entiendo que probablemente no tenga el conocimiento y la experiencia de muchos de los miembros de su junta directiva cuando se tomó esta decisión.

— JSON

Parece que no leíste esa sección o el artículo al que hace referencia. El enmascaramiento no es para evitar que los proxies lean los datos, es para evitar que traten involuntariamente los datos de WebSockets como una solicitud HTTP almacenable en caché. Puede discutir si eso es complacer a los representantes estúpidos (y creo que sí), pero esa es la razón.

— Ross Patterson

+1 para la explicación. Parece que hubiera sido una mejor respuesta. Si puede mover, edite su respuesta original, sería genial.

— JSON

El enmascaramiento es inútil con wss://aka WebSockets sobre SSL / TLS. Como se recomienda utilizar SSL / TLS siempre que sea posible, puede concluir razonablemente que el enmascaramiento cubre un caso de uso marginal.

— Laurent Caillette
fuente

Esto realmente debería haber sido un comentario, pero aún no tienes suficiente reputación ...

— Adam Zuckerman