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 post 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
Understanding TLS termination points is crucial in designing secure systems. 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, such as Zero Trust Network Access (ZTNA) and 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 organizational security policies.
Table 1 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 | Content Delivery Network (CDN) / server and client. | TLS session runs from the client to the CDN with the browser and CDN termination point as the points of exposure. | This prevents any middle box service from accessing the content of a session, protecting the user's privacy. This also prevents any screening of the content by security services. DNS is the primary point of exposure as well as the control point for administrators to restrict access. |
| TLS with Encrypted Client Hello (ECH) disabled | Content Delivery Network (CDN) / server and client. | TLS session runs from the CDN to the browser, with the Server Name Indicator visible to screening services that may filter at the URL level, extending beyond DNS hostname | Allows for middle boxes in place that screen content either for filtering or to alert on indicators of compromise (loCs) to see the SNI value. |
| User VPN service | The user may elect to use a personal VPN service. | The user's browser and the VPN service termination point are the points of exposure. The VPN service creates TLS session to the user's destination to mask and anonymize the user from the desired point of connection | This may be selected to anonymize the user's access to a site or to obscure the sets of sites visited by a user since the original point will show as the VPN provider. |
| Zero Trust Network Access (ZTNA) | This option refers to an application that accepts only secure connections from clients using end-to-end TLSv1.3 connections from a client to the application termination point on or near (load balancer) the application server. Strong authentication is enabled between these endpoints. | The end user system and the server or load balancer are the points of exposure. In other words, there are no additional points of exposure as the application will have access to all user transactions. | The TLS session is dedicated to a single application. There are no connections to other applications, including similar applications used by the same organization or the same application from the provider for a separate tenant. This is a zero-trust measure to prevent lateral movement and allow for alerts when set boundaries are crossed. |
| Corporate VPN service | To access a corporate network a VPN is used to terminate a connection from an end user to the network, allowing access to all systems accessible from that network. This is typically coupled with strong authentication. | If access is gained into the VPN service, all assets behind the VPN are accessible This is a model being phased out in favor of direct secure access on a per-application basis using Zero Trust Network Access (ZTNA). | A traditional VPN service is easy to set up to allow a remote user to connect to any service or application operating on the network protected by the VPN service. Lateral movement is possible between applications on the same network by the user and by a successful attacker. |
| Interception for monitoring (such as IPS) | This option is used on internal networks, with the administrator managing the use of a shared key across TLS configurations, including that of the monitoring point. The places where content is exposed include the client, server, and the interception points that allow for this passive monitoring technique. The user is only aware of the client and server as the endpoints and places where data is decrypted. | TLSv1.2 allows the use of a shared key to be used on a network, enabling interception capabilities to decrypt, access network data, then re-encrypt once traffic/data has been inspected. This creates a point on the network where all traffic is visible. The monitoring server is typically secured to prevent unwanted access. | This method allows for intrusion detection or other monitoring to occur passively on a network. A point of aggregation is created, where all traffic is visible that may otherwise be separated by service with access and network controls to prevent lateral movement. |
| Proxy service interception | In addition to the TLS endpoints, the TLS proxy service allows for the TLS session to terminate at the proxy service, the traffic to be inspected, and then for the TLS session to initiate from the proxy server to the other TLS endpoint. The client is configured to accept the PKI certificate used for the proxy server. | The proxy server is an additional point of exposure in addition to the TLS endpoints. In this case, the client is aware of the interception since a certificate and PKI key pair other than the destination is in use. This certificate is configured once, so it may be part of a standard browser install on corporate-managed systems and the user may forget it is in place. A proxy server is typically tightly managed and secured to mitigate the chance of an attack being successful. | A proxy service can be used in the firewall to detect malicious or unwanted traffic. Traffic is decrypted for inspection with the TLS session terminating at the proxy server and then a new session is created from the proxy server to the destination server. |
Table 1 — Configuration and deployment options.
TLS version transition planning
Many organizations have historically relied on TLSv1.2’s passive interception, enabling middleboxes 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 tradeoff 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, it obsoleted TLSv1.2. You can still use an obsoleted protocol, its deprecation 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 (such as 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 on 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.
Kathleen Moriarty is the Founder of SecurityBiaS, a Technology Strategist, CTO, Board Member, Keynote Speaker, Author, CISO, and former IETF Security Area Director. She has more than two decades of experience working on ecosystems, standards, and strategy. Kathleen was CTO at the Center for Internet Security when writing this post.
Adapted from the original at the RSA conference blog.
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.