Server-side Blazor should use WebSocket compression

[benaadams]

Dependent on dotnet/runtime#49304

[mkArtakMSFT]

Thanks for contacting us.
@blowdart are there any security concerns with this? Can we do this at all?

[blowdart]

The RFC acknowledges the usual compression concern,

8. Security Considerations

There is a known exploit when history-based compression is combined
with a secure transport [CRIME]. Implementors should pay attention
to this point when integrating this extension with other extensions
or protocols.

So, if you do it, it should be off by default IMO, much like http compression when TLS is on.

@GrabYourPitchforks any thoughts here?

[mkArtakMSFT]

Thanks @blowdart.
After some more discussion we've decided not to do this work as the risk involved is quite high.

[SteveSandersonMS]

It's also worth noting that Blazor Server already deduplicates strings if we know for sure that they came from compile-time constants, and hence don't vary by user input. So it's already a kind of compression for the things we know are safe.

[benaadams]

Using https://themesof.net/ as an example server-side Blazor app; its still very chonky

94.2 kB is the reload of server-side render (as it resends the starting state vs WebSocket); which is 7 kB when compressed

482 kB is clicking the open nodes button; which is super chonk

[SteveSandersonMS]

I'd personally be open to enabling an option for this if it became a common customer request. In this specific example with themesof.net, I don't think the compression oracle attacks would be a viable attack vector, since there's very limited scope for an attacker inserting their own data into the stream. Though maybe the attacker could be someone with write access to issue titles/labels.

Generally the problem with having these kinds of options is that developers may turn them on because they understand the benefits but don't understand the risks. The risk level of compression oracle attacks is really hard to estimate or communicate.