It's 2018, and network middleware still can't handle TLS without breaking encryption

An academic study published last month shows that despite years worth of research into the woeful state of network traffic inspection equipment, vendors are still having issues in shipping appliances that don't irrevocably break TLS encryption for the end user.

Encrypted traffic inspection devices (also known as middleware), either special hardware or sophisticated software, have been used in enterprise networks for more than two decades.

System administrators deploy such appliances to create a man-in-the-middle TLS proxy that can look inside HTTPS encrypted traffic, to scan for malware or phishing links or to comply with law enforcement or national security requirements.

Also: Why 31% of data breaches lead to employees getting fired TechRepublic

All such devices work in the same way, creating a TLS server on the internal network and a TLS client on the external network. The TLS server receives traffic from the user, it decrypts the connection, allows the appliance to inspect the traffic, and then re-encrypts and relays the connection to the intended server by mimicking the browser via its own TLS client.

For many years, this has not been an issue, mainly because in the beginning, HTTPS connections were simple to set up. But as the technologies supporting TLS traffic have become more and more complex, it also became harder for vendors to support all types of connections without accidentally or intentionally downgrading HTTPS encryption.

In the last decade, security researchers have looked closely at the issue of TLS inspection appliances that break or downgrade encryption. There has been much research on the topic, from research teams from all over the world [1, 2, 3, 4, 5].

But despite years worth of warnings and research, some vendors still fail at keeping the proper security level of a TLS connection when relaying traffic through their equipment/software.

Academic research published at the end of September by three researchers from Concordia University in Montreal, Canada, shows that network traffic inspection appliances still break TLS security, even today.

The research team looked at 17 versions of 13 TLS network appliances between July 2017 and March 2018, including open source, free, low-end, and high-end TLS middleware appliances.

To do so, the research trio created an extensive framework that could analyze the TLS-related behaviors of appliance-based proxies and their potential vulnerabilities.

Researchers looked at TLS version and certificate parameter mapping, cipher suites, the private key generation and its protection, the content of the root CA store, known TLS attacks, and 32 certificate validation tests.

Also: KRACK attack: Here's how companies are responding CNET

The study was more than fruitful, finding several issues with almost all devices. The findings were as follow:

• WebTitan, UserGate, and Comodo do not perform any certificate validation. These appliances allowed all faulty TLS certificates, researchers said.
• Comodo and Endian do not perform certificate validation in default setups because a checkbox for accepting all certificates is checked by default in its configuration. Researchers said that even after unchecking the box, Comodo still failed to perform certification validation, accepting all upstream certificates.
• Cacheguard accepted self-signed certificates, enabling dead-simple MITM attacks.
• Trend Micro, McAfee, and Cacheguard use pre-generated key
• pairs, enabling a similar dead-simple MITM attack.
• McAfee states in its documentation that it generates a private key pair during installation, but researchers found the appliance to use a pre-generated key pair instead.
• Four appliances --UserGate, WebTitan, Microsoft, and Comodo-- accept their own certificates for externally delivered content. If an attacker can gain access to the private keys of these appliances, he/she can launch a MITM attack to impersonate any web server. Researchers said the private keys are stored on the devices and are easily accessible if another vulnerability allows an attacker to read data from the TLS middleware. Non-root users on UserGate, WebTitan, and Comodo can read the private key, while admin rights are needed to retrieve the key on Microsoft devices.
• All appliances except Untangle and McAfee accept certificates signed using the MD5 algorithm.
• WebTitan, Microsoft, UserGate, Cisco, and Comodo still accept MD4.
• Attackers could break session confidentiality for clients behind Sophos, Cacheguard, OpenSense, Comodo and Endian, as they accept RSA-512 external leaf certificates (RSA-512 is easily factored).
• Clients behind Untangle are similarly vulnerable to MITM attacks because the appliance uses the RSA-512 "Root Agency" certificate in its trusted certificate store. The Root Agency CA certificate is valid until 2039, and has been used since the 1990s as the default test certificate for code signing and development. Windows systems still include this certificate, but they mark it as untrusted, although this wouldn't stop an attack on the TLS middleware. The RSA-512 private key corresponding to this certificate can be easily factored under four hours.
• Attackers can use the BEAST attack to recover authentication cookies from users behind Microsoft, Cisco, and TrendMicro TLS middleware.
• Attackers could also recover cookies from clients behind WebTitan, Microsoft, TrendMicro, Comodo, and Endian due to their use of RC4.

The research team says all appliance flaws were reported to their respective vendors after two series of tests in 2017 and 2018. Despite the reports, researchers said vendor responses were not what they expected.

"Overall, the disclosures appear to have limited impact on vendors," said the research team. "Many vendors completely ignored the security issues (Untangle, Microsoft, UserGate, and pfSense). More worryingly, some products even became worse over time (Cisco), and some patched product releases introduced new vulnerabilities compared to their older versions (WebTitan)."

Also: Worries arise about security of new WebAuthn protocol

Unfruitful, to say the least.

Researchers argue that since TLS middleware works as a proxy for client-to-web server connections, "they should maintain (at least) the same level of security as modern browsers." Similarly, as they act as a TLS server for web-to-client internal network connections, they should also be "securely configured like any up-to-date HTTPS server."

By abiding to these simple principles, researchers say middleware appliances should be simple to manage.

The testing framework used by the Concordia University crew is available for download from here. More details are available in a research paper entitled "The Sorry State of TLS Security in Enterprise Interception Appliances."

Devices certified by Google's Android Enterprise Recommended

RELATED STORIES:

• US government rolls out 2-step verification for .gov domain owners
• Web hosting providers take three days, on average, to respond to abuse reports
• After two decades of PHP, sites still expose sensitive details via debug mode
• Why free VPNs are not a risk worth taking
• Over a million vulnerable fiber routers can be easily hacked