Add "Heal the Breach" protection to compression middlewares

[pbiggar]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

It can be dangerous to enable compression on encrypted requests because of BREACH attacks. As a result, many users choose not to enable compression over HTTPS, and multiple dotnet docs warn about using it.

Describe the solution you'd like

A technique called "Heal the breach" can help mitigate BREACH attacks, as discussed in https://ieeexplore.ieee.org/document/9754554. It works by modifying the gzip library to add randomness to the length of the response. If this was added to the asp.net compression middlewares, it could significantly reduce the attack surface due to BREACH.

Additional context

No response

[danmoseley]

@blowdart

[blowdart]

Cc @GrabYourPitchforks

We thought about this at the time, either by adding a random header in the response before zipping or mutating the zip headers. I can't remember why we ruled it out, but it would have been ran by our cryptographers first.

[javiercn]

@blowdart from what I understand that approach only buys you time but does not prevent an attacker from succeeding.

To give additional context about this, we can to a high degree avoid this problem by rotating our own secrets (cookies, antiforgery, anything we DP and put on a vulnerable response) but we can't prevent protected personal information that the page adds from being vulnerable to it.

An example of this would be if the application page displays the bank account number and is vulnerable to breach, there is no way in which we can know that that information needs to be "protected" (nor there is a good way to do so either).

[adityamandaleeka]

Triage: we don't want to implement this at this time. Our general recommendation is not to use compression with sensitive data.

[halter73]

Do we know if any other web stacks support this? It looks like this would require adding a new compression mode to GZipStream and DeflateStream first to add the randomness.

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.