WIP: Properly enable gzip compression in nginx config

norm commented

2024-03-14 04:09:09 +00:00

Contributor

Given that there's already a bunch of other gzip options set in the
nginx config, it's likely someone forgot to actually add the setting to
turn gzip on, so let's fix that.

Given that there's already a bunch of other gzip options set in the nginx config, it's likely someone forgot to actually add the setting to turn gzip on, so let's fix that.

norm added 1 commit 2024-03-14 04:09:09 +00:00

Properly enable gzip compression in nginx config

ci/woodpecker/pr/build-amd64 Pipeline is pending

Details

ci/woodpecker/pr/build-arm64 Pipeline is pending

Details

ci/woodpecker/pr/docs Pipeline is pending

Details

ci/woodpecker/pr/lint Pipeline is pending

Details

ci/woodpecker/pr/test Pipeline is pending

Details

9cec6aa5a1

Given that there's already a bunch of other gzip options set in the
nginx config, it's likely someone forgot to actually add the setting to
turn gzip on, so let's fix that.

Oneric commented

2024-03-15 16:51:21 +00:00

Member

Just to make sure, it’s probably best to first check whether we already have defenses against the BREACH attack

Just to make sure, it’s probably best to first check whether we already have defenses against the [BREACH](https://en.wikipedia.org/wiki/BREACH) attack

Oneric commented

2024-04-05 23:02:01 +00:00

Member

From https://breachattack.com:

To be vulnerable, a web application must:

Be served from a server that uses HTTP-level compression

with this patch, yep

Reflect user-input in HTTP response bodies

yep (e.g. received posts)

Reflect a secret (such as a CSRF token) in HTTP response bodies

yep, responses always include a set-cookie directive for __Host-pleroma_key and it seems to stay the same for multiple requests

Additionally, while not strictly a requirement, the attack is helped greatly by responses that remain mostly the same (modulo the attacker's guess).

This last bit might be hard for people following many accounts, as they might receive many notifications, posts on TL, etc

.

Afaict except for (possibly too liberal) rate limiting, none of the proposed countermeasures is implemented:

A very effective mitigation is HTB (Heal-the-BREACH) that modifies the server-side gzip compression library to add randomness to the size of the response content.

i couldn’t find anything on how to enable this for nginx

Other mitigations are ordered by effectiveness (not by their practicality - as this may differ from one application to another).

Disabling HTTP compression

Separating secrets from user input

Randomizing secrets per request

Masking secrets (effectively randomizing by XORing with a random secret per request)

Protecting vulnerable pages with CSRF

Length hiding (by adding random number of bytes to the responses)

Rate-limiting the requests

While i’m not sure how practical it is for an attacker to both inject plaintext and measure the size of packets received by the victim, it seems best to me to be careful here and only enable compression after adding some more countermeasures here.
Ideally HTB, otherwise e.g. sending the __Host-pleroma_key only once for each value (though this probably requires some care and possibly server overhead to track who received the key already and if it was received successfully), more frequent Host-key rotations or adding an unused padding header X-Akkoma-Random-Padding to each response with a random length of random data.

From https://breachattack.com: > To be vulnerable, a web application must: > > - Be served from a server that uses HTTP-level compression with this patch, yep > - Reflect user-input in HTTP response bodies yep (e.g. received posts) > - Reflect a secret (such as a CSRF token) in HTTP response bodies yep, responses always include a `set-cookie` directive for `__Host-pleroma_key` and it seems to stay the same for multiple requests > > Additionally, while not strictly a requirement, the attack is helped greatly by responses that remain mostly the same (modulo the attacker's guess). This last bit might be hard for people following many accounts, as they might receive many notifications, posts on TL, etc . Afaict except for (possibly too liberal) rate limiting, none of the proposed countermeasures is implemented: > A very effective mitigation is HTB (Heal-the-BREACH) that modifies the server-side gzip compression library to add randomness to the size of the response content. i couldn’t find anything on how to enable this for nginx > Other mitigations are ordered by effectiveness (not by their practicality - as this may differ from one application to another). > > 1. Disabling HTTP compression > 2. Separating secrets from user input > 3. Randomizing secrets per request > 4. Masking secrets (effectively randomizing by XORing with a random secret per request) > 5. Protecting vulnerable pages with CSRF > 6. Length hiding (by adding random number of bytes to the responses) > 7. Rate-limiting the requests While i’m not sure how practical it is for an attacker to both inject plaintext _and_ measure the size of packets received by the victim, it seems best to me to be careful here and only enable compression after adding some more countermeasures here. Ideally HTB, otherwise e.g. sending the `__Host-pleroma_key` only once for each value (though this probably requires some care and possibly server overhead to track who received the key already and if it was received successfully), more frequent Host-key rotations or adding an unused padding header `X-Akkoma-Random-Padding` to each response with a random length of random data.

👍 1

norm changed title from ~~Properly enable gzip compression in nginx config~~ to WIP: Properly enable gzip compression in nginx config

2024-04-06 01:34:42 +00:00

norm commented

2024-04-06 01:35:23 +00:00

Author

Contributor

Marking as WIP until proper BREACH mitigations are in place

ci/woodpecker/pr/build-amd64 Pipeline is pending

Details

ci/woodpecker/pr/build-arm64 Pipeline is pending

Details

ci/woodpecker/pr/docs Pipeline is pending

Details

ci/woodpecker/pr/lint Pipeline is pending

Details

ci/woodpecker/pr/test Pipeline is pending

Details

This pull request is marked as a work in progress.

This branch is out-of-date with the base branch

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u nginx-gzip:norm-nginx-gzip

git checkout norm-nginx-gzip

WIP: Properly enable gzip compression in nginx config #721

Checkout