Transport Layer Security (TLS) is an internet security protocol designed to safeguard data and network communications — and is the official successor to Secure Sockets Layer (SSL). TLS is critical to protecting users and infrastructure as messages flow between web applications, APIs, LLMs, and their corresponding web servers.
TLS was first introduced in 1999 with the release of TLS 1.0. Since then, updated versions of TLS have launched to alleviate performance, security, and compatibility issues across web browsers and servers. The protocol has also changed hands. While Netscape previously owned all versions of SSL, the Internet Engineering Task Force (IETF) has claimed oversight for every TLS version since its launch.
Despite distinctions in ownership and functionality, TLS and SSL are often (incorrectly) used interchangeably. All versions of SSL have security issues (addressed by TLS) and are generally disabled outside of older applications. These apps must usually be fronted by a proxy such as HAProxy to ensure that all traffic over the internet is secure.
Bringing "TLS" into common usage as the default terminology has been an ongoing battle between users, organizations, and maintainers as the protocol continues to evolve — diverging further and further from SSL. This change isn't based purely on semantics.
How does Transport Layer Security (TLS) work?
The basics
Transport Layer Security (TLS) first needs to establish a connection between client and server to function properly. This requires a handshake process (two steps for TLS 1.2, one step for TLS 1.3) that works like this:
The client and server establish a connection and specify which TLS version they'll each use. This defaults to the newest common version used between both parties. For example, if a client only supports TLS 1.2 and a web server supports TLS 1.3, then TLS 1.2 will be chosen.
Both client and server choose a cipher suite to use.
The server's TLS certificate authenticates its identity for the client. This completes the handshake.
Finally, the process creates session keys to encrypt shared messages between client and server. The server uses a private key managed by and known only to it, while the client uses a public key to decipher encrypted server responses.
Any web application that uses HTTPS, the secure variant of the HTTP protocol, also uses TLS by default. If you see that padlock icon in your browser's address bar, then you're visiting a website secured via TLS.
Earlier conversations around TLS (and especially SSL) centered on TLS' impact — either measured or perceived — on overall application performance. Many have long believed that TLS adds notable latency and slows the exchange of data.
With modern enhancements to TLS and infrastructure that enables network communication (such as routers and load balancers), the cost of using TLS is now minimal. The biggest performance hit happens during the handshake. Plus, newer features such as zero round-trip time (0-RTT) resumption have eliminated the handshake process on familiar websites.
Depending on the TLS cipher used, both the server and client will unscramble and authenticate each encrypted message it receives and re-package it into a readable format.
Understanding TLS cipher suites
TLS enables encryption of client requests and backend responses using a number of available encryption algorithms such as AES-256, ChaCha-20, and various flavors of AES-128 that use SHA-256 hashing. This combination of encryption and hashing strengthens data privacy while protecting data integrity, respectively. These components make up the TLS protocol's cipher suite.
Each TLS version ships with its own cipher suite. These suites regularly change (growing or shrinking) in response to known vulnerabilities and the introduction of new technologies. While many algorithms have stood the tests of time and implementation, others have become less viable for various reasons.
For example, TLS 1.2 specifies 37 cipher suites, and the protocol supports a whopping 319 total cipher suites when considering previous versions. Meanwhile, TLS 1.3 has cleaned things up dramatically and only supports five cipher suites.
These algorithms also run in different modes:
Galois/Counter (GCM) mode – Using universal hashing, this block cipher operation mode provides privacy, data integrity, and authentication using a message authentication code (MAC).
Counter with cypher block chaining message authentication code (CCM) – This mode is used with block ciphers to provide data encryption and integrity. CCM is less common than GCM and also performs plaintext message authentication instead of using cipher text.
Both of these have their advantages and disadvantages, yet give users options depending on their use cases.
While these operate as block ciphers — packaging data into units with fixed sizes — a method such as ChaCha20 is considered a stream cipher. Stream ciphers combine plaintext data byte-by-byte with cipher data using a symmetric key. They're typically very fast and excel at handling large quantities of streaming data.
Does HAProxy support Transport Layer Security (TLS)?
Yes! HAProxy products support TLS 1.2 and TLS 1.3, enabling clients and servers to use the latest TLS version while offering a fallback option for greater compatibility. We also support features such as mTLS, TLS bridging, TLS termination, server name identification (SNI), and 0-RTT to secure messages and deliver them as quickly as possible.
To learn more about TLS support within HAProxy, check out our TLS documentation.
