You are here
Luisn - Sun, 2019/03/03 - 17:01
Hello!
I've double checked if apache2 mod_deflate is enabled, but it doesn't seem to work.
I've tried to enable the compression in wordpress trough htaccess, but it doesn't work.
Is there a way to force it to compress everything?
Thanks a lot!
My htaccess:
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
<IfModule mod_setenvif.c>
<IfModule mod_headers.c>
SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
</IfModule>
</IfModule>
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE "application/atom+xml" \
"application/javascript" \
"application/json" \
"application/ld+json" \
"application/manifest+json" \
"application/rdf+xml" \
"application/rss+xml" \
"application/schema+json" \
"application/vnd.geo+json" \
"application/vnd.ms-fontobject" \
"application/x-font-ttf" \
"application/x-font-opentype" \
"application/x-font-truetype" \
"application/x-javascript" \
"application/x-web-app-manifest+json" \
"application/xhtml+xml" \
"application/xml" \
"font/eot" \
"font/opentype" \
"font/otf" \
"image/bmp" \
"image/svg+xml" \
"image/vnd.microsoft.icon" \
"image/x-icon" \
"text/cache-manifest" \
"text/css" \
"text/html" \
"text/javascript" \
"text/plain" \
"text/vcard" \
"text/vnd.rim.location.xloc" \
"text/vtt" \
"text/x-component" \
"text/x-cross-domain-policy" \
"text/xml"
</IfModule>
<IfModule mod_mime.c>
AddEncoding gzip svgz
</IfModule>
</IfModule>Forum:
Tags:
It should be enabled by default?!
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:
If it's not already enabled, enable it:
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.
Configuration is Ok
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!
Ah ok, I'm guessing that you're referring to HTTPS compression?!
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):
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-gzipActually, here's a one liner to do that for you:
Then restart Apache:
You should now have compressed HTTPS.
Thanks a lot for your answer
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!
If you are really careful, it's still possible
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.
Hi Arron
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
In security.conf commented out
SetEnvIfExpr "%{HTTPS} == 'on'" no-gzipand then ran
and compression started immediately.
Thanks bill!
:)
SSL compression on WordPress 16.0 appliance
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?
OpenSSL no longer supports compression
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'):
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.
Add new comment