Le masquage est-il vraiment nécessaire lors de l'envoi depuis un client Websocket

La RFC Websocket actuelle exige que les clients Websocket masquent toutes les données dans les trames lors de l'envoi (mais le serveur n'est pas obligé de le faire). La raison pour laquelle le protocole a été conçu de cette façon est d'empêcher que les données de trame ne soient altérées par des services malveillants entre le client et le serveur (mandataires, etc.). Cependant, la clé de masquage est toujours connue de ces services (elle est envoyée par trame au début de chaque trame)

Ai-je tort de supposer que ces services peuvent toujours utiliser la clé pour démasquer, modifier et masquer à nouveau le contenu avant de passer la trame au point suivant? Si je ne me trompe pas, comment cela corrige-t-il la vulnérabilité supposée?

security protocol websockets

— JSON
source

Réponses:

La section 10.3 de la RFC explique exactement pourquoi le masquage est requis. C'est une réponse très spécifique à une technique de piratage spécifique. Le problème qu'il tente de résoudre est décrit dans un article de 2010 intitulé Talking to Yourself for Fun and Profit par certaines des personnes les plus pointues de la sécurité des transports sur Internet.

Le masquage client-serveur est utilisé par le protocole Websocket pour empêcher les mandataires de traiter sans le vouloir les données WebSockets comme une requête HTTP pouvant être mise en cache. Vous pouvez vous demander s'il s'agit de proxies stupides (et je pense que oui), mais c'est la raison.

— Ross Patterson
source

Oui, mais après avoir travaillé avec une poignée de services Websocket (côté client et côté serveur), j'estime avoir une bonne compréhension du protocole et je ne vois pas en quoi ce serait difficile pour un proxy de démasquer et de modifier cadres à la volée. a) La clé de masquage n'est pas basée sur les données [comme un hachage], b) la clé de masquage n'est pas prévisible, donc un homme du milieu peut modifier les données et la clé elle-même, c) (je crois) un proxy peut passer probablement des images complètement nouvelles et non sollicitées [correctement masquées et toutes], en tant que client valide une fois qu'une session client valide est créée / autorisée / furtivement à travers elle

— JSON

Cela dit, je comprends également que je n'ai probablement pas les connaissances et l'expérience de nombreux membres de leur conseil d'administration lorsque cette décision a été prise.

— JSON

On dirait que vous n'avez pas lu cette section ou le document auquel elle fait référence. Le masquage n'est pas pour empêcher les mandataires de lire les données, c'est pour les empêcher de traiter sans le vouloir les données WebSockets comme une requête HTTP pouvant être mise en cache. Vous pouvez vous demander s'il s'agit de proxies stupides (et je pense que oui), mais c'est la raison.

— Ross Patterson

+1 pour l'explication. Il semble que cela aurait fait une meilleure réponse. Si vous pouvez déplacer modifier votre réponse d'origine, ce serait bien.

— JSON

Le masquage est inutile avec wss://aka WebSockets sur SSL / TLS. Puisqu'il est recommandé d'utiliser SSL / TLS dans la mesure du possible, vous pouvez raisonnablement conclure que le masquage couvre un cas d'utilisation marginal.

— Laurent Caillette
source

Cela aurait vraiment dû être un commentaire, mais vous n'avez pas encore une réputation suffisante ....

— Adam Zuckerman