TLS Version Transition Planning
By: Kathleen Moriarty
Many organizations have historically relied on TLSv1.2's passive interception, enabling middle boxes like Intrusion Prevention Systems (IPS) to inspect all network traffic. This approach, while providing comprehensive visibility for threat detection, introduces significant security risks by creating centralized decryption points. For legacy systems, this trade-off might have been deemed necessary. However, as organizations transition to a Zero Trust architecture, which emphasizes application-specific security using strong authentication and TLSv1.3, this practice should be phased out. A well-structured multi-year transition plan, aligned with investment schedules and resource considerations, is essential. This plan should include migrating applications to Zero Trust principles, deprecating legacy security tools, and continuously monitoring the diminishing value of these tools. A thorough risk-benefit analysis must guide all roadmap decisions to ensure optimal security and resource allocation.
The Internet Engineering Task Force (IETF) TLS working group reached consensus to move TLSv1.2 to maintenance mode, with the draft to signify this action in the final phases of publication. This means there will be no more features added to the TLSv1.2 protocol to support backwards compatibility with the current version, TLSv1.3. There will only be vulnerability fixes published as updates until the time (could be years) in the future when TLSv1.2 is deprecated. A protocol is typically deprecated when vulnerabilities persist that are too difficult to fix, we are not at this phase and TLSv1.2 is still safe to use when properly configured. When TLSv1.3 was published, this obsoleted TLSv1.2. You can still use an obsoleted protocol, it’s deprecation that determines end-of-life. The recent move to transition TLSv1.2 into maintenance mode provides a signal to seriously consider a transition to the newer and fully supported version. Older versions of TLS including 1.0 and 1.1 have been formally deprecated and were previously obsoleted. SSLv3 has been deprecated and obsoleted due to vulnerabilities.
TLSv1.3 has been adopted on the Internet overwhelmingly due to changes in browsers that alert users when older versions of protocols (e.g. SSL, TLSv1.0, and TLSv1.1) are used. TLSv1.2 remains in widespread use as of the time this blog was published. Users are also alerted in cases where a cryptographic algorithm is selected for use that is not considered strong, or when an issue with the certificate associated with the public/private key pair is detected. These controls have had a major impact improving security on the Internet. For internal networks of organizations, we have not had the same push yet.
Content delivery networks (CDN) support TLSv1.3 at a higher rate than the general Internet, and cover a large percentage of websites hosted on the Internet. The top CDN hosts about 70% of web content, therefore support for TLSv1.3 not he server side is quite high. Statistics are a bit more balanced between actual TLSv1.2 and TLSv1.3 usage on Internet bound sessions. While many websites have TLSv1.3 configured, the usage is determined by a negotiation between the client and the server, currently resulting in a more balances division of TLSv1.3 and TLSv1.2 usage when reviewing statistics.
Why is TLSv1.3 a better fit for zero trust?
The Zero Trust Architecture (ZTA), as defined by NIST Special Publication 800-207 includes 2 applicable tenets to TLS. The property of provable security make a strong case in favor of TLSv1.3.
The first tenet is strong ubiquitous encryption. Strong encryption is intended to be in transit, at rest, and during compute or compute is isolated in an enclave, a.k.a. trusted execution environment. TLSv1.3 applies to encrypted data in transit. This means encryption is in use that cannot be intercepted, including by an authorized service. The reason being is that this authorized service or mechanism to allow for interception creates a point of potential vulnerability. TLSv1.3 went through a lengthy review process to ensure the protocol is provably secure. There are regular updates made as needed to ensure that remains the case, this includes preparations for post-quantum cryptographic algorithms as well as addressing any vulnerabilities discovered over time. TLSv1.2 will not support post quantum encryption, a consideration for roadmap planning.
The second is strong authentication. TLS (all versions) contains features that cross several layers of the protocol stack between the application layer at 7 and the transport layer (e.g. TCP) at layer 4. The session and presentation layer are both covered as encryption is negotiated between the 2 connecting hosts and the protocol implementation includes rich features such as a strong authentication. Mutual TLS (mTLS) is an option that can be enabled from all TLS libraries that have been implemented to assist with building a secure connection with PKI certificate-based authentication. Mutual means that both ends of the connection (client and server) authenticate to each other. Password authentication is also possible, but it is not secure. You can add-on additional forms of authentication such as one-time password (OTP) solutions or WebAuthn, with the use of additional libraries. WebAuthn, also known as passkeys, and PKI are considered phishing resistant.
While strong authentication is available in TLSv1.2, the protocol did not go through the rigorous research based process to be called provably secure as was done for TLSv1.3. Several critical changes occurred in the TLSv1.3 standard to set these two versions apart, leading TLSv1.3 to be a better fit for meeting the requirements of a zero trust architecture. This is why NIST and others had set dates to deprecate use of anything earlier than TLSv1.3 several years back. Since TLSv1.2 is still secure with appropriate configurations, other governments have allowed for additional flexibility for roadmap panning.
Changes continue to be made, updating TLSv1.3 to prevent interception and ensure connections using TLSv1.3 are strong and provably secure. As stated above, TLSv1.2 is still considered secure when configured correctly and can be used in environments considered as part of a zero trust architecture. The zero trust tenets on isolation to prevent lateral movement should be considered in the log-term roadmap towards implementing zero trust. The use of ZTNA to access individual applications that are on separate networks aid in providing the isolation properties as does the use of a routing overlay protocol such as GENEVE with IPsec to secure network traffic and provide the necessary levels of isolation.
Considerations to securely configure TLS are documented in RFC9325, including cipher suite advice that is also maintained in the IANA registry for TLS Parameters. Please keep in mind that an IANA registry is the most up-to-date source for parameter information such as recommended cipher suites and key sizes as it is maintained over time. RFCs are point-in-time publications that may have errata filed to note corrections, and may be updated in a new document that would be linked from the original, stating it updates or even obsoletes an older document version.
TLSv1.3 coupled with strong authentication meets the requirements for zero trust application access. A core belief of zero trust is that you do not trust other layers, such as infrastructure or communication protocols. TLS provides that level of security so that, if configured correctly, you don’t need to rely on WiFi (or avoiding WiFi), or other controls to protect your system, the application you are accessing, and your data. If your organization still requires a VPN, it may still be in transition to a zero trust architecture. Once applications can all be accessed using strong encryption and authentication, the requirement for the universal access VPN should fall away in favor of isolated secure application access following zero trust tenets.
VPN concentrators have been subject to attacks, such as the 2020 attacks exploiting a known vulnerability. Financial institutions were the primary target in response to sanctions placed on Iran. Access via compromise to the VPN concentrator, meant access was then permitted to all unprotected resources behind that VPN concentrator. This provides an argument for dedicated application access in the zero trust architecture design, isolating each application to prevent lateral movement.
Conclusion
A deeper understanding of protocols enables simplified security policies, breaking away from older control recommendations and embracing advancements. Design in protocols, code, and systems where security is built-in and in cases where it has been designed to be provably secure transform our options to simplify security and make it invisible. Enterprises should understand where their data transits and rests, including the potential aggregation points in order to assess business risk.
