Luisn's picture

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: 
Jeremy Davis's picture

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.

Luisn's picture

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!

Jeremy Davis's picture

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:

  • SSL, GONE IN 30 SECONDS (original researchers who documented the vulnerability)
  • Defending against the BREACH Attack (Qualys SSL Labs)
  • Don't Worry About BREACH (Some random blog post which has some interesting points and perspectives)
  • Answer to "Current State of BREACH (GZIP SSL Attack)?" (on Security Stack Exchange)
  • Answer to "Whats the best custom compression method to use when I have SSL?" (on Security Stack Exchange)
  • Answer to "How to defeat CRIME, BREACH, TIME etc… server side (without sacrificing compression)" (on Security Stack Exchange)
  • Another answer (to the same question above) with some contrary info - also worth a read.
  • 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.

    Luisn's picture

    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!

    Jeremy Davis's picture

    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.

    Arron's picture

    Hi,   We are using Turnkey WordPress 15.3 Stretch and would like to enable compression. I've made the changes to the security.conf file you mentioned in the above post. I have also changed the tried chaing the "SSLCompression off" line in ssl.conf to "SSLCompression on" and commenting it out completely. But, I am still unable to get compression working.   Do you have any further things I can try to enable compression?   Thanks!
    Jeremy Davis's picture

    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?

    Bill Carney's picture

    In security.conf commented out 

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

    and then ran 

    service apache2 reload

    and compression started immediately.

    Jeremy Davis's picture

    :)

    Ken Blansette's picture

    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
    Jeremy Davis's picture

    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.

    Add new comment