Re: WebSockets and masking

On Fri, May 19, 2023 at 11:07:16PM +0200, Dragana Damjanovic wrote:
> Hi,
> 
> I wrote a draft that proposes adding an extension to WebSockets to
> negotiate "no-masking". The extension should be used only if intermediaries
> cannot see unencrypted traffic. In this case, the masking is not needed,
> and omitting it would reduce needed processing. The proposal has some
> problems, but I would like to hear the opinion of the group and if people
> are interested in such a feature.

I did write one application using websockets, with its own websockets
code. It always sets masking key to all zeroes on client side, and on
server side skips the unmasking if the key is zero. Server side code
does not support TLS (it relies on TLS-terminating middlebox), so there
is no way to have E2E encryption (but there is E2E auth).

Originally, the client side only supported wss, but later there was
support for unencrypted ws to localhost and some non-IP destinations.


> https://www.ietf.org/archive/id/draft-damjanovic-websockets-nomasking-00.html
> 
> A problem that I have identified with the proposal is that it will require
> TLS terminating middleboxes to change (they will need to remove the
> extension from the list), otherwise, servers behind them could wrongly
> negotiate the extension. This is not optimal.

That is just non-starter given what middleboxes exist already.

 
> Other approaches I have considered:
> 
> - making it HTTP/2- and HTTP/3-only feature and negotiating it via settings
> (In this way it cannot be transfer to unencripted part of a path). This is
> not ideal.
> 
> - Creating a new header for the feature and adding it to the “Connection”
> header in the case of HTTP/1.1 and transferring it as a setting in the case
> of HTTP/2 and HTTP/3, and
> 
> - creating a new version of the WebSocket protocol, but the negotiation of
> a new version is not ideal for this purpose and may have the same problems
> as my proposal in the draft.
> 
> Other ideas are welcome.

- Just require secure connection on client side, and place no
  requirements on server side.

  TLS will prevent the kind of middleboxes that were the motivation to
  adding masking to websockets.

  And the kind of attacks discussed will not work through TLS
  terminating middlebox, and even if any attack worked, it would seem
  to be exploitable already.

  And requirement for E2E encrypted connection would be a severe
  deployment problem. There are a LOT of reverse proxies out there,
  mostly for good reasons.




-Ilari

Received on Saturday, 20 May 2023 09:48:03 UTC