How Secure Are My Sessions?
TLS Options and Considerations
By: Kathleen M. Moriarty
Transport Layer Security (TLS) is a critical protocol, 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 is 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 at 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
Configuration and deployment Options
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 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.
