This post is the first in a three-part series on TLSv1.3 adoption. The post addresses the concerns with transitioning to TLSv1.3.
At the recent RSA Conference, I had the honour of moderating an impressive panel on the hot topic of Transport Layer Security version 1.3 (TLSv1.3) adoption.
Network Monitoring is Going Away…What Now? TLS, QUIC and Beyond was the result of the panellists’ and my interest in further opening up the path for adoption debate outside of the IETF. The goal was to discuss the concerns and solutions related to network management and monitoring as we move to an Internet with the increased use of stronger encryption.
Soon after the RSA Conference 2018, I also presented this topic at Dell Technologies World (DTW) 2018, “Technology Advancements: The Balance Between Encryption and Management”. I gleaned additional insights from attendees who operate and manage large networks, both private and service provider networks.
The feedback from these two audiences is included in this, the first of a short blog series on TLSv1.3 adoption. Subsequent blogs will dive deeper into the topics for consideration as you think about the next steps for your network and plan for the changes toward increased deployment of encryption, as well as improved protection against interception.
Push for stronger session encryption
The panel debate was quite interesting as it discussed both security and manageability concerns. These concerns centred around the current practice of passive session interception for some network and security management tools with the push for stronger session encryption.
There’s the obvious goal of session encryption to prevent pervasive monitoring and, therefore, provide privacy and human rights protections for end users. This goal is why we’ve seen a steady increase in recent years in deployed encryption for web traffic.
Figure 1 — Percentage of page loads over HTTPS by region. Source: Let’s Encrypt
While the Snowden revelations led to an immediate increase in deployed session encryption in this graph (Figure 1), trends in standards development also shifted at this time. The shift in standards resulted in the recent and sharper increase in deployed encryption — the fundamental shift driven by the acceptance of less-than-perfect security in favour of deployability.
We see examples of this both with Opportunistic Security (OS) and the standards used by Let’s Encrypt, further developed in the Automated Certificate Management Environment (ACME) IETF working group. Opportunistic Security enables an upgrade path from cleartext sessions to sessions encrypted without authentication (which is breakable, but allows for easy automated configuration without knowledge of the other endpoint), to authenticated session encryption.
Before this shift, such efforts would not have gone anywhere since the unauthenticated session could be intercepted, leaving you with no security. From a purist point of view, that was not acceptable in the past, but now there’s a justification. OS raises the cost for pervasive monitoring, resulting in an infeasibility to monitor all sessions passively. If economies or malicious actors want to monitor traffic in this model, they would need to target specific sessions for decryption and observation.
While we haven’t seen much deployment outside of OS’s use with IPsec, ACME is enjoying huge success via the Let’s Encrypt project. Standards efforts similar to ACME to automate certificate management have previously been tried, but were stopped from a purist point of view on security. What has been reported is that sessions not previously using encryption have taken up use of ACME via Let’s Encrypt to automate the management of certificates, carving out a new ‘service’ aimed at improving privacy protections for end users.
Let’s Encrypt offers certificates for free, but the ACME protocol can be used by other certificate providers who are interested in automating maintenance of certificates for other Certificate Authorities and for any type of certificate. An out-of-band process may be required up front for identity proofing of individuals and organizations for Extended Validation (EV) certificates or other certificate types. If you are not already using ACME, you should consider it as a way to ease certificate management and say goodbye to the days where an expiring certificate causes extensive server outages without anyone realizing the root cause.
We’ve all heard the stories and some have experienced them. Now, with automation it can be avoided.
Human rights not top of mind
Going back to the panel and audience questions, it was apparent that human rights considerations were not top of mind for decision makers in attendance. Very few said human rights factored into their decision-making process and those that did had regulatory requirements.
While not surprising, since work to improve human rights considerations in technology is fairly recent, the IETF protocol designers have studied these considerations for some time. This can be seen with some of the changes transitioned from from TLSv1.2 to TLSv1.3. For the IETF, the primary focus is on protocols that run over the Internet; usage (such as protocols restricted to a data centre) was considered secondary. Enterprise and data centre use cases were not a priority during the initial development of TLSv1.3 as there weren’t many individuals following the development contributing to this point of view and use case.
The IETF is driven by individual contributions. Protocol developers need to consider the protection of end-user traffic on a global scale for TLS, including concerns such as monitoring by nation states or others with malicious intent. While the enterprise and data centre use cases were not top-of-mind, enterprises will benefit by being able to offer customers greater security protections for their sessions that traverse the Internet.
This Internet-focused view is where human rights and privacy considerations factor into the design work. Simple health-related searches, or access to political content, could have grave consequences depending on regional laws or customs. Session protection and anonymity are key properties for consideration in protocol development specific to human rights used to protect individuals and is already considered in security and privacy measures.
TLSv1.3 improvements
It was surprising to learn that not many in either audience had near-term plans to deploy TLSv1.3 on Internet-facing connections (your customer’s browser to the termination point at the edge of your network). This is likely a result of the learning curve prior to adoption.
TLSv1.3 introduces security enhancements, is provably secure, and should be strongly considered to improve the security of sessions for your customers. Browser vendors and libraries supporting TLSv1.3 are ready with interoperable solutions as long as there are no findings that interrupt the final steps of the publication process.
Content delivery networks (CDN) will likely be among the early adopters as it will provide quick wins for their customers’ security and many CDNs are interested in protecting sessions from interception, including multiple types of middleboxes. As an industry, we’ll gain experience from the deployment of this new version and others will begin to decide when and where to deploy TLSv1.3.
As previously mentioned, the changes from TLSv1.2 to TLSv1.3 improve session security for end users, offering additional privacy protections from the interception of traffic via passive monitoring techniques. Active interception capabilities remain and the tools in browsers to detect active proxies will continue to operate as they do today — notifying users and giving them the choice of whether to trust the intercepting proxy. If you terminate sessions at the edge of your network for proxy-type inspection, that will continue to work.
What’s at the heart of the debate for the changes in TLSv1.3 for management and monitoring?
There are a few important changes to provide forward secrecy recommended in the best practices for TLSv1.2 that are now inherently part of the TLSv1.3 protocol. We say that a system, or a protocol, has forward secrecy if the encrypted traffic that is recorded today cannot be decrypted tomorrow if some long-term secret (like a certificate’s private key) is compromised tomorrow. It is accomplished via frequent independent key exchanges, such that the compromise of one key limits the data exposure to the information protected by that compromised key.
TLSv1.3 maintains forward secrecy, as does TLSv1.2 when configured according to best practices, except when pre-shared keys are in use. The protocol update from TLSv1.2 to TLSv1.3 removed static RSA and static Diffie-Hellman cypher suites, thus removing the possibility of using these session monitoring techniques and making the protocol forward secret.
TLSv1.3 supported symmetric algorithms are Authenticated Encryption with Additional Data (AEAD), also a recommended best practice for TLSv1.2. Additionally, TLSv1.3 uses a more secure key exchange based on the elliptic curve Diffie-Hellman algorithm. These changes should not have much of an impact on your Internet-based deployment if your sessions are configured with TLSv1.2 according to best practices.
If you have any network-based monitoring in place (for example, firewalls or intrusion prevention), and it occurs at a proxy at the edge of your network after a point of termination for the session, this will continue to function as expected with TLSv1.3. The only change here is if passive or out-of-band monitoring techniques are in use that relies upon the use of static keys, where the session encryption is not a forward secret.
Emerging protocols
The panel discussion, as well as the session at DTW, discussed other emerging protocols including QUIC and TCPcrypt. While not yet approved standards, they are currently used on the Internet and are important to understand with regard to the trends for session encryption.
Those in the audience aware of QUIC were outright blocking its usage on their networks. This tells me that in corporate environments, there is no business imperative critical enough to permit the use of this new protocol to date. That may change in time. As for TCPcrypt, most were unaware of this protocol.
The next post in this series will dig deeper into the types of monitoring performed on internal and external networks to better understand considerations for your deployment plans. Then we’ll move into a deeper dive on options for network encryption and monitoring including alternate session encryption protocols.
Adapted from the original post which appeared on the RSA Blog.
Kathleen Moriarty 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.
Thank you for interesting and useful article!