Common practice is to not use TLS and always keep using the latest version of the protocol, however, there is one danger that needs to be carefully considered: Compression.
When configuring a web server, many people are using either the default configuration, or a template, and adapt them to their needs.
It goes without saying that there is no excuse any more today to not use TLS (especially since the existence of Let’s Encrypt), and always keep using the latest version of the protocol.
But there is one danger that needs to be carefully considered: Compression.
Compression is used to reduce the size of the content transmitted with the goal of e.g. faster page load. However, the combination of encryption and compression at the same time is subject to the so-called BREACH attack. Unless you are 100% sure that this attack is not possible given how you are serving your content, we recommend disabling compression altogether. And, believe us, you cannot be 100% sure in most cases.
Here are the configurations you need to look out for for the most common web servers out there.
The configuration on the `http` level should be `gzip off`, which is the default. Ensure that you do not overwrite it on a `server` or `location` level. The documentation is here.
If you find in your `httpd.conf` the line
LoadModule deflate_module modules/mod_deflate.so
Then the module for compression is loaded. The general use is described here.
IIS has two extensions that need to be installed when using compression: The StaticCompressionModule, and the DynamicCompressionModule.
When these are installed, a <httpCompression> tag can be defined e.g. inside the ApplicationHost.config file. There, you can set the different mime-types where static resp. dynamic compression should be applied. Read the documentation here for more information.
.png)
