Gzip compression

security

(Zoran Pajeska) #1

Since gzip compression is recognized as a security breach, any chance to deactivate it?

  • SonarQube on alpine image (dokcerfile, version 7.1, alpine, embedded tomcat)
    (https://github.com/SonarSource/docker-sonarqube/tree/master/7.1-alpine)
  • I am trying to disable gzip compression. Any chance to deactivate it? Currently, image use embedded tomcat and I would like to use parameter inside run.sh for disabling compresion (file avaible in the repository) or use sonar.properties.

Thanks in advance


(Dinesh Bolkensteyn) #2

@zoran27 Which security vulnerability are you referring to? https://en.wikipedia.org/wiki/BREACH?


(Zoran Pajeska) #3

@dbolkensteyn I am reffering to CVE-2013-3587


(Dinesh Bolkensteyn) #4

Yes so that is indeed the BREACH vulnerability.

Our security experts are currently looking into this and we will get back to you - I am unable to tell you exactly by when though.

Thank you for bringing this to our attention.


(Zoran Pajeska) #6

@dbolkensteyn Thanks :slight_smile: Some parameter when you run sonarqube will be great :slight_smile:


(Christophe Lévis) #7

Hi @zoran27 ,

According to security experts, BREACH seems to be a pretty complex attack that requires a man-in-the-middle position. The risk is low in the case of SonarQube because it has a CSRF protection.

We don’t know what the impact on performance would be if compression is deactivated. If you really want to take additional precautions, a better solution could be to only allow TLS1.3 encryption in your reverse proxy. Since TLS1.3 is quite new and not yet well adopted, you could also consider using some solutions to append random HTML comments to vary the response size. For ex, if your instance is served by nginx, you could use a module such as https://github.com/nulab/nginx-length-hiding-filter-module.