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?

    Add new comment