F5 Networks Response to US-CERT Alert (TA17-075A) HTTPS Interception Weakens TLS Security

Summary

When properly configured, the F5 BIG-IP addresses nearly all the concerns, and avoids nearly all the risks, specified in US-CERT Alert (TA17-075A). This is the key point; on BIG-IP most of the functionality, and the level of security, is determined by the customer created configuration. Whether certificates are validated, and the level of validation, is determined by the configuration, as are the specific cipher suites and protocols that are supported, etc. There are a couple of corner cases, as explained below, where the BIG-IP does not fully meet the recommendations; F5 Networks is continuously improving our products and working to address these areas in future releases.

In short, when properly configured, the F5 BIG-IP or SSL Orchestrator can perform SSL Interception without compromising overall security.

Detailed Examination

A great deal of interest has been generated by the recent publication of US-CERT Alert (TA17-075A) HTTPS Interception Weakens TLS Security. This is of interest to F5 customers as we do support SSL Intercept on BIG-IP, as well as commonly being used for SSL/TLS termination. While the US-CERT Alert does not name F5 Networks, a primary reference for the alert is a two year old blog post, The Risks of SSL Inspection, which does.

It is important to acknowledge upfront that the concern, in general, is not unwarranted. Any point where encrypted communications are decrypted, such as for SSL Intercept, is a potential weak link in the chain, a point of increased vulnerability. But it is equally important to acknowledge that such interception may be necessary as part of a comprehensive security solution.

Interception allows for traffic inspection, such as to protect networks from malware or phishing attempts. It is also used for scanning inbound & outbound traffic for evidence of data extraction or an existing intrusion. Without the use of SSL/TLS Interception at an ingress or egress chokepoint, the same level of protection could only be achieved by monitoring every end-point device on the network.

End-point protection is much more resource intensive, and it may not be practical to do so on appliances such as routers, switches, or even networked printers. With the growth of the Internet of Things (IoT) endpoint-based protection is increasingly unfeasible. It is not possible to run detection software on every connected thermostat or lightbulb. Malware is increasingly using encrypted communication to hide from conventional detection systems, and interception is required to level the playing field.

In response to the question of ‘why use or support SSL/TLS interception at all?’ consider an even larger question: If not SSL/TLS interception, how do you provide equivalent protection? Using interception may add some risk, but there are greater risks in not detecting and blocking malware, phishing attempts, intrusions, etc. Security is about minimizing the overall risk, and tradeoffs are required. SSL/TLS interception is a useful tool and when used well it adds minimal risk while providing a great security benefit.

While the US-CERT Alert generalizes, the cited blog post raised specific technical concerns which have subsequently been raised by customers. These points are addressed in Appendix A.

A second reference cited in the alert, a research paper, The Security Impact of HTTPS Interception, touches on several other potential issues. This include the protocols supported by the interception device (allowing a protocol downgrade), the ciphers allowed by the device, etc. On F5 products these are configurable in the associated profiles. The level of security, or vulnerability, is determined by the configuration used by the customer – and not F5 or the BIG-IP inherently.

Customers who had additional concerns, or who desire assistance in configuring their BIG-IP to meet their specific needs, are encouraged to reach out to their F5 Account Team and/or F5 Professional Services.

The key point to take away is that the F5 products can perform SSL Interception without compromising security, but it comes down to the configuration that is used. It is a tool, and like any tool it can be used skillfully or haphazardly. Customer are advised to properly configure the system for their specific needs, and best practices should always be followed. When it comes to security, being conservative in what you accept and enforcing higher levels of validation is always recommended and any exceptions to these practices should be well considered. Used judiciously, SSL Interception can make a net positive contribution to security.

Appendix A: F5 Networks response to The Risks of SSL Inspection technical points.

1) Incomplete validation of upstream certificate validity
Some SSL-inspecting software fails to validate the certificates of systems that it connects to. In some cases, the software may attempt to perform some validation of the certificate, but the validation may be insufficient.

Risks: Clients cannot know if they are connected to a legitimate site or not.

2) Not conveying validation of upstream certificate to the client
In some cases, the SSL inspection software does perform validation of upstream certificates, but it does not relay the results of the validation to the client.

Risks: Clients cannot know if they are connected to a legitimate site or not.

3) Overloading of certificate Canonical Name (CN) field
Some SSL inspecting software attempts to relay the validity of the upstream certificate to the client by way of the CN field of the certificate. For example, Komodia SSL Digestor changes the CN to begin with "verify_fail" if the server-provided certificate is invalid for any reason. There are a number of issues with this technique. The most obvious mistake being that the actual error conveyed to the user usually has nothing to do with why it failed.

Risks: Users of client systems may not know why certificate validation failed, or even if it failed. An attacker may be able to specify a Subject Alternative Name field to specify any domain that the certificate specifies it is valid for, which results in a browser that does not display a certificate warning.

4) Use of the application layer to convey certificate validity
To relay the validity of the certificate to the client, some SSL inspectors provide web content (e.g. HTML) to the client, describing what is wrong with the certificate. The normal mechanisms through which client software ascertains and displays certificate validity may still indicate that the certificate is fine.

Risks: Not everything that accesses data using HTTPS is a human using a web browser. For example, the client may be an application that communicates with a server using JSON data. This flaw also causes inconsistent use of SSL validity indicators (e.g., "Where do I look for the padlock again?").

5) Use of a User-Agent HTTP header to determine when to validate a certificate
Some software will selectively decide when to validate upstream certificates based on the User-Agent HTTP header provided by the client. This technique is likely used in conjunction with the technique described above where certificate validity is conveyed in the application layer.

Risks: Not every web client may receive certificate validation. Various web browser versions and non-browser software may be exempt from validation.

6) Communication before warning
Upon detecting a certificate error, some SSL inspection applications will send the client's request to the server prior to presenting a warning to the user.

Risks: An attacker still may be able to view or modify sensitive data.

7) Same root CA certificate
Some SSL inspection applications use and install the same trusted root CA certificate for each installation of the application.

Risks: An attacker may be able to extract the private key from the software and sign all visited sites with the universally-trusted root CA certificate.