Good Enough Security Redux: SSL Inspection Devices Can Make Networks Less Secure
A few months ago, I wrote about the concept of “Good Enough” security. This explored the thought that having DNS-based internet security is good enough to secure a network from most, if not all, internet-based threats. These technologies necessarily make tradeoffs between security, performance, budget, and user experience in order to check a box that internet security is implemented. Similar to how organizations are turning to “good enough” security to perform internet content inspection, they also acquire “good enough” solutions to inspect encrypted traffic, commonly referred to as SSL Inspection. Just as is the case with good enough internet content inspection, good enough SSL Inspection is simply not.
NOTE: For this article, I will be using the term "SSL Inspection" for simplicity since it is the industry accepted terminology, even though modern secure communications today mostly use TLS.
With the rise of HTTPS encrypted traffic and knowing that end-users and their respective clients are typically the weakest link in the information security chain, organizations are turning to SSL Inspection technology to decrypt and inspect normally unreadable traffic. SSL inspection has been gaining popularity in the last few years for two separate, yet very compelling reasons. The first is content inspection for detecting malware and attacks hidden in SSL and TLS encrypted channels. Attackers know that many organizations still do not perform inspection of encrypted traffic and take advantage of that fact to deliver malicious payloads and command and control traffic over encrypted channels. The second reason covers compliance and legal requirements to prevent the unauthorized disclosure of intellectual property, copyrighted material, trade secrets, and non-public material information, commonly referred to as Data Loss Prevention (DLP). SSL Inspection is typically performed using a Man-in-the-Middle TLS Proxy, leveraging dedicated hardware, software, or a cloud service to terminate an SSL/TLS session from a client, inspect the content, then establish a second SSL/TLS session to the destination server. In the past, performing this inspection was trivial since HTTPS connections were simple and straight-forward. With the advent of stronger cipher suites, handshake mechanisms, and validation techniques, many SSL Inspection vendors have not kept up with these advances and are still relying on old and insecure methods for decrypting traffic.
Just like cryptography and encryption, SSL Inspection is an important part in securing an organization’s information and assets, but only if properly implemented. When implemented incorrectly, these technologies could give organizations at best a false sense of security and at worst make them less secure. Security researchers at Concordia University in Montreal, Canada set out to investigate the landscape of SSL Inspection technologies today and their results were surprising. The research team looked at 17 versions of 13 TLS network appliances for nearly a year between 2017 and 2018 and found that of these 17 appliances, four appliances perform no certificate validation, three use pre-generated certificates instead of dynamically generated, and eleven accept certificates signed using the outdated MD5 hashing algorithm, exposing their clients to malicious Man-in-the-Middle (MitM) attacks.
By definition, performing SSL Inspection increases the attack surface by introducing a TLS Proxy into the data stream. That TLS Proxy necessarily needs to be as up to date and secure as a modern web server in order to not subject the connection to attacks such as protocol downgrade to weaken the connection to outdated or insecure ciphers. Certificate validation must also be as strict as modern web browsers since end users will only see proxy-generated certificates and will not be performing the validation on the destination server’s actual SSL certificate.
Some notable findings from the research:
Three vendors did not perform any certificate validation. These appliances allowed invalid TLS certificates to be trusted by the end clients
Two vendors do not perform any certificate validation in their default setups because a setting for "accepting all certificates" is enabled by default. Even after disabling this setting, one of the two vendors still did not perform any certificate validation
One vendor accepted self-signed certificates, enabling MitM attacks
Three vendors used pre-generated keys instead of dynamically generated keys at installation
Four appliances accept their own certificates for externally delivered content. If an attacker can gain access to the private keys on these appliances, it would be trivial to perform a MitM attack
All appliances, except for two vendors, accept certificates signed using the outdated and insecure MD5 hashing algorithm
Five vendors still accept MD4, considered obsolete since 2008, the year Barack Obama was elected president
Five vendors accept RSA-512, broken in 1999, the year the South Park movie “Bigger, Longer, Uncut" was originally released
Researchers responsibly disclosed their findings to the respective security vendors and were met with a lackluster response. Many vendors ignored the disclosure and the vulnerabilities discovered are still in use today. For one vendor, their security posture actually got worse over time. For another vendor, their attempt to patch existing vulnerabilities actually introduced more vulnerabilities than were actually patched.
When evaluating SSL Inspection technologies, it is just as important to investigate the methods used to decrypt and re-encrypt the traffic as it is for traditional metrics such as malware detection rate. When it comes to upgrading SSL Inspection technology to support modern ciphers and technologies, cloud vendors tend to do better since they are always running the latest version of software available and there is no downtime or end-user maintenance required. Patching is just like flossing teeth, something that can be put off just one more day.