Last updated at Thu, 01 Feb 2024 20:46:53 GMT

In the security industry, as in much of life, a problem we often face is that of balance. We are challenged with finding the balance between an organization's operational needs and the level of security that can be implemented. In many situations an acceptable, if less than optimal, solution can be found but there are cases where this balance cannot be achieved. I recently saw a case of this on the mailing list of the IETF TLS Working Group where Andrew Kennedy, a representative of a finance industry group, asked for changes to be made to the draft proposal of the next version of TLS. In the eyes of many in the security community honoring the request would undermine one of the goals of the new standard and enable the continuation of real time and after the fact decryption of TLS traffic. From the perspective of the Mr. Kennedy the TLS draft changes break existing security controls for the industry as well as prevents organizations from meeting governmental regulations and requirements. In other words, they actually increase risk for the industry that he represents.

Background on how RSA certificates are used

Before I continue I'll need to provide a little background information in order to provide context for Mr. Kennedy's request. At a very high level RSA certificates are a pair of mathematically linked encryption keys. One of the keys, "private," must be protected and known only to the server.  The other key, "public," is expected to be shared with any party trying to communicate with the server.  Within the SSL/TLS protocols RSA certificates can be used for two purposes that are relevant to this discussion: proof of identity and key exchange.

Proof of identity

The use of RSA certificates that most people are familiar with is proof of identity. While making a TLS connection to a service, the server must present a valid certificate matching the hostname the client sent the request to. The certificate must be signed by, or be in a chain of signed certificates that are signed by, a certificate that the client trusts. This proves that the server is actually the one that the client intended to communicate with and not some malicious actor.

Key exchange

A lesser known use for the RSA certificate is encrypting secret data used during the key exchange portion of TLS session negotiation. Asymmetric encryption, such that which is performed with RSA keys, isn't actually what is used for encrypting the application traffic in a TLS session. This is due to multiple factors but the most significant is speed. Encrypting all data using the asymmetric encryption would be so slow as to be unusable. Application traffic is encrypted with a symmetric cipher such as AES. For this to work both sides of the conversation need to know a session specific secret key. When RSA key exchange is used the information used to create the session key is generated by the client. The data is then encrypted using the server's RSA public key and transmitted to the sever.

One downside of using RSA certificates to perform key exchange is that if the server's RSA private key is compromised then all TLS communications to that server can be decrypted. The private key of the server's RSA certificate can be used to decrypt the TLS session setup phase and extract the session key. At this point all traffic for that particular session can be decrypted. What makes this particularly dangerous is that this technique works for any sessions that have been captured in the past. If traffic to a server was captured by a malicious party for three years and at the end of this time the party compromised the RSA certificate used for key exchange during that time then ALL of that traffic could be decrypted and the contents compromised.

To address this risk endpoints can be configured to use other methods of key exchange that don't use long lived keys like RSA certificates. This provides Forward Secrecy where compromise of long-term keys does not compromise past session keys. The TLS Working Group and contributors considered Forward Secrecy important enough that they removed support for RSA static key exchange from the TLS 1.3 draft specification in mid-2014. This change does fantastic things for the security of an endpoint's communications but it severely breaks the ability of authorized parties to monitor traffic.

The request

This brings us back to Mr. Kennedy's request. On September 22, 2016 Mr. Kennedy, who is with the Financial Services Roundtable BITS Cybersecurity team, sent an email to the TLS Working Group email list requesting that RSA key exchange remain in the TLS 1.3 specification. His reasons for requesting this essentially boil down to:

  • His industry is generally required by regulation and contract to implement security technologies aligning with best practices such as IPS, DLP, malware detection, etc.

  • His industry is often required to provide an audit trail of all actions taken by certain employees and systems

  • Network and application troubleshooting often require inspection of traffic contents

  • Removing RSA key exchange from TLS 1.3 breaks capability to decrypt TLS traffic in real time or retroactively

  • At some point regulations, contractual obligations, or technology requirements will force the implementation of TLS 1.3

  • Using Man in the Middle (MitM) techniques add overhead, latency, and complexity

  • Capturing the required data on the endpoint is subject to failure, adds complexity, and requires control of all endpoints

He has a point

Having spent some time as an InfoSec professional in the Finance industry I can see the value in his arguments and, whether you agree with him or not, those are legitimate business needs and drivers. From a practical risk perspective for the average financial institution the current TLS specification is “good enough” for general usage because of the extremely low likelihood of attacks against the TLS session itself. On the other hand the ability to detect attacks against infrastructure in real time is critical. Additionally, real risk can come in the form of financial penalties and sanctions due to non-compliance with regulation and rules. Non-State actors are unlikely to decrypt an organizations internal communications, but failure to meet U.S. Security and Exchange Commission (SEC) requirements can have real and measurable impacts in the form lost revenue due to the inability to trade. Further, changes such as the one discussed here can reduce or remove the incentive to adopt new technologies and the benefits they represent when the opportunity arises. This is particularly true in industries where change itself causes risk.

But there are problems

All of this being said, I think the train has left the station on this one. One of the goals of the current TLS 1.3 draft specification was to remove weak/broken key exchange and lock in forward secrecy. To a large degree this stance is in response to increased awareness of State level surveillance and the potential impacts of compromised server keys. The efforts to harden TLS are also being driven by the large number of TLS and general cryptography related security issues that have been discovered over the last decade. The IETF mailing lists responses to Mr. Kennedy generally trend towards ‘no', ‘where were you a dozen drafts ago?', ‘you are doing security wrong', and ‘that particular technique for surveillance/monitoring will be dead soon, deservedly so'. Obviously there is a lot of nuance in both positions that can't be captured in a short blog post.

Unbalanced exchange

One point that I don't feel like was made strongly enough was that what Mr. Kennedy has asked for has limited, local benefits. Using the RSA certificate to decrypt the traffic only works when you have the certificate from the server side of the conversation. The tools will be unable to decrypt and inspect traffic to 3rd parties, malicious hosts and services within the network, and traffic to endpoints where forward secrecy is a requirement implemented via technical configuration. This does provide value when monitoring for attacks against your web servers but is going to have limited value when deploying Data Loss Prevention (DLP) to detect information exfiltration. It also won't detect when an organization's stock brokers are handling trades via Facebook or malware is calling out to command and control servers. While not ideal, these problems are more completely solved in the form of constrained networks and hosts, end point solutions, and logging. In short, the requested change to the TLS draft adds risk to others but doesn't truly solve the industry's problems.

Looking into the future

I think there are a couple of take-aways from this situation:

  • Implementing TLS 1.3 as it currently stands WILL break, BY DESIGN, certain methods of traffic surveillance/monitoring.

  • Organizations with requirements to monitor traffic will need to either MitM or implement endpoint monitoring (traffic logging, inspection, session key retention).

  • Organizations will have to rely on MitM network egress filtering to deal with traffic between endpoints they don't control. This is not a change to how things are done today.

  • Organizations will have many years to deal with this for assets they control. You will still find SSLv2 within enterprises and SSLv3 is still a thing on the Internet.

  • Regulations and the speed of technology adaption to the new protocol will slow the progress of implementation. That being said, I expect TLS 1.3 to be deployed much faster than its predecessors.

At the end of the day

I think Mr. Kennedy's request to the IETF TLS Working Group was well formulated, appropriately targeted, and based on legitimate business drivers. Despite this I don't think that he will find the balance between security and business needs that he is looking for. One could argue that the request was too late in the process but I honestly think the outcome would not be different had it been sent during the first draft of the TLS 1.3 specifications. On the other hand, increased awareness and involvement at that time would have allowed more time to review options and work with regulators and vendors to meet the industry's needs.