Why now?
It’s early 2025 – why are we still talking about SSL/TLS/Security practices? Unfortunately, many organizations and companies have not been able or willing to migrate to the new standard. More appalling, Alexa reports that over 20% of the sites on the internet do not use SSL or TLS, in spite of a laundry list of security concerns. (Nohe, 2018)
The lack of widespread implementation of TLS protocols is concerning and is evidence of the backwards compatibility that has been removed in the various standards. While all modern operating systems support TLS 1.0 and above; modern is still a relative term. Windows Vista for example is only 18 years old, but doesn’t support TLS 1.2. (Vera, 2024)
Achieving consistent security requirements is not only difficult for companies, but government agencies charged with a mandate to protect personal information such as PII and PHI data transmitted to requesters. Sites and services available to end users who rarely have a requirement to upgrade their personal computing devices (smart phones and personal computers). In 2024 the reported distribution of Windows 8 and older WIndows operating systems, that by default supported TLS 1.2 was around 5% (Sherif, 2024)
Blame for the lack of migration to the new standard isn’t solely on users who fail to migrate to the latest and greatest devices. Many end user devices run TLS 1.3 supporting operating systems. Companies and government organizations are some of the biggest drivers of adoption, first as a method of best practice but also through regulatory requirements. Many of these regulatory requirements dictate that governments and organizations must begin moving toward TLS 1.3, either implicitly or explicitly. In the United States, FIPS, NIST, and OMB clearly emphasize a preference and support toward moving to TLS 1.3:
- Federal Information Processing Standards (FIPS) Publication 140-2:This standard specifies security requirements for cryptographic modules protecting sensitive information. It indirectly impacts TLS by requiring the use of approved cryptographic algorithms, which are often tied to specific TLS versions.
- National Institute of Standards and Technology (NIST) Special Publications: NIST provides guidance on various aspects of information security, including the use of TLS. NIST SP 800-52 Revision 2 specifically addresses TLS implementation and recommends using the latest TLS versions (currently 1.2 and 1.3) and disabling outdated and insecure versions (SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1).
- Office of Management and Budget (OMB) Circular A-130: This circular outlines management of federal information resources and emphasizes the importance of security controls, including the use of appropriate encryption protocols like TLS.
Across the pond, UK organizations are subject to broader data protection and cyber security laws that, while not as forthright in their specifics, still indirectly require the use of up-to-date and secure TLS versions:
- Data Protection Act 2018 This Act requires organizations to implement appropriate technical and organizational measures to ensure the security of personal data. Using outdated and insecure TLS versions could be considered a failure to meet these obligations.
- Network and Information Systems (NIS) Regulations 2018 These regulations apply to operators of essential services and digital service providers. They require organizations to take appropriate security measures to manage risks to network and information systems. This would likely include using secure TLS versions.
What Can You Do
Like any good recovery program, the first step is identifying that you have a problem. Traditionally, this is a task for IT administrators, Engineers, and Cyber Security professionals; however, end users can perform this task on their own machines. Mileage will vary depending upon their specific operating system. The easiest way to identify the sites SSL version is to utilize the openssl library to interrogate their web sites and resources:
In the above example, we can see that the Amazon hosted website for DIOS-Tech is leveraging TLS 1.3. By comparison, Speakeasy only implements TLS 1.2:
This isn’t to blame any single company or group of users, but to make more readily available the knowledge of how these security mechanisms work and how to help people improve them. TLS 1.3, for example, is preferred, but any type of encrypted communication is better than none at all.
Once we’ve identified whether or not we have a problem, it’s time to look at the specific technology stack and begin engineering a resolution. In many cloud cases, this is a non issue. Vendors such as Microsoft, Google, and AWS have already implemented and defaulted to secure protocols, such as TLS 1.3 (API Gateway now supports TLS 1.3, 2024). Many of our US Government customers implement web applications and services using .Net. While .Net application loads are not solely limited to Windows platforms, they are definitely more predisposed to running on top of Windows Servers. For Windows 2008 R2 and later, TLS 1.2 can be enabled by default. (Rahul, January 2024) In the vast majority of Microsoft Windows Server implementations the steps are the same to enable various TLS versions. Open registry editor and update the following registry keys:
- [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2
- [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] “DisabledByDefault”=dword:00000000 “Enabled”=dword:00000001
- [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] “DisabledByDefault”=dword:00000000 “Enabled”=dword:00000001
These keys can be rinsed and repeated for other SSL/TLS protocols (eg. SSL 1.0, 2.0, and so on depending on platform compatibility). Unfortunately, Windows operating systems, including Windows 2016, do not support TLS 1.3.
In Unix/Linux environments the prevailing web service mechanism is Nginx and Apache. Regardless of the software generally the solution is pretty straightforward. Implementation of the relevant sections within the configuration file to support the correct protocol, as shown in the below Nginx example (Vivek, 2024) (Rahul, June 2024):
ssl_protocols TLSv1.2 TLSv1.3;
SSLProtocol -all +TLSv1.2 +TLSv1.3
In many cases this might require a package upgrade that may cause dependency issues with other installed software. This is where many of our customers start to see complexity that initially slows and can even stall their progress to leveraging the latest version of TLS. In examples such as application or web servers that can’t be easily updated without refactoring of applications or application components, choke points in the usage of TLS 1.3 start to develop. Consider a distributed application that depends on a Windows 2016 system to host one of the overalls applications web components. While other components such as the CDN can be built to leverage TLS 1.3 the older Windows hosted components can only be upgraded to TLS 1.2, resulting in the inability for the organization to utilize TLS 1.3 exclusively for their client machines.
In some cases, these issues can be effectively resolved by the use of proxies, Web Application Firewalls (WAF), or certain types of load balancers. In many of these examples, client SSL traffic can be terminated at the appliance or WAF. This allows components that may not be directly TLS 1.3 compatible participate in an overall application system that does support the upgraded protocol. Like web server configurations; configuring TLS 1.3 on devices, like the F5, is a relatively trivial matter. Specifically, all the device required is configuration SSL Server profiles cipher group to only support TLS 1.3. (K39580786: Configure the SSL profile to allow TLS 1.2 and 1.3 only, 2023). F5 is not the only vendor currently offering customers the ability to restrict their TLS versions to 1.3. Many such as ZScaler also have best practice articles that demonstrate how the vendor community is ready to provide mechanisms by which organizational and modernization shortcomings can be solved, at least in the short term.
It’s important to recognize that while switching to TLS 1.3 is the best case scenario, in many cases where this is simply not a solution, the strategy that IT professionals should consider centers around identification, communication and management of the problem. It’s important to identify and track points of failure that can stop your organization from implementing the best security posture possible. Significantly enough this mirrors industry wide practices, such as Risk Mitigation Framework, wherein risk is identified, quantified, and tracked until the risk can be completely mitigated. It’s important to remember that IT modernization is a marathon, not a sprint, and identifying these components so that a strategy can be developed and incorporated into your organization’s roadmap. Successful implementation of modern secure communication protocols, such as TLS 1.3, are integral parts of this roadmap and critical to protecting your organizations, and its customers, most important product – their data.