Today, many modern security products offer the important capability to see within secure web traffic, otherwise known as HTTPS or SSL/TLS. Though HTTPS is intended to secure your online purchases or banking transactions, attackers increasingly use HTTPS to hide their malware command and control (C&C) channels and other nefarious activity. Products like WatchGuard’s Firebox offer administrators the ability to enable HTTPS Deep Inspection, so that our antimalware, botnet detection, and intrusion prevention services (IPS) can still detect attacks that might happen over HTTPS.
To inspect encrypted HTTPS traffic, administrators make our Firebox part of a client’s trust chain by adding a digital certificate that makes their Firebox a Trusted Root Certificate Authority (CA). This allows the Firebox to inspect all the client’s encrypted traffic, without breaking HTTPS security or the expected user experience. However, doing this properly—without accidentally downgrading the security of HTTPS—is harder than it first might seem.
Bad Deep Inspection Negatively Impacts HTTPS Communications
Recently, researchers published a study [PDF] highlighting the negative impact some security products have on TLS connections and the integrity of HTTPS communications. These researchers tested several host based antivirus (AV) products and gateway security solutions that offer content inspection for HTTPS, similar to the Firebox’s HTTPS Deep Inspection. Even though these researchers did not test WatchGuard appliances, I decided to have a deeper look at this study to find out how we might fare if they had tested a Firebox.
Adding Security Here Shouldn’t Degrade Security There
In my opinion, security solutions should not introduce significant new security risks. However, network and security vendors must always balance security with interoperability. As older encryption ciphers become deprecated, smart security vendors depreciate or remove them. That said, sometimes it’s important to support slight variations of TLS ciphers to benefit HTTPS Deep Inspection. After all, analyzing content is very important for businesses to protect environments against modern web-based threats. Without Deep Inspection, you can’t protect your encrypted connections, and according to the latest statistics at least 50% of the overall web traffic uses HTTPS.
In essence, this new research scores HTTP Deep Inspection products by auditing which encryption ciphers they support. If they downgrade to weaker outdated ciphers, they get a lower score. Unfortunately, the researchers found that 62% of these devices caused less secure HTTPS connections, and 58% even had severe vulnerabilities that might make it easier for hackers to intercept your HTTPS traffic. This, of course, led me to wonder how the Firebox’s HTTPS Deep Inspection would do.
To get straight to the point, a Firebox running current software with a well configured ruleset would score in the upper range in these tests. By default, our HTTPS Deep Inspection proxy does not support weaker, broken protocols like SSLv2 and SSLv3. Our HTTPS proxy prefers TLS 1.2, the latest TLS protocol (1.3 is coming soon). Our proxy also can use the Online Certificate Status Protocol (OCSP) to validate the original server certificate. If a certificate is expired or is not signed by a well-known certification authority that the Firebox trusts, it marks it as invalid before providing it to the browser. In addition to already using modern ciphers, Fireware version 11.11 added Perfect Forward Secrecy (PFS) ciphers to our suite to ensure the most secure TLS connections. In short, we believe our HTTPS proxy would have scored better than others in these researchers tests. At least in theory…
Real World Results
To get an objective result, I wanted to verify our Firebox HTTPS proxy’s SSL/TLS capabilities using a well-known third party SSL security test at SSL Labs. Our appliance’s result was good, as expected. The test confirmed the proxies use of TLS 1.2, and did not find our appliance vulnerable to SSL attacks like Logjam or Freak. The test also confirmed our appliance preferred and used modern and secure ciphers (for instance, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is prioritized; without HTTPS DPI Firefox 51 showed TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as prioritized cipher).
See some of our test results below:
In conclusion, my test shows that using WatchGuard’s HTTPS Deep Inspection does not introduce significant SSL/TLS degradation or vulnerability—at least if you use the latest versions of Fireware. I believe that you need HTTPS Deep Inspection if you want to survive today’s evasive threats. Unfortunately, some products HTTPS inspection features introduce new vulnerabilities of their own. However, with the Firebox’s HTTPS inspection, you get the benefit of Deep Inspection without the risk of badly implemented SSL/TLS.
Do websites who implement HSTS manage to get inspected by Watchguard or will browsers that support HSTS prevent users from accessing the site? The way WG inspects https traffic is a voluntary MITM and HSTS is there to prevent this from happening (so it’s good overall but can be a problem for https inspection).
Hey David,
HSTS (HTTP Strict Transport Security) only instructs the browser that the connection must use HTTPS and must not be accessed via unencrypted HTTP. The Firebox re-encrypts the connection after it performs its inspection, re-signing the original server certificate with the Proxy Authority certificate installed on the Firebox. Because the browser still sees an encrypted connection, HSTS validates successfully.
HPKP (HTTP Public Key Pinning) is another security feature which is commonly implemented alongside HSTS and also generates a lot of questions when it comes to HTTPS inspection on the Firebox. Websites that use HPKP instruct the browser to perform a few additional verification checks when accessing the website. First, if there is any issue at all with the server’s certificate chain or the encryption negotiation itself, the browser must prevent access to the website without allowing the user to proceed. Second, if the connection has no errors, the browser should verify that the CA certificate chain (also called the “trust anchor”) provided by the website matches the expected CA certificate chain stored in the browser’s “pin list.”
The HPKP standard allows browsers to skip the pin validation if the CA certificate chain provided in the connection contains a “user-defined trust anchor”, such as a CA certificate manually installed by the system administrator. Both Google Chrome and Mozilla Firefox disable pin validation when the CA certificate chain terminates at a user-defined trust anchor. Long story short, so long as the Firebox’s Proxy Authority certificate is correctly installed, the Firebox can still perform HTTPS inspection on websites that use HPKP.
-Marc Laliberte
P.S. Some people question what the point of HPKP is if it can be bypassed with a manually installed CA certificate. HPKP was designed to prevent rogue public certificate authorities from signing certificates to websites which they have no authority over. It was not designed to prevent intentional Man-in-the-Middle “attacks” like those used in a corporate environment.
What is about SSL/TLS renegotiation? More and more webservers test their connections for Man in the Middle attacks. We have deactivated deep inspection because of 5 to 10 new exceptions per day.
Fireware 11.12 U2 on M400
My Webroot seems to think Secplicity can’t be trusted ” – Reputation: SUSPICIOUS
When visiting this website there is a higher than average probability that you will be exposed to malicious links or payloads”
Competing products should know A) Other storied security sites are *probably safer than generic, ad plastered sites; B) Knocking a competitor’s site is kind of… suspicious. C) If this is pointing out that security related sites are prime targets, it could be more specific.
Thanks for sharing this. I reported to Webroot, and according to their reply, we should no longer show up as suspicious. Not sure why we did in the first place. Let me know if you still have the problem.
When will watchguard be able to decrypt and scan QUIC traffic? Its usage is growing and it will shortly be an IETF standard so it will become far more widespread than just google.
Matt-
We are a WG partner and our standard config has QUIC blocked via denying UDP 443 traffic. We also attempt to deny QUIC traffic via Application Control (App Control requires Basic or Total Security Suite). I have only seen a slight decrease in website performance with QUIC disabled. All sites sped up by QUIC will still work with HTTP/HTTPS on standard TCP ports.
Looking at the standard I think doing full inspection on QUIC would be problematic so the above may be a better long term strategy.
-Eric Snyder
Verus Corp