Re: WebSockets and masking

Hi,

I have updated the draft incorporating the feedback:
https://datatracker.ietf.org/doc/draft-damjanovic-websockets-nomasking/

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.

Dragana

On Mon, May 22, 2023 at 1:57 PM Dragana Damjanovic <
dragana.damjano@gmail.com> 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 <mt@lowentropy.net> 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.)
>>
>>