TLS session security isn't just about encryption - it’s about where and how that encryption is terminated. This article explores common risks in TLS deployments and how to align them with modern security principles like Zero Trust.
Transport Layer Security (TLS) is a critical protocol for protecting data in transit and includes multiple options for authentication within implementations. In recent discussions, it became clear that additional information could be helpful, breaking down what a user or administrator needs to understand about TLS implementation and configuration options to better assess points of potential exposure. As such, this blog is aimed at filling that gap. The configuration options listed tie into policy for an organisation and can assist in discussions between the security and policy stakeholders in an organisation.
Understanding points of exposure
In designing secure systems, understanding TLS termination points is crucial. These points, where encryption ends and data becomes vulnerable, are inherent in TLS sessions. However, misconfigurations or unexpected interceptions can lead to data exposure. This discussion focuses on the risks tied to different TLS deployment strategies, especially for securing web applications via HTTP.
We will examine how TLS secures direct application layer traffic and establishes encrypted tunnels (ZTNA, VPNs), highlighting the termination points that impact data security. Furthermore, we'll address new TLS features for web sessions, emphasising their configuration's role in aligning with organisational security policies. The table below offers a practical guide to various deployment scenarios and their associated termination points, empowering security teams to make informed policy decisions.
Configuration or Deployment Option | Endpoints for setting (server/client) | Potential points of exposure with setting option selected | Description/Advantages |
---|---|---|---|
TLS with Encrypted Client Hello (ECH) Enabled | CDN/Client | Client-CDN | Privacy-focused; limits middlebox access. |
TLS with Encrypted client Hello (ECH) Disabled | CDN/Client | CDN-Client | Allows middlebox filtering based on SNI. |
User VPN Service | User/VPN Service | User-VPN | Anonymizes user; hides browsing history. |
Zero Trust Network Access (ZTNA) | Client/App Server | Client-Server | Dedicated app access; prevents lateral movement. |
Corporate VPN Service | Client/VPN Server | VPN Server | Network-wide access; risk of lateral movement. within corporate infrastructure. |
Interception for Monitoring (e.g. IPS) | Client/Server | Client/Server/Middlebox | Network traffic visibility for intrusion detection. |
Proxy Service Interception | Client/Proxy | Client/Proxy | Proxy decrypts/inspects traffic; new session initiated to server. |
TLS version transition planning
Many organisations 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 centralised decryption points. For legacy systems, this trade-off might have been deemed necessary. However, as organisations transition to a Zero Trust architecture, which emphasises 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 organisations, 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 on the 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 balanced 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 two applicable tenets to TLS. The property of provable security makes a strong case in favour 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 authorised service. The reason being is that this authorised 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 two connecting hosts and the protocol implementation includes rich features such as 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 ensuring 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 long-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 TLSv1.3 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 obsolete 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, organisations don’t need to rely on Wi-Fi (or avoiding Wi-Fi), or other controls to protect their systems, applications , and data. If an organisation 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 favour 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.
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.
Comments 0