F5 Networks Response to US-CERT Alert (TA17-075A) HTTPS Interception Weakens TLS Security
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. F5 Response: Configuration Dependent Certificate validation is configuration dependent. Customers can configure the CA bundle that is used to authenticate downstream certificates. They can also configure whether to allow connection to servers with expired certificates, or to servers with untrusted certificates. Note that the default is to ignore both expired and untrusted certificates, so customers should change this during configuration if they desire increased validation. To satisfy the US-CERT recommendations, the configuration should not allow connections with expired or untrusted certificates; Ultimately, the customer is in control of the configuration, and therefore the requirements for certificate validation. Note that once the upstream certification is validated, the BIG-IP does cache the certificate it generates for the client. This is to improve performance, as certificate generation and signing is a computationally expensive operation. While this certificate remains in the cache, the upstream certificate is not re-validated. The cache lifetime may be configured, trading off re-validation time for performance. F5 Networks is also working to add OCSP Stapling support in a future release. 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. F5 Response: Configuration Dependent If the BIG-IP is configured to perform certificate validation and the upstream certificate does not pass, the upstream connection will not be completed. In turn the client connection will be disconnected. If the configuration allows upstream connections with untrusted certificates the client is not informed if the certificate has failed validation. There are two different validations performed: expiration and trust: If set to ignore an expired cert, the BIG-IP will re-issue and cache an expired cert to the client. This satisfies the notification recommendation in the US-CERT Alert; the client can make the same evaluation as it would without the BIG-IP in the path. If set to ignore an untrusted cert, the BIG-IP will re-issue and cache a valid cert to the client. This does not satisfy the notification recommendation in the US-CERT Alert. F5 Networks is planning a change to this behavior in a future release to better align with the US-CERT recommendations. To satisfy the US-CERT recommendations, F5 Networks recommends not ignoring expired or untrusted certifications, and allowing connections only with sites issuing current, trusted certificates. 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. F5 Response: Not Applicable F5 does not overload the certificate CN field. 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?"). F5 Response: Not Applicable F5 does not use the application layer to convey meta information. 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. F5 Response: Not Applicable F5 does not use the User-Agent HTTP header to determine when to validate a certificate. This is controlled strictly by the configuration; if validation is required it is performed for all connections. 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. F5 Response: Not Applicable F5 does not do this. If the upstream connection fails validation we do not complete the connection, let alone forward the client’s request. 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. F5 Response: Configuration Dependent On F5 BIG-IP the customer provides the CA certificates and configures the CA bundle to use for validation. This is entirely under the control of the customer.
