Information Security
Maksim Kabakou - Fotolia
HTTPS interception gets a bad rap; now what?
Should products intercept Transport Layer Security connections to gain visibility into network traffic? A new study by researchers and U.S.-CERT warn against it.
In March, the United States Computer Emergency Readiness Team issued an Alert (TA-17-075A) notifying security managers that "HTTPS Interception Weakens TLS Security."
Secure internet communications that adhere to privacy and data protection standards may mean that enterprises continue to have a blind spot when it comes to encrypted traffic. To detect malicious software or illegal user activities, network security gateways with HTTPS inspection have provided companies with a way to monitor inbound and outbound internet traffic that Secure Sockets Layer (SSL) and Transport Layer Security (TLS) encryption protects. But interception of TLS connections by firewalls, antivirus products and other security tools can introduce vulnerabilities that companies generally remain unaware of, according to researchers.
"To put it bluntly, this is not good," said Johna Till Johnson, CEO and founder of Nemertes Research, in an April 2017 blog that looked at the issue. "There's really no point in deploying security products and protocols if you intentionally break them."
Hypertext Transfer Protocol Secure, or HTTPS, relies on trusted third-party certificate authorities to validate secure internet communications between web servers and browsers, using SSL and TLS encryption. The problem with middlebox software and other endpoint security applications is self-certification -- part of the trust model and generally set up by network administrators -- which can weaken TLS connections and open up transactions to legitimate man-in-the-middle attacks.
Too many versions
While TLS 1.2 supports modern cryptographic algorithms like authenticated encryption and associated data, web servers and clients frequently fall back to earlier versions of the SSL and TLS protocols to enable interoperability. If TLS 1.2 is not supported by both client and server, the handshake drops to the protocol with the next highest security level. Currently, there are five versions of the SSL and TLS protocols: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. The IETF Working Group is in the draft stages of TLS 1.3.
Improper SSL or TLS implementations have caused untold headaches for web service providers and information security professionals. An unknown vulnerability in some versions of the OpenSSL cryptographic library, known as Heartbleed, allowed attackers to exploit memory leaks to identify secret keys and intercept data communications that would normally have been protected by SSL and TLS encryption. The flaw was discovered by Google in March 2014, and a patch was released to the public in April.
Later that year, attackers targeted HTTP and the fallback to SSL 2.0 and SSL 3.0 to expose plaintext data with man-in-the-middle exploits, known as Padding Oracle on Downgraded Legacy Encryption or POODLE. A similar attack was used against TLS 1.0. Google, whose researchers identified POODLE in October 2014, disabled support for SSL 3.0 in some versions of the Chrome browser.
To maintain compliance, companies that engage in e-commerce will soon have to migrate from SSL and early TLS encryption. PCI DSS will require all websites that accept credit cards to discontinue support of TLS 1.0 by June 2018.
'In the wild'
While client-server certificate mismatches and awkward handshakes across the internet have been well-documented, security products that intercept SSL and TLS connections by using proxies may give rise to vulnerabilities that security experts label severe.
Earlier this year, a group of researchers from Google, Mozilla, Cloudflare, the University of California at Berkeley, the University of Michigan, the University of Illinois at Urbana-Champaign and the International Computer Science Institute published a detailed study, "The Security Impact of HTTPS Interception." The research looked at the heuristics of HTTPS interception "in the wild" on three networks: Mozilla Firefox update servers, a group of e-commerce sites and the Cloudflare content distribution network. Researchers found notable security gaps:
In the course of analyzing corporate middleboxes and client-side security software, we uncovered a range of TLS implementation errors, many of which allow connections to be intercepted by a man-in-the-middle attacker.
The authors of the study provided the vulnerability information to manufacturers in August 2016. Some vendors said they had discovered the weaknesses via testing and addressed them before the disclosures; others issued updates, and some were not convinced. Several vendors noted that "secure product configuration was a customer responsibility, and they would not be updating default configurations."
Hidden threats
As researchers raise alarms about the risks of weakened TLS connections, many enterprises fail to inspect encrypted SSL traffic. The Ponemon Institute surveyed 1,023 IT and security professionals in 2016 -- the independent study was sponsored by A10 Networks -- and found that 62% of organizations did not inspect decrypted web traffic. Roughly 80% of the companies surveyed had been victims of cyberattacks or malicious insiders in the past 12 months, and 41% of those attacks used encryption to evade detection. Half of respondents indicated their organizations planned to install some form of traffic decryption in the next 12 months.
How can organizations safely monitor SSL and TLS connections? The U.S. Computer Emergency Readiness Team points to the GitHub badssl.com project, which developers can use to test SSL configurations. The researchers behind the HTTPS interception study outline other approaches and hope that the call to action will get the security community involved in more discussions of HTTPS interception alternatives.
Nemertes' Johnson recommends that information security professionals encourage their teams to use validation testing and not rely on default configurations. Network security teams should test and measure for TLS interception usage. "Pressure your security vendors not to implement TLS interception," she advised.
