Latest Student Article:
- Visibility vs Confidentiality (4/25/2017)
Debating the Value of SSL Encryption
Security is all about tradeoffs and trust. A recent article, US-CERT’s Warning on SSL Interception vs. Security is a False Dichotomy (itself a response to US CERT warning TA17-075A HTTPS Interception Weakens TLS Security) neatly illustrates that point. Which should take precedence; the integrity of structures ensuring confidentiality, or having visibility into potential malware vectors?
Before we step into that debate, let’s describe the underlying technologies in brief. Two technologies work hand in hand to secure web traffic, each serving a different role. Digital certificates issued by Certificate Authorities (CAs) are a form of authentication and provide a starting point for encryption such as TLS. TLS (also known as SSL, more on that later) is the protocol used to encrypt communications between client and server, ensuring confidentiality. Together[1] these are the basis for Secure HTTP, more commonly known as HTTPS.
Digital Certificates
When you type in ‘google.com’, your client (your browser) reaches out to the server hosting google.com. Because Google (responsibly) insists on using HTTPS, the server automatically instructs your browser to use port 443. The client then examines the server’s certificate (which is sort of like a driver’s license: it describes the identity of the server) and tries to decide if the server is trustworthy. Here is where Certificate Authorities come into play. Every browser has a list of trusted CAs called a root certificate store. These CAs are third-party organizations responsible for verifying the website’s identity and issuing that website a unique certificate tied to that identity. DigiCert, Symantec, and GoDaddy are a few examples of CAs. Because your browser trusts the issuing Certificate Authority, it will trust any website that received a certificate from that CA. To continue using the driver’s license analogy, this would be like taking a Wisconsin driver’s license at face value because you trust the DMV of the state of Wisconsin.
Digital certificates are an important system underpinning the security of the internet; without them you would have no way of knowing whether the site you were viewing was legitimate or an imposter. If someone found a way to redirect your request for google.com to their own server, then they could control the content you accessed, putting malware on your machine, harvesting your credentials, or running a scam. With certificates this is nearly impossible: because of the mathematics behind the technology it is far more difficult to spoof or fake a certificate than to make a fake driver’s license.
SSL & TLS
SSL stands for ‘Secure Sockets Layer’ and was the first widely used encryption protocol for secure HTTP communications. Though the actual protocol was replaced by the superior Transport Layer Security (TLS) protocol, over time the term ‘SSL’ has become less the name of a protocol and more the name of the technology in general. Be aware that most discussions use the terms SSL and TLS interchangeably.
TLS uses the information in the server’s certificate to generate the key used for encrypted communications. This means that if anyone is sniffing your web traffic (especially easy to do with wireless networks) they will only see what appears to be random noise[2]. Used in conjunction with certificates end users can browse with a high degree of confidence in the sites they are visiting.
Digital Certificates and TLS serve as a method of ensuring trust and establishing trust relationships. This seems to be wholly a good thing, but every security measure has tradeoffs. Where are the tradeoffs here? There are a few minor penalties at the protocol level that we won’t discuss here, but there is also a significant tradeoff from an enterprise security perspective. In many cases an entity has a legitimate reason to view or inspect traffic, and cannot because of HTTPS. If you are on a security team charged with making sure your company doesn’t become compromised it is vital you be able to monitor traffic, even encrypted traffic. After all, just because a server is authenticated does not mean it is benign—from malvertising (advertising that delivers malware through javascript or flash) to compromise, nearly any site is a potential vector for malware or data exfiltration.
SSL Interception
This brings us to SSL interception (also known as HTTPS Interception, or SSL Proxy). This is usually implemented by placing a server near the network edge (at the firewall or other device) and giving it a trusted certificate. When a client goes to connect to a site (for example google.com) the connection is intercepted: the client is actually connecting to the proxy, and the proxy then connects to google.com on the client’s behalf. By acting as an intermediary and using its own certificate, the proxy is able to decrypt the traffic to inspect it, then re-encrypt it as it is sent on to Google. Because the proxy has a trusted certificate this process is entirely transparent to the user, at most adding a few milliseconds of latency.
While this may sound like a hacker’s tool (isn’t man-in-the-middle traditionally a black hat tactic?) it is usully implemented by network security teams within enterprises. It’s important to remember that for this to work without displaying warning messages the browser on the certificate either needs to be installed in the browser’s root certificate store or issued by a trusted CA, which is difficult to accomplish for a most attackers. Many companies will even use their own internal CA and distribute its certificate to all Active Directory members via group policy.
The Debate
Armed with that background knowledge, we can now jump into the US Cert warning and Security Week’s response.
US Cert’s warning on the dangers of SSL interception was directed at companies that use these SSL proxies. According to the article, using a SSL inspection product creates not only another point of failure, but potentially introduces security vulnerabilities. This technology is relatively new, and some vendors have weaker implementations of TLS which in turn weakens the security of the connection. Worse still, some do not verify the certificate chain of the destination server—in other words, they don’t make sure the certificate is from a trusted source. This may permit a man in the middle attack between the proxy and the destination, the very thing digital certificates are designed to protect against. Lastly, this is one more server and service that must be managed and configured properly, and a weak understanding of the underlying technology often leads to misconfiguration by the administration team implementing and supporting it.
David Holmes in his column on Security Week points out that the risks of poor design and implementation are not a valid reason to avoid a technology, and accuses US Cert of creating a false dichotomy—a binary decision between not using SSL interception and using it poorly. This neglects the third and somewhat obvious option of proper, effective implementation. He also points out that the greatest threat organizations face is not man-in-the-middle attacks but malware, and SSL interception can be a powerful tool in a security admin’s arsenal.
In the end, I would suggest that technology be evaluated based on its merits when properly configured and used, implemented with appropriate care to avoid flaws, and finally verified to ensure that it is working as expected and does not compromise security. SSL interception serves a valuable purpose in an organization when used and administered effectively. An excellent place to start when verifying is badssl.com—a website mentioned in both the US Cert warning and the Security Weekly article. The site hosts a series of tests that verifies digital certificates and related protocols.
As powerful as SSL interception is, it is not appropriate in every use case. A better understanding of the trusts and tradeoffs involved will equip you to make the best decision for your specific situation and environment. To that end reading the two articles referenced here is a good start. Good luck, and stay secure!
[1] Hashing can optionally be added for integrity.
[2] Sniffing to see noise. This shouldn’t make ‘sense’, but it does. English! Also, puns!
Past Student Articles:
- A Study of Password Security, Part 2 (3/10/2017)
For the majority of users, Part 1 should satisfy all your password needs, so start there if you haven’t read it already.
But what if your password manager doesn’t have a password generator built in? Or you are an Advanced User™ and like having control of your life no matter how complicated things get. Or perhaps you were scarred when your GitLab project suddenly disappeared and don’t trust software to remember your data if something fails. With your own password generation algorithm, you can make and salvage passwords even if your password manager fails.
- A Study of Password Security, Part 1 (2/28/2017)
Everyone knows password security is ‘A Thing’ [citation needed]. And everyone knows why: online sites, stores, and personal computers get compromised (hacked, broken into, or have data stolen through other means) all the time. Identity theft can ruin reputations and bank accounts. Worst of all someone could steal all of your level 80 character’s gear. So what does ‘everyone’ do about it?