Il mascheramento è davvero necessario quando si invia dal client Websocket

L'attuale RFC Websocket richiede che i client websocket mascherino tutti i dati all'interno dei frame durante l'invio (ma non è richiesto al server). Il motivo per cui il protocollo è stato progettato in questo modo è impedire che i dati dei frame vengano alterati da servizi dannosi tra client e server (proxy, ecc.). Tuttavia, la chiave di mascheramento è ancora nota a tali servizi (viene inviata in base al frame all'inizio di ciascun frame)

Sbaglio nel ritenere che tali servizi possano ancora utilizzare la chiave per smascherare, modificare e ri-mascherare il contenuto prima di passare il frame al punto successivo? Se non sbaglio, come si risolve la presunta vulnerabilità?

security protocol websockets

— JSON
fonte

Risposte:

La sezione 10.3 della RFC spiega esattamente perché è necessario il mascheramento. È una risposta molto specifica a una specifica tecnica di hacking. Il problema che sta cercando di risolvere è descritto in un documento del 2010 intitolato Talking to Yourself for Fun and Profit di alcune delle persone più sicure della sicurezza dei trasporti su Internet.

Il mascheramento client-server viene utilizzato dal protocollo Websocket per impedire ai proxy di trattare involontariamente i dati WebSocket come una richiesta HTTP memorizzabile nella cache. Puoi discutere se questo è assecondare gli stupidi delegati (e penso che lo sia), ma questa è la ragione.

— Ross Patterson
fonte

Sì, ma dopo aver lavorato con una mano piena di servizi Websocket (sia lato client che lato server) sento di avere una buona conoscenza del protocollo e non vedo come sarebbe difficile per un proxy smascherare e modificare cornici al volo. a) La chiave di mascheramento non si basa sui dati [come un hash], b) la chiave di mascheramento non è prevedibile, quindi un uomo al centro può cambiare i dati e la chiave stessa, c) (credo) un proxy può probabilmente passano frame completamente nuovi e non richiesti [correttamente mascherati e tutti], come client valido una volta che una sessione client valida viene creata / consentita / passata di nascosto attraverso di essa

— JSON

Detto questo, capisco anche che probabilmente non ho le conoscenze e l'esperienza di molti membri del consiglio di amministrazione quando è stata presa questa decisione.

— JSON,

Sembra che tu non abbia letto quella sezione o l'articolo a cui fa riferimento. Il mascheramento non impedisce ai proxy di leggere i dati, ma impedisce loro di trattare involontariamente i dati WebSocket come una richiesta HTTP memorizzabile nella cache. Puoi discutere se questo è assecondare gli stupidi delegati (e penso che lo sia), ma questa è la ragione.

— Ross Patterson,

+1 per la spiegazione. Sembra che avrebbe fatto una risposta migliore. Se riesci a spostare, modifica la risposta originale sarebbe ottima.

— JSON,

Il mascheramento è inutile con wss://aka WebSocket su SSL / TLS. Poiché si consiglia di utilizzare SSL / TLS ogni volta che è possibile, si può ragionevolmente concludere che il mascheramento copre un caso d'uso marginale.

— Laurent Caillette
fonte

Questo avrebbe dovuto essere davvero un commento, ma non hai ancora una reputazione sufficiente ....

— Adam Zuckerman,