Infosec Journey

Transport Layer Security (TLS) is the backbone of secure communications on the internet. It protects data as it moves between clients and servers. While TLS 1.3 has been available for over five years, and TLS 1.2 still lacks an official sunset date, regulatory bodies and security-conscious organizations are pushing hard for TLS 1.3 adoption to tackle modern security challenges and improve performance.

This blog explores the technical challenges of TLS 1.2, the security and performance gains of TLS 1.3, and what’s required for a successful migration—focusing on both application and infrastructure layers to show real-world enterprise scenarios.

The TLS Handshake: Where Security and Performance Start

All secure communications rely on the TLS handshake—a negotiation process at the start of every session. This handshake determines the cryptographic algorithms (cipher suites) to be used. It also specifies how the client and server will authenticate each other. In TLS 1.2, this process is not only more transparent (i.e., more handshake data is sent in plaintext), but also more vulnerable to misconfiguration and attacks.

Let’s spend a moment running through the key technical limitations of TLS 1.2 and how TLS 1.3 addresses them with security by design—before we explore a real-world migration scenario.

TLS 1.2: Technical Limitations

• Weak Cipher Suites: TLS 1.2 allows negotiation of outdated and insecure ciphers. Examples include RC4, SHA-1, and MD5. Connections stay at risk if these ciphers are not explicitly disabled.
• Inefficient Handshake: The handshake process requires two round trips, adding latency and slowing down connections, especially over high-latency networks.
• Unencrypted Handshake Data: Most handshake messages are sent in plaintext. This includes server certificates. This exposes sensitive metadata to anyone intercepting the traffic.
• Optional Forward Secrecy: Forward secrecy is not required in TLS 1.2. If static key exchange is used and the server’s private key is compromised, past sessions can be decrypted.

TLS 1.3: Security and Performance by Design

• No Weak Ciphers: Only strong, modern cipher suites are allowed, eliminating the risk of misconfiguration and weak encryption.
• Faster Handshake: The handshake is reduced to a single round trip, cutting connection setup time and improving performance.
• Encrypted Handshake: Most handshake messages are encrypted after the initial key exchange, protecting sensitive negotiation details from attackers.
• Mandatory Forward Secrecy: Every session uses ephemeral key exchange. This ensures that even if a server’s private key is compromised, past sessions remain secure.

With these fundamentals in mind, let’s look at what needs to change in a real-world enterprise environment to successfully migrate from TLS 1.2 to TLS 1.3.

What to Consider: Application and Infrastructure Changes with a Scenario

Let’s walk through a typical enterprise scenario:

Your company runs a Java-based web application that serves customers and internal users. The application is hosted on a mix of Linux and Windows servers. It connects to an Oracle database backend. It sits behind an Nginx load balancer. Security and compliance are top priorities, and you use a cloud security platform for visibility and compliance checks. You’re now tasked with enforcing TLS 1.3 across the environment.

Application Layer

Java Runtime:

Your app servers are running Java 8, but to fully support TLS 1.3, you upgrade to Java 11 across all nodes. This ensures the JVM can negotiate TLS 1.3 with clients and backend systems.

Protocol Configuration: You update your application’s configuration files to allow only TLS 1.3:

server.ssl.enabled-protocols=TLSv1.3

For custom SSL logic, you explicitly set TLS 1.3 in your code and restrict cipher suites to those supported by the protocol.

JDBC/Oracle: Your Oracle database is already at 19c. You update your JDBC drivers to 19c+. You configure both the driver and the database listener to accept only TLS 1.3 connections.

Dependencies: You audit all libraries. These include Spring Boot, HTTP clients, and third-party integrations. You ensure they are compatible with TLS 1.3, updating or replacing any that are not.

Infrastructure Layer

Operating Systems:
Linux servers are upgraded to use OpenSSL 1.1.1+ (required for TLS 1.3), and Windows servers are upgraded to Windows Server 2022+ to ensure native support.

Web Servers:
Nginx is recompiled or upgraded to a version linked with OpenSSL 1.1.1+. Configuration is updated:

ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384;

This ensures only TLS 1.3 connections are accepted at the edge.

Load Balancers and Proxies:
All network appliances—including load balancers and application firewalls—are reviewed for TLS 1.3 support. Firmware and software are updated as needed, and configurations are locked down to prevent fallback to older protocols.

Database:
The Oracle database listener is configured to accept only TLS 1.3, and database clients are tested to ensure compatibility.

Security Monitoring:
Security tools and monitoring platforms are reviewed to ensure they can operate effectively in a TLS 1.3-only environment, recognizing that passive decryption is no longer possible and inline inspection may be required for deep packet analysis.

At a Glance: Legacy App Example in the TLS 1.3 Transition

Suppose you have a legacy app running on Windows Server 2012 that communicates with an external API using HTTPS. If the API enforces TLS 1.3 only, the legacy app (which supports up to TLS 1.2) will fail to connect, resulting in handshake errors like:

javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version

Resolution:
Upgrade the OS to Windows Server 2022+, update the application stack to support TLS 1.3, or introduce a proxy to bridge the protocols. Note that proxies add operational complexity, performance overhead, and potential new security risks.

How to Test for TLS 1.3 Connections After Migration

Once you’ve migrated your applications and infrastructure to support TLS 1.3, it’s important to verify that your systems are actually negotiating TLS 1.3 connections. Here are a couple of practical ways to test this:

• Using OpenSSL:
  Run the following command from a terminal (requires OpenSSL 1.1.1 or later):

openssl s_client -connect yourserver:443 -tls1_3

If the connection succeeds and the protocol in the output shows TLSv1.3, your server is successfully negotiating TLS 1.3.

• Using Curl:
  You can also use curl to force a TLS 1.3 connection:

curl -v --tlsv1.3 https://yourserver

• The output will indicate if TLS 1.3 was negotiated.

These methods allow you to confirm that both your clients and servers are using TLS 1.3, ensuring your migration is complete and effective. For enterprise environments, consider automated testing and monitoring to validate ongoing compliance and catch any misconfigurations.

Some of these changes may be forced upon you by regulatory or business requirements. Whether you like it or not, you may only realize later that this shift to TLS 1.3 is for the greater good—bringing stronger security, better privacy, and a safer internet for everyone.