This post is the third and final in a three-part series on TLSv1.3 adoption. It addresses options for network encryption and monitoring including alternate session encryption protocols.
With TLSv1.3 approved and in the IETF publication queue, it’s time to think about deployment options and obstacles, and planning for changes inherent in this revision.
Regardless of when you plan to upgrade it may require significant planning for internal applications and network architectures, less so for Internet-based sessions. Supporting libraries and browsers are ready for this upcoming release.
As the former IETF Area Director responsible for TLSv1.3, I assisted with managing the tough conversations around monitoring and managing networks with TLSv1.3 and making sure they could occur. Options exist to maintain visibility, but identifying and implementing the most appropriate choice for your network requires careful planning.
In an ideal world, organizations would be able to upgrade usage of TLSv1.2 to TLSv1.3 in their internal networks seamlessly
This will happen for some enterprises, where they have already shifted to a network without a perimeter or no single discernible firewalled gateway point of access. These networks already rely upon secure TLS sessions — which are more difficult to intercept — following the deployment best practices for TLSv1.2 in RFC 7525.
In other cases, where possible, the enterprise moved away from relying on out-of-band or passive TLS interception middleboxes, instead relying on the information available at the endpoint and active interception for monitoring via a proxy-based solution. If your organization still relies upon TLSv1.0 or TLSv1.1, you should minimally move to TLSv1.2, configured according to best practices, as that deprecates older crypto algorithms and cypher suites and provides forward secrecy.
Others have network architectures that would incur great costs to overhaul and move away from the ability to intercept encrypted traffic, yet still have the desire to apply the best practice of session encryption on their internal networks.
As such, work has been proposed — unsuccessfully to date — in the IETF to allow for visibility in TLSv1.3. These enterprises may need a technology bridge allowing them to continue monitoring the way they are today while considering a shift to session protocols, for which session interception is more difficult. Neither of the proposals to date have gone forward toward adoption.
The proposals included Data Center Use of Static Diffie-Hellman in TLS 1.3 and TLS 1.3 Option for Negotiation of Visibility in the Datacenter. The two technical arguments, or hurdles, preventing them from moving forward include, the working group’s desire to ensure the technique or extension could be bound to the data centre or enterprise and a requirement for client opt-in. The concern is if there is a way to intercept traffic, it may be done by unknown or malicious parties, in addition to those who already have access to the data at the server or point of termination for the TLS session.
Planning to continue to use TLSv1.2?
Those planning to continue to use passive interception using TLSv1.2 with RSA static keys for management and monitoring functions today have a few choices:
Stay with TLSv1.2; deprecation is likely a long way off!
- Current regulations do not require session encryption on internal networks, so it’s unlikely to see this specific version be called out as not approved for use on an internal network. Your organization’s security policy and architecture may guide the selection of the appropriate session encryption protocol.
- Protection of the data through object-level encryption or tokenization are required and will offer the protection mandated by current regulations.
- It is best practice to use session encryption on internal networks and there is no currently known vulnerability in TLSv1.2 that would force its deprecation.
TLSv1.1 was standardized 12 years ago and will be deprecated by browser vendors and content delivery networks in June 2018 along with TLSv1.0.
SSLv3 enjoyed 20 years of deployment before POODLE forced it to be deprecated by the industry and the IETF. Unless there is a major vulnerability and support remains in browsers and libraries, there should be no rush to remove TLSv1.2 from use in your internal network.
- NIST’s 800-52 draft revision “requires that TLS 1.2 configured with FIPS-based cypher suites be supported by all government TLS servers and clients and recommends that agencies develop migration plans to support TLS 1.3 by January 1, 2020”. This recommendation is in line with the best practices for deploying TLSv1.2. NIST also deprecates TLSv1.0 and recommends against the use of TLSv1.1 in the draft guide.
- Note: Be sure to phase out any use of TLSv1.0 and TLSv1.1. Support for these protocols that have not been deprecated by the IETF may dwindle in the June/July timeframe, as CDNs and other organizations will deprecate their support of these protocols. Browser support plans are not clear, but web traffic statistics from the Alexa Top 1 million show that TLSv1.0 compromises 0.8% of traffic and TLSv1.1 is even lower.
Transform your network and security architecture to perform monitoring at the endpoints to prepare for a transition to TLSv1.3
- Evaluate logs and debug level logs of your applications and systems. Work with vendors to fill the gaps in visibility.
- Eliminate the use of middleboxes that observe and decrypt traffic passively. See if these functions are needed or could be performed at some other point in the network, preferably the edge. Monitoring via a proxy (active) is still possible with TLSv1.3 and will appear similar to end users as in your TLSv1.2 deployments. Proxy-based monitoring is where you terminate a TLS session, perform monitoring, then initiate a new session.
Look for artificial intelligence and machine learning solutions to process logs and alerts from the endpoint
- There is room for innovation here to better scale security and system management. Future and emerging protocol options to better suit your internal network management and monitoring requirements could be considered for longer-term solutions.
The first two of the following three possibilities assume TLS is terminated at the Internet-facing edge of your network and alternate encryption protocols can be deployed internally in a server-to-server configuration — the third would run in parallel to TLS.
- Opportunistic security is applied to TCP sessions, leaving the header exposed. Opportunistic security means the session is not authenticated, which eases deployment as it can easily be automated but also leaves it open to interception.
- Libraries are available; however, the standard is not yet approved for publication, therefore modifications are possible.
IPsec
- IPsec transport mode leaves the source and destination address information exposed for network management.
- Group keying options are already standardized: GDOI and MIKEY.
- It’s little known, but many implementations allow for a debug session to provide a full, clear text of a session to be collected at the endpoint for troubleshooting.
- Interoperability work is needed between implementations to make IPsec transport mode a real contender, but it’s possible for this work to occur if there is demand. The IPsec Maintenance (IPsecMe) working group is fairly active. This would require a push from customers to their vendors to see support. Alternatively, IPsec tunnel mode could be used from endpoints to preserve the source and destination address information in the packet header.
- There’s active work in the IETF’s Interface to Network Service Function (I2NSF) working group to automate IPsec provisioning through a SDN controller within your data centre or even a hosted environment. See “Software-Defined Networking (SDN)-based IPsec Flow Protection”.
Multi-party protocol designed for data centre use
- Candidate solutions are intended to run in parallel to TLS. As I understand it, the PATIENT effort is looking for solutions that enable visibility from all monitoring points where the client can see what points of monitoring exist, while maintaining forward secrecy.
- There are a few candidate solutions, and it’s possible an effort will form in the IETF, where a protocol is designed specifically for this use case.
- If interested, you can follow along and contribute on the PATIENT mailing list to see if the work can be shaped into a secure solution to meet the needs of enterprises and data centres.
TLSv1.3 adoption = technology gap
Recently, at the RSA Conference 2018 and Dell Technologies World 2018, the audiences for the TLSv1.3 sessions were polled regarding planned adoption. There were few deployments of TLSv1.3 planned for internal networks. I see this as a technology gap problem.
Standards efforts and industry have put forth the tools for maintaining secure sessions but still must provide a path for network and security management functions that have operated via middlebox technologies intercepting traffic passively.
We are at a learning curve prior to an adoption phase. However, the tools are ready, implementations have been well tested for interoperability, and the security benefits are clear for some use cases including Internet-based sessions.
Adapted from the original post which appeared on the RSA Blog.
Kathleen is Global Lead Security Architect with the Dell EMC Office of the CTO working on technology strategy and standards, and former IETF Security Area Director.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.