É realmente necessário mascarar ao enviar do cliente Websocket

O atual RFC do Websocket exige que os clientes do Websocket mascarem todos os dados nos quadros ao enviar (mas o servidor não é necessário). A razão pela qual o protocolo foi projetado dessa maneira é impedir que os dados do quadro sejam alterados por serviços maliciosos entre o cliente e o servidor (proxies, etc.). No entanto, a chave de máscara ainda é conhecida por esses serviços (é enviada por quadro no início de cada quadro)

Estou errado ao supor que esses serviços ainda podem usar a chave para desmascarar, alterar e re-mascarar o conteúdo antes de passar o quadro para o próximo ponto? Se não estou errado, como isso corrige a suposta vulnerabilidade?

security protocol websockets

— JSON
fonte

Respostas:

A seção 10.3 da RFC explica exatamente por que o mascaramento é necessário. É uma resposta muito específica a uma técnica específica de hackers. O problema que ele está tentando resolver está descrito em um artigo de 2010 chamado Conversando consigo mesmo por diversão e lucro por algumas das pessoas mais afiadas em segurança de transporte na Internet.

O mascaramento de cliente para servidor é usado pelo protocolo Websocket para impedir que os proxies tratem inconscientemente os dados do WebSockets como uma solicitação HTTP armazenável em cache. Você pode argumentar se isso está atrapalhando com proxies estúpidos (e acho que sim), mas essa é a razão.

— Ross Patterson
fonte

Sim, mas depois de trabalhar com uma mão cheia de serviços Websocket (do lado do cliente e do servidor), sinto que tenho um bom entendimento do protocolo e não vejo como seria um desafio para um proxy desmascarar e modificar quadros em tempo real. a) A chave de máscara não é baseada nos dados [como um hash], b) a chave de máscara não é previsível, portanto, um homem do meio pode alterar os dados e a própria chave; c) (acredito) um proxy pode provavelmente passará quadros completamente novos e não solicitados [adequadamente mascarados e tudo], como um cliente válido, uma vez que uma sessão de cliente válida é criada / permitida / furtivamente através dele

— JSON

Com isso dito, também entendo que provavelmente não tenho o conhecimento e a experiência de muitos membros do conselho quando essa decisão foi tomada.

— JSON

Parece que você não leu essa seção ou o artigo que ela faz referência. A máscara não é para impedir que os proxies leiam os dados, é para impedir que eles tratem inconscientemente os dados do WebSockets como uma solicitação HTTP em cache. Você pode argumentar se isso está atrapalhando com proxies estúpidos (e acho que sim), mas essa é a razão.

— Ross Patterson

+1 para a explicação. Parece que teria dado uma resposta melhor. Se você puder editar sua resposta original, seria ótimo.

— JSON

O mascaramento é inútil com o wss://WebSockets sobre SSL / TLS. Como é recomendável usar SSL / TLS sempre que possível, você pode concluir razoavelmente que o mascaramento cobre um caso de uso marginal.

— Laurent Caillette
fonte

Isso realmente deveria ter sido um comentário, mas você ainda não tem reputação suficiente ...

— Adam Zuckerman