Protocols are evolving to meet the demands of the future. We must continue to strengthen the security of these protocols to keep pace with the threat landscape. As such, Transport Layer Security (TLS) 1.3 has been designed to be more secure in order to prevent the interception of sessions over the Internet. TLS 1.3 has been designed over the course of 4 years with a more secure key exchange based on the Elliptic Curve Diffie-Hellman algorithm, formally deprecating the use of RSA static keys to ensure forward secrecy (FS). The end user and privacy were top-of-mind with this and other TLS working group consensus decisions when the zero round trip time (0-RTT) option is not in use. Now, fast forward to when TLS 1.3 is nearing publication and use cases surfaced about a year ago from those leveraging TLS 1.2 to monitor connections within their data centers.
It’s not uncommon for implementers to learn about changes in protocols close to their publication date. Ideally, implementers would be aware earlier in the process and contributing to the standards process, reading the email list to keep abreast of upcoming changes. In this case, enterprise data center operators are voicing concerns over the changes and proposed a solution to enable monitoring within a data center. The working group agreed to continue discussing the issue, but how to solve the problem is uncertain at the moment. While the current revision of the proposal uses the protocol as written (no on-the-wire changes), the client is not aware of the use of interception and decryption and could be subject to monitoring. This is fine within a data center, but if it were used for Internet-based connections, it is not acceptable. The proposal states a restriction of use to the data center, but there is no technical guarantee of that restriction. This leaves the current proposal dead in the water. In the interest of finding a solution for monitoring within the data center while preserving FS in TLS 1.3, let’s explore this a bit further.
Here’s a very simple diagram to help explain the use case for monitoring within the data center:
In the use case described, client-initiated sessions (your web browser connecting to a banking or retail site) terminates a TLS session at the edge of a data center, typically at a load balancer. This usage of TLS 1.3 preserves FS as there is no planned monitoring in the use case of this portion of the session. New encrypted sessions are used for the connections between systems inside of the data center. Some enterprises use TLS 1.2 with RSA static keys to intercept and monitor traffic today. The use of static RSA keys goes away in TLS 1.3, resulting in the need for a new solution for the data center use case. It should be noted that use of RSA static keys in TLS 1.2 was no longer recommended at the time of publication for the TLS 1.2 Best Practices document.
Regulations are one of the drivers as transaction monitoring is sometimes required. Current regulations require encryption on the Internet, but not necessarily within a data center. Encrypting or using tokenization on sensitive data elements, such as Payment Card Industry (PCI) data or personally identifiable information (PII), at the object level meet many of the regulatory requirements for protecting data within the data center. The addition of session encryption is a best practice and may help with limiting the spread of advanced persistent threat attacks once inside a network, but isn’t required. It’s very positive that enterprises want to deploy session encryption and it would be good to assist finding a way forward to enable monitoring and the use of secure session encryption within a data center. It is likely time is on our side to develop a solution that is fit for purpose as the PCI regulation will not require the use of TLS 1.2 until June of 2018. That means, we have time –years – to devise an appropriate solution for use within the data center if TLS 1.3 (as-is) won’t work or data center operators want a standardized solution. It should be noted that nothing prevents the deployment option used in the static Diffie-Hellman proposal, standardization is not necessary since the proposal does not alter the standard.
After reading through lengthy email threads on the TLS mailing list, following the discussions, reading the TLS 1.3 and proposal drafts, and listening to the presentations, working collaboratively with enterprises toward meeting their use case while preserving security properties for TLS 1.3 is possible. I’m aware of a TLS extension proposal that requires client opt-in that will be submitted soon and encourage others to think more on ways forward. Here’s an option I’ve been pondering outside of TLS.
TLS 1.3 improves user security as well as security for organizations and should be adopted and deployed for Internet-facing connections. Solutions for use within a data center can remain on TLS 1.2 for the time being. We have time before regulatory bodies will require TLS 1.2 to be phased out. Additionally, the regulations I’ve looked at list TLS as an option among several, including IPsec and SSH, for encrypting Internet sessions. With that in mind, it is possible for TLS 1.3 to terminate at the data center edge with a different encryption protocol being used within the data center.
IPsec transport mode offers some hope here as a viable alternative. I’m suggesting IPsec transport mode for a few reasons:
- With IPsec Transport mode, the IP header is not encrypted, leaving visibility to the source and destination IP addresses. This offers some troubleshooting capability without the need to decrypt traffic.
- Group key management for secure group communication has already been defined and deployed with “The Group Domain of Interpretation (GDOI)” by multiple vendors. For applications requiring lower latency, such as real-time application, we also have “Multimedia Internet KEYing (MIKEY)”.
- IPsec transport mode isn’t widely deployed. While this means there is work to do to improve interoperability, there may be more acceptance with developing the protocol to meet the needs of data center operators.
- IPsec terminates at the system level, not the application layer like TLS. This offers a point of visibility for traffic streams not available for TLS without group keys or interception techniques (shared keys – not advised, but possible). A little known feature in many IPsec implementations is the ability to dump clear text traffic at an endpoint. Since this is within a single administrative zone, the use of this feature for troubleshooting is not uncommon.
- Issues with Network Address Translation (NAT) have been documented and fixed in some implementations.
Separate from the data center use cases presented to the TLS working group, there is a new draft in the Interface to Network Security (I2NSF) working group to automate IPsec connections within service provider networks. A YANG model has been proposed to assist with customers of cloud offerings to automate deployment of IPsec encrypted sessions (tunnel and transport mode) within their hosted environments. The draft has not yet been adopted as a working group item, but there is work starting between the I2NSF and IPsec Maintenance (IPsecMe) working groups to improve the proposal. A call is scheduled for 6 September. Not all data centers have the same needs, so this may not be a fit for all, but would be good to consider for the reasons stated above.
A third option is a multi-party encryption/decryption protocol designed for data center use; however I am not aware of such a proposal to date.
What does this mean? It means there is motivation and expertise to work to meet the necessary use cases, while maintaining TLS 1.3 deployment models that better protect end users’ traffic on the Internet. In other words, keep TLS 1.3 safe for people using the Internet as well as the organizations they access over the Internet. Will this be costly? Possibly, as upgrading and changes within a data center are not trivial, but the costs associated are likely to be much smaller than the potential costs if TLS 1.3 is not maintained as a secure protocol for Internet use.
Ideally, we’d get to a point where end point servers as adequate capabilities to provide transaction monitoring and logging to enable end-to-end encryption within a data center too, assistance from application and other developers is needed to close the gap.
Comments are welcome as is your input and ideas to help advance work to meet the use case described. This may be done directly through the discussions in the TLS list, work on the current proposal, assisting with improvements needed to IPsec implementations to have that be a feasible solution, or the design of a secure multi-party session encryption solution to enable data center decryption and monitoring.
