tfh wrote
* There seems to be quite a user friendly solution:
A very effective mitigation is HTB (Heal-the-BREACH)[8] that adds random-sized padding to compressed data, providing some variance in the size of the output contents. This randomness delays BREACH from guessing the correct characters in the secret token by a factor of 500 (10-byte max) to 500,000 (100-byte max). HTB protects all websites and pages in the server with minimal CPU usage and minimal bandwidth increase.
I know have to enable this for all 30 hosts on my server. Can you PLEASE enable global server wide settings for this kind of stuff? Maybe with an option to override it per host?
Hello,
You don't actually need to add padding to the HTTP content, because in HTTP both the response headers and the response content are part of the same bytes stream.
So inside this HTTP socket, whose encryption depends on TLS, you could very well have Abyss Web Server return random 'X-HTB-1a2b3c: whatever-variable-length-data' headers in its HTTP responses.
Also, HTTP/2 should be somewhat safer against this kind of attack since in HTTP/2 you can receive in random order the responses for any requests on the same HTTP socket.
Example: Abyss Web Server could add random HTTP headers such as:
X-HTB-1a2b3c: random-length-bytes-in-base64(20 to 80 bytes)
X-HTB-9d5a4d: random-length-bytes-in-base64(20 to 80 bytes)
X-HTB-6d5f84: random-length-bytes-in-base64(20 to 80 bytes)
Considering that 80 random bytes encoded in base64 easily exceed 100 characters, a length between 20 to 80 bytes should be good enough when encoded in base64 to add padding without tampering with the HTTP response content.
Also, for the sake of consistency, since 'Anti-Hacking Protection' is located in the global server settings that means server security-related features should be located in global settings.
So I would consider that Heal-The-Breach protection should be on the same global configuration page as Anti-Hacking Protection, since it should protect the entire server and not just some hosts but not others.
However thanks to the Aprelium developers for explaining this decision.