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 organization and can assist in discussions between the security and policy stakeholders in an organization.
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, emphasizing their configuration's role in aligning with organizational 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 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 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.
Read part two of this two-part blog series: Part 2: How Secure are my Sessions?