BREACH is a category of vulnerabilities affecting the secrecy of TLS/SSL sessions. A HTTPS page is vulnerable if compression is activated and if user input is reflected on the page. To exploit the vulnerability an attacker must be able to perform specific request on the TLS session and to monitor the encrypted connection (passive man-in-the-middle).
It's very likely that applications behind Airlock are secured against BREACH since the default configuration of Airlock is safe.
Airlock is not vulnerable by default because response compression is not activated in the standard configuration. See the red box in the following screenshot. The checkbox can be found in the Basic Tab of the mapping configuration.
Check for all mappings whether compression is activated. If the compression checkbox is not set - then the mapping is secure against BREACH.
For all mappings with activated compression check whether access to the mapping is restricted. Since BREACH affects only the secrecy (and not integrity) of a TLS session the attack is not relevant for public accessible resources. If all of the following points apply BREACH affects the corresponding mapping:
- There are roles defined in "Restricted to roles" (blue box in the screenshot).
- The back-end application itself does provide a session/login/authentication mechanism and therefore does provide access to sensitive data.
- The application has to show secrets on the same page as user input is reflected.
- The mapping is used by browsers (and not only for fat clients, web service, ActiveSync, ...)
Note: We assume here that mappings providing access to sensitive data are only accessible trough HTTPS.
Mappings providing access to sensitive data with activated compression are potentially affected by BREACH. From a security point of view we recommend to deactivate compression for these mappings.
For applications where compression is mandatory we provide the following BREACH mitigation:
https://techzone.ergon.ch/breach_mitigation