Re: WebSockets and masking

On Fri, May 19, 2023 at 02:30:50PM -0700, David Schinazi wrote:
> Hi Dragana, and thanks for writing this up!
> 
> I agree with you that the main motivations for masking don't matter as much
> when WebSocket runs over TLS or QUIC (though AEADs without random IVs allow
> a collaborating client and server to predict the next keymat...).

Note that masking was not designed to protect the contents from snooping,
but to make sure an application running in a browser cannot forge the
contents sent onto the wire to make it look like another protocol (HTTP,
SMTP etc). So actually I think that being transported over TLS doesn't
change the paradigm: is the WS connection is sent to a TLS port and the
client starts sending the HTTP upgrade that is taken for junk by the
server on this TLS port and causes errors to be reported back, then the
client sends application-controlled data, the problem remains the same:
the WS termination gets raw traffic and if it doesn't understand WS well
it may very well pass on this decrypted traffic to another location.

IMHO due to the fact that the initial handshake requires a valid response
from the server, and that servers supporting upgrade are essentially those
supporting WS, this risk is probably zero or very close to zero. However
when transported over H2 using a CONNECT that should normally be converted
to an HTTP/1 upgrade as per RFC 8441, we cannot fully rule out the
possibility that a lazy or bogus gateway advertises support for this RFC
but doesn't perform an upgrade and instead performs just a CONNECT to a
remote host (this would obviously be a big bug in that gateway).

My personal feeling is that this masking tries to cover risks that do
not exist anymore due to how the protocol works, and that would only
depend on purposely written bugs in intermediaries, in a way that's so
advanced that we could even expect them to remove the masking before
passing the traffic if such bugs were to be found and exploited. But
I find it important not to forget why this masking was added in the
first place, and not to solely focus on intermediaries but consider the
ability of the end point to play the role of such an intermediary.

> However,
> it's not clear to me why the overhead of masking matters. I wouldn't expect
> the XOR to be visible on CPU traces. Is this masking causing noticeable
> performance issues in your environment?

I agree. I would think that the total amount of CPU time saved on the
planet by removing XOR would be lower than the total human time involved
in writing and implementing an extension to drop it!

Thanks,
Willy

Received on Saturday, 20 May 2023 03:57:05 UTC