Apache2 mod_deflate not working on wordpress app

FWIW, I just launched a v15.1 LAMP server and ran it through an online http compression check (as well as manually checking from the commandline too). By default, the vanilla HTTP traffic is already being compressed but the HTTPS traffic isn't.

TBH, I had forgotten about that. We disabled both TLS and HTTP gzip compression on HTTPS traffic by default as it is the only way to reliably ensure that your server and users are protected from BREACH attacks.

As noted by Apache (within the documentation for Deflate):

Compression and TLS
Some web applications are vulnerable to an information disclosure attack when a TLS connection carries deflate compressed data. For more information, review the details of the "BREACH" family of attacks.

If you're unfamiliar with BREACH and would like some further reading (beyond the Wikipedia page) then here are some resources that may be of interest:

Since the revelation of BREACH, all major browsers have implemented mitigations, but AFAIK the attack is still possible under specific circumstance. Mitigating it completely (without disabling compression) is impossible unless you know all the contributing factors, and the internals of the particular software being run (both on server and client). As such, as a matter of best practice, we have erred on the side of caution and disabled HTTPS compression by default for all appliances (unless we have explicit information noting that the vendor mitigates against it). FWIW, I did try to find out whether WordPress has some specific mitigation factors against BREACH, but was unable to conclusively be sure one way or the other. If you have any further info, I'd love to hear.

So the bottom line is that security is best served by leaving HTTPS compression disabled. If you are sure that there are sufficient mitigations in place, or feel for some other reason that the advantages of compression outweigh the possible implications of a BREACH attack, then by all means, re-enable it.

If you wish to push ahead and enable HTTPS compression, then it should be as simple as editing the Apache Security module config, i.e. /etc/apache2/conf-available/security.conf Look for the line below and comment it out (i.e. add a # to the start of the line):

SetEnvIfExpr "%{HTTPS} == 'on'" no-gzip

Actually, here's a one liner to do that for you:

sed -i "/no-gzip/ s|^|#|" /etc/apache2/conf-available/security.conf

Then restart Apache:

server apache2 restart

You should now have compressed HTTPS.

I've checkd and it is all rightly configurated.

Might there be any other reason why the commpression is not taking place?

Thanks a lot!

AFAIK, it should be enabled by default. Although TBH I'm not particularly familiar with Deflate in Apache. Regardless, (at least in theory) it should "just work". To check which modules are enabled:

apache2ctl -t -D DUMP_MODULES

If it's not already enabled, enable it:

a2enmod deflate
service apache2 restart

Also, it should already be configured by default in our WordPress appliance, but make sure that you have 'AllowOverride All' within the relevant part of your Apache config (otherwise .htaccess files will not be processed). E.g. see line 18 of our default WordPress Apache config.

If you are really careful to only allow compression of specific files via HTTPS and have an understanding of any mechanisms which the software you're running might have to mitigate it, then it is still possible to decrease page load times without causing a significantly increased risk.

Unfortunately though, that is only feasible with specific context to your individual scenario. There is no way for us to ship generic config to ensure that users are not vulnerable just because they installed a new plugin, or make some minor config change. So we err on the side of caution. We'd hate to hear that someone using our servers got themselves into trouble with our default config.

If you do wish to persevere, it will require a fair bit of research and understanding on your end. If you decide to do that, please feel free to share any useful info your come across, as I'm sure it will be useful for others.

We're still hoping that there will be some future improvements to TLS that make blanket compression of compressed content a worry free option, but I doubt it will happen anytime soon (the jury still appears to be out on what the best process would be to support that). Padding seems to be a potential option, but I guess we'll need to wait and see.

Good luck with it all.

Thank you very much for your extense and detailed answer.
The idea is loweriong loading times of my page, and compressing seems to be an important factor. But as you kindly made me see, it is less important than security.

Have a nice day!

It's a little while since I tested this, but when I did, I confirmed that following all the above steps that I noted, it should "just work".

It sounds like either there was a step that I neglected to document, or something has changed?! I would have expected it to change as my tests were done on a v15.x LAMP server (which is the basis of the WordPress appliance). The only other thing that occurs to me as a possibility is that perhaps you missed the step about restarting Apache? The updated settings won't be applied until the Apache service is restarted.

When I get a chance, I'll try configuring this again and post back with my results.

PS it's possibly worth noting that TurnKey v15.x is Debian 9/Stretch under the hood. Whilst we do apply some custom config (mostly security hardening) documentation for Debian should still apply. So you may find something via google?

:)

In security.conf commented out 

SetEnvIfExpr "%{HTTPS} == 'on'" no-gzip

and then ran 

service apache2 reload

and compression started immediately.

Apache still allows you to set that, but OpenSSL doesn't support TLS layer encryption since version 1.0.0. So you'd need to get an old insecure copy of OpenSSL to support that. FWIW, Apache will actually tell you that if you do a config test. I.e (with 'SSLCompression on'):

apachectl configtest

AH00526: Syntax error on line 13 of /etc/apache2/sites-enabled/mantis.conf:
This version of OpenSSL does not have any compression methods available, cannot enable SSLCompression.
Action 'configtest' failed.
The Apache error log may have more information.

Having said that, compressed content delivered via HTTPS is still possible, just not on the TLS layer. Instead you'll need to compress the plain HTTP (prior to encryption). So what you are most likely after is Apache's mod_deflate.

As you appear to be aware, enabling it entails potential security implications. The disabling of compression at the TLS layer (as current OpenSSL does) protects against the "CRIME" exploit. Enabling compression at the HTTP level makes your client connections potentially vulnerable to the somewhat similar BREACH vulnerability.

BREACH has more impact at the application level and does not have quite the same on/off type secure/insecure dichotomy. Wihtout knowing the content being served, the only guaranteed mitigation against BREACH is to not use compression, hence why we ship all of our appliances with no compression enabled. However, if you have a known piece of software that you trust (e.g. WordPress itself should be pretty trustworthy, although be careful with third party plugins!) and are sure that it is pro-active protecting against CSRF (cross-site request forgery) attacks, then compressing some content can be done relatively safely. That is particularly the case with static content such as images, javascript, css, etc.

Having said all that, I personally don't have a ton of experience with using HTTP compression and managing "high value" webservers long term in a hostile environment. Plus there is just no easy definitive way to guarantee safety when sending compressed content via HTTPS. So I am unable (and unwilling) to give you an example that will "just work" and remain secure. The Apache mod_deflate docs are a pretty good start IMO. Plus you'll likely find plenty of further info online if you desire.

Please post back and let us know how you go. I'd be really interested to hear how you end up configuring things.

Is there a way to enable gzip over ssl on the WordPress 16.0 version? Seems to be structurally different and a simple change (shown below) to /etc/apache2/mods-available/ssl.conf to turn SSL compression on causes apache to fail on load. Also the older security.conf command line to comment out is now gone. I understand the security issue, but we need to be able to use this over SSL in certain rare circumstances. What is the new procedure for this?

SSLCompression on

Sure it sucks, but security is always a tradeoff.

Did you read my post above? While we're now in 2025, it still applies. Despite the fact that BREACH is ~12 years old, unless you can be sure that the webapp explicitly provides the required mitigation against it it remains a potential issue. We are not sure which applications mitigate those attacks so for security sake, we continue to leave https gzip compression disable as per the default config provided by Debian.

Many of our users are not particularly experienced with Linux, let alone web server security measures. We have implemented additional web server security tweaks that arguably provide some mitigation against this class of attacks. But we remain skeptical that they are sufficient to provide enough protection to unaware users.

We take security seriously and part of our mission is to provide the best balance of security, performance and usability that we can. It is impossible to "have it all" so deciding on which compromises we are willing to make on behalf of our users is part of our role. If you use a TurnKey server and are willing to make a different compromise and/or can confirm that your particular use case is not vulnerable to compression attacks then you are free to change the settings as you see fit.

Having said all that, your post has prompted me to consider creating a whilelist of applications that do have mitigations. We can then enable gzip compression for them on a case by case basis and document our rationale. I make no promises regarding when we will have time to look at that, but I've added an issue to our tracker.

If you have specific knowledge that can guide us further, I welcome your input.

This sucks big-time. I mean, un-allowing gzip compression these days when speed is a major contributor to site ranking seems backwards. Surely you guys could of implemented this a better way... 2025 and no gzip compression?