Re: WebSockets and masking


I have updated the draft incorporating the feedback:

The new version only requires the use of a secure connection on the client
side and places no requirements on the server side.

I am looking for feedback on the approach and interest in the feature.


On Mon, May 22, 2023 at 1:57 PM Dragana Damjanovic <> wrote:

> Hi,
> I am answering multiple emails in one email.
> I do not have a scenario where masking causes noticeable performance
> issues. I was trying to figure out if it is possible to remove it if a
> server wants to remove it.
> From the discussion, I hear that requiring TLS on the client side may be
> enough?
> Dragana
> On Sun, May 21, 2023 at 12:54 PM Martin Thomson <> wrote:
>> On Sat, May 20, 2023, at 19:47, Ilari Liusvaara wrote:
>> >   TLS will prevent the kind of middleboxes that were the motivation to
>> >   adding masking to websockets.
>> Not necessarily: those middleboxes were so terrible they would probably
>> be vulnerable to an attack that mutated the ciphertext so that looked like
>> cleartext HTTP.  See also the NAT slipstreaming attacks.  But also maybe
>> not: they are probably not so widely deployed any more[*].  It has, after
>> all, been some time.
>> [*] I considered the possibility that they might not look at ports other
>> than 80, but you can run TLS on port 80.
>> It's only time then that might change our attitude toward masking.  We
>> might reasonably conclude that middleboxes that are that awful are no
>> longer worth protecting.  By extension, however, that means concluding that
>> the endpoints, for whom those middleboxes might have caused problems, are
>> less reliant on those middleboxes.  Remember that the attack was ultimately
>> on endpoints that were being served up malicious content by those
>> middleboxes.  But there is a lot less content around that is unsecured now,
>> so maybe it's OK.
>> FWIW, we deliberately shipped QUIC without equivalent protection against
>> this particular class of attack.  It's harder to attack QUIC, but not
>> impossible.
>> >   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.
>> Yeah, I think that the requirement for TLS more or less rules out these
>> sorts of tricks for protecting endpoints.  Endpoints need to protect
>> themselves (and a TLS terminator is an endpoint as far as something like
>> masking is concerned.)

Received on Thursday, 6 July 2023 13:30:03 UTC