HTTPS, SSL & Security
What is TLS?
TLS, Transport Layer Security, is the cryptographic protocol that secures communication between clients and servers over the internet. It provides three fundamental security properties, encryption that prevents eavesdropping, authentication that verifies the server’s identity, and integrity verification that detects tampering. TLS is the technology that makes HTTPS possible, the S in HTTPS stands for Secure and that security is delivered entirely by TLS.
TLS is the direct successor to SSL: Secure Sockets Layer, the original protocol Netscape developed in the 1990s for securing web connections. SSL had significant security vulnerabilities that were discovered over time, POODLE, BEAST, and other attacks demonstrated that SSL 2.0 and SSL 3.0 were fundamentally insecure. TLS was developed as a corrected and improved replacement, TLS 1.0 was released in 1999 and subsequent versions addressed vulnerabilities discovered in earlier versions. All SSL versions and TLS 1.0 and 1.1 are now deprecated and disabled in modern browsers and servers. Current standards require TLS 1.2 as a minimum with TLS 1.3 as the preferred version.
Despite TLS being the technically correct term the industry continues to use SSL and TLS interchangeably. SSL certificates are actually TLS certificates. SSL configuration refers to TLS configuration. SSL errors are TLS errors. The terminology confusion is universal and accepted, understanding that SSL in everyday usage means TLS is essential for navigating technical documentation and conversations about web security.
TLS versions
TLS has evolved through four major versions, each addressing security weaknesses in previous versions and improving performance through better cryptographic primitives and protocol design.
TLS 1.0: released in 1999 as an upgrade from SSL 3.0. TLS 1.0 fixed the most critical SSL 3.0 vulnerabilities but retained much of the same structure and was subsequently found to have its own vulnerabilities, particularly the BEAST attack that exploited CBC cipher mode weaknesses. TLS 1.0 was deprecated by major browsers in 2020 and is disabled in all modern browsers. Servers should not offer TLS 1.0.
TLS 1.1: released in 2006 and addressed some TLS 1.0 vulnerabilities. TLS 1.1 was similarly deprecated alongside TLS 1.0 in 2020, its incremental improvements over TLS 1.0 were not sufficient to justify continued support. Servers should not offer TLS 1.1.
TLS 1.2: released in 2008 and still widely used today. TLS 1.2 introduced significant improvements, support for stronger cipher suites, authenticated encryption modes, and SHA-256 for certificate signatures. TLS 1.2 is the current minimum acceptable TLS version, all public-facing servers must support it. When configured with strong cipher suites TLS 1.2 provides robust security. It remains the fallback for clients that do not support TLS 1.3.
TLS 1.3: released in 2018 and the current preferred version. TLS 1.3 represents a significant redesign, removing support for weak and obsolete cryptographic primitives that accumulated over previous versions, simplifying the handshake to require only one round trip rather than two, and introducing 0-RTT resumption for even faster reconnections. TLS 1.3 supports only forward secrecy cipher suites, ensuring that compromise of a server’s private key does not enable decryption of previously captured traffic. Modern browsers and servers support TLS 1.3 and prefer it when both sides support it.
The TLS handshake in detail
The TLS handshake is the process that establishes a secure session before any application data is transmitted. Understanding the handshake clarifies what TLS actually does and why it provides the security properties it claims.
TLS 1.2 handshake: the TLS 1.2 handshake requires two round trips before the encrypted session begins, one more than TLS 1.3.
The client sends Client Hello, specifying the highest TLS version it supports, a list of cipher suites it can use, a random value, and session ticket information for resuming previous sessions.
The server responds with Server Hello, selecting the TLS version and cipher suite, followed by its certificate and optionally a ServerKeyExchange message for Diffie-Hellman key exchange parameters. The server sends ServerHelloDone to signal it has finished its initial messages.
The client verifies the certificate chain, performs key exchange by sending ClientKeyExchange, deriving the pre-master secret, and sends ChangeCipherSpec to indicate switching to encrypted communication, followed by a Finished message encrypted with the derived session keys.
The server verifies the client’s Finished message, sends its own ChangeCipherSpec and Finished message. The handshake is complete and encrypted application data can flow.
TLS 1.3 handshake: TLS 1.3 reduces the handshake to one round trip, a significant performance improvement particularly on high-latency connections.
The client sends Client Hello, including key share data for supported Diffie-Hellman groups alongside the standard hello information. This allows the server to derive shared key material in the same message rather than requiring a separate key exchange round trip.
The server responds with Server Hello, selecting parameters and including its key share, followed by encrypted extensions, certificate, and Finished message. All server messages after Server Hello are encrypted because shared key material is already established.
The client verifies the server certificate, sends its Finished message, and the encrypted session begins. One round trip total from client hello to encrypted data.
0-RTT resumption in TLS 1.3: TLS 1.3 introduces 0-RTT, zero round trip time, resumption for reconnecting to servers that have been contacted before. The client sends early data, encrypted application data, with the Client Hello rather than waiting for the handshake to complete. This eliminates the handshake latency entirely for reconnections. 0-RTT has limitations, replay attack resistance requires careful implementation, and is used selectively for specific use cases.
TLS cipher suites
A cipher suite is a combination of cryptographic algorithms used together in a TLS connection, specifying the key exchange algorithm, authentication algorithm, encryption algorithm, and message authentication code algorithm. The cipher suite is negotiated during the TLS handshake, the client offers a list of supported suites and the server selects one from the offered options.
TLS 1.2 cipher suites: TLS 1.2 supports a wide range of cipher suites, including both strong modern suites and weak legacy suites retained for backward compatibility. A well-configured TLS 1.2 server should support only strong cipher suites.
Strong TLS 1.2 cipher suites use ECDHE or DHE for key exchange, providing forward secrecy, AES-GCM or CHACHA20-POLY1305 for authenticated encryption, and SHA-256 or SHA-384 for message authentication.
Weak cipher suites that should be disabled include RC4, a broken stream cipher, 3DES, vulnerable to SWEET32 birthday attacks, CBC mode suites vulnerable to BEAST and Lucky 13, and any suite using NULL encryption or static RSA key exchange without forward secrecy.
TLS 1.3 cipher suites: TLS 1.3 removed all weak cipher suites from the specification, only five cipher suites are defined and all are strong. The choice between TLS 1.3 cipher suites is purely about performance preference between AES-GCM and CHACHA20-POLY1305. TLS 1.3 mandated forward secrecy by removing all non-ephemeral key exchange options.
Forward secrecy: a cryptographic property where compromise of the server’s long-term private key does not enable decryption of previously captured TLS sessions. Forward secrecy is provided by ephemeral Diffie-Hellman key exchange, ECDHE or DHE, where unique key material is generated for each session and discarded afterward. Even if the server’s certificate private key is later compromised an attacker who captured encrypted traffic cannot retroactively decrypt it. Forward secrecy is a requirement of TLS 1.3 and a strong recommendation for TLS 1.2 configurations.
TLS certificates vs SSL certificates
The terminology around TLS and SSL certificates creates confusion, understanding the relationship between them clarifies what certificates actually are and do.
Certificates are independent of the protocol version: an SSL certificate and a TLS certificate are the same thing, an X.509 digital certificate that binds a public key to a domain name. The certificate format is defined by the X.509 standard, not by the SSL or TLS protocol specifications. The same certificate is used whether the connection uses TLS 1.2 or TLS 1.3. The protocol version is negotiated during the handshake, the certificate is simply presented and verified regardless of which protocol version is used.
Why they are called SSL certificates: the SSL naming convention for certificates persists because SSL certificates were introduced during the SSL era and the terminology stuck. Certificate authorities continue to call their products SSL certificates. Certificate management tools refer to SSL certificates. The hosting and web server industry uses SSL certificate as the universal term. Technically all modern certificates are TLS certificates, but practically they are called SSL certificates universally.
Certificate validation types: certificates come in DV, OV, and EV validation levels as described in the SSL article: these validation levels are independent of TLS version. A DV certificate can be used with TLS 1.2 or 1.3 equally. The validation level affects what identity information the CA verified and included in the certificate, not how the cryptographic protocol uses the certificate.
TLS and redirect management
TLS is the security foundation beneath all HTTPS-based redirect management. Every redirect involving HTTPS depends on TLS functioning correctly at each endpoint in the redirect chain.
TLS on redirect source domains: when a browser attempts to reach https://redirect-source.com the TLS handshake must succeed before the redirect response can be received. The redirect source domain must have a valid certificate, the TLS handshake verifies the certificate before any HTTP communication occurs. A missing or invalid certificate on the redirect source domain means HTTPS visitors never receive the redirect, they see a TLS error instead.
This requirement applies to all redirect source domains regardless of their purpose, brand protection domains, legacy domains, and any other domain configured as a redirect source. Every source domain needs its own certificate, or coverage under a wildcard or multi-domain SAN certificate, for HTTPS redirects to function.
TLS version requirements: modern browsers require TLS 1.2 as a minimum. Redirect infrastructure that only supports older TLS versions, TLS 1.0 or TLS 1.1, fails for visitors using modern browsers. Redirect management platforms should support TLS 1.2 and TLS 1.3 on all connected domains.
HSTS and TLS: HTTP Strict Transport Security instructs browsers to connect to a domain exclusively over TLS, eliminating HTTP connections and the HTTP-to-HTTPS redirect entirely. An HSTS header on a redirect destination domain tells browsers that all future connections to that domain must use TLS. This adds an additional layer of TLS enforcement beyond the server-side redirect.
Certificate provisioning for redirect domains: managing TLS certificates for large redirect domain portfolios, dozens or hundreds of source domains, is operationally significant without automation. Dedicated redirect management platforms that integrate automated certificate provisioning through Let’s Encrypt or similar ACME-based CAs provision and renew certificates for all connected domains automatically, eliminating certificate management from redirect operations.
TLS performance optimisations
TLS adds computational and latency overhead to connections, though modern implementations have reduced this overhead dramatically. Several optimisations improve TLS performance.
TLS session resumption: when a browser reconnects to a server it has previously connected to TLS session resumption allows the handshake to be abbreviated, reusing key material from the previous session. TLS 1.2 supports session IDs and session tickets for resumption. TLS 1.3 introduces more efficient resumption mechanisms including 0-RTT for the fastest possible reconnections.
OCSP stapling: Online Certificate Status Protocol allows browsers to check whether a certificate has been revoked. Without stapling the browser makes a separate connection to the CA’s OCSP server to check revocation status, adding latency to the TLS handshake. OCSP stapling moves this check to the server, the server periodically queries the CA’s OCSP server and staples the response to the TLS handshake, eliminating the browser’s separate OCSP request.
HTTP/2 and TLS: HTTP/2 requires TLS in all major browser implementations. HTTP/2’s multiplexing, multiple requests over one connection, reduces the number of TLS connections needed for a page load. The overhead of TLS connection establishment is paid once per session rather than once per resource, significantly reducing the proportional cost of TLS on HTTP/2 connections.
TLS hardware acceleration: modern CPUs include hardware acceleration for AES encryption, the most common TLS encryption algorithm. Hardware-accelerated AES reduces the computational cost of TLS encryption to near zero on modern server hardware, eliminating encryption overhead as a meaningful performance concern.
Checking TLS configuration
Verifying TLS configuration ensures secure connections are established correctly and that deprecated protocol versions and weak cipher suites are not offered.
SSL Labs SSL Test: the most comprehensive free TLS analysis tool. Running the test against a domain provides a detailed report including supported TLS versions, cipher suites offered, certificate chain validation, forward secrecy support, and overall configuration grade. The grade, A+ through F, provides a quick assessment of configuration quality.
OpenSSL command line testing: testing specific TLS versions:
Testing whether deprecated versions are rejected:
A correctly configured server should refuse TLS 1.1 connections, the handshake fails if the server does not support the specified version.
Browser developer tools: the Security tab in browser developer tools shows the TLS version and cipher suite used for the current connection. This is a quick check of what version was negotiated for a specific page load, useful for verifying TLS 1.3 is being used when both client and server support it.
TestSSL.sh: an open-source command-line tool that performs comprehensive TLS configuration testing, checking for supported versions, cipher suites, known vulnerabilities, HEARTBLEED, POODLE, BEAST, ROBOT, certificate issues, and many other configuration aspects. More detailed than SSL Labs for server-side testing.