Vault 📚

02_tls

7 min read

Transport Layer Security

Transport Layer Security, commonly abbreviated as TLS, is a cryptographic protocol that protects data transmissions over computer networks. It succeeds the older SSL (Secure Sockets Layer), and though the term “SSL” is still widely used, most modern “SSL” connections are really TLS. The protocol aims to make sure that data moving between parties, such as a user’s browser and a web server, cannot be intercepted, read, or modified by anyone else. By encrypting and verifying identities through certificates, TLS helps preserve confidentiality and authenticity for a wide range of applications, from simple webpage visits to sophisticated web services.

TLS versus SSL

TLS started as a direct upgrade to SSL, improving the protocol’s security and addressing vulnerabilities. SSL is now deprecated, and recent versions of web servers and browsers rely on TLS 1.2 or TLS 1.3 for secure communications. Although people might still refer to “SSL certificates” or “SSL connections,” the underlying technology is almost always TLS.

Concepts in TLS

TLS relies on encryption and identity verification to secure communication sessions. Encryption makes sure that the transmitted data is indecipherable to eavesdroppers, while identity verification relies on digital certificates and certificate authorities to confirm the authenticity of the server (and optionally the client). Once the TLS handshake completes, both parties share session keys to encrypt and decrypt subsequent data with minimal overhead.

TLS Handshake

When a client, such as a web browser, accesses a server via HTTPS, a TLS handshake occurs to set up how data will be encrypted and to verify identities. The following ASCII diagram outlines this process:

Client (Browser)                        Server (Website)
    |                                       |
    | 1. ClientHello ---------------------> |
    |    (Supported TLS versions, ciphers)  |
    |                                       |
    | <--------------- 2. ServerHello ------|
    |    (Chosen cipher, certificate)       |
    |                                       |
    | 3. Certificate Verification           |
    |    (Validate server's certificate)    |
    |                                       |
    | 4. Key Exchange --------------------> |
    |    (Client sends encrypted pre-master)|
    |                                       |
    | <------------ 5. Server Key Exchange  |
    |    (Both generate session keys)       |
    |                                       |
    | 6. Secure Communication --------------|
    | (Data encrypted with session keys)    |
    |                                       |
    | <------------- Encrypted Data --------|
    | (Server responses also encrypted)     |
  1. The client initiates contact by listing its supported TLS versions and cipher suites.
  2. The server responds with its chosen version, cipher suite, and a certificate.
  3. The client checks that the certificate is valid.
  4. The client and server perform a key exchange, often involving short-lived Diffie-Hellman or elliptic-curve cryptography, so they derive a unique session key.
  5. The server confirms or finalizes the key information, and once both sides agree, the secure channel is in place.
  6. All subsequent messages are encrypted with the session key.

TLS Certificates

A TLS certificate affirms the server’s identity. Certificate Authorities (CAs) issue certificates after verifying the domain ownership (and sometimes more details about the organization). The certificate embeds the public key of the server and is digitally signed by the CA, so clients can verify that no tampering or impersonation has occurred.

To trust a certificate, the client checks whether the CA’s own certificate is in its trust store. Browsers ship with many trusted CAs, so any certificate signed by one of those CAs is considered valid if it passes all checks (expiration date, matching domain name, etc.).

Why TLS Matters

Security is the core motivation for TLS. By encrypting data, TLS defends against eavesdroppers who might otherwise capture sensitive information such as login credentials or payment details. Through certificates, TLS also makes sure that users connect to the intended site rather than an imposter, helping thwart man-in-the-middle attacks. Search engines and browsers often rank or flag sites based on HTTPS adoption, so deploying TLS can enhance reputation and trustworthiness.

TLS Versions

TLS 1.2

Released in 2008, TLS 1.2 improved on older versions with more secure hashing (e.g., SHA-256), support for authenticated encryption (AEAD ciphers), and explicit negotiation of signature algorithms. Over time, several vulnerabilities arose (like BEAST, CRIME, and POODLE) that required specific mitigations or changes to cipher configurations. Despite these issues, TLS 1.2 has remained widely used and remains functional when configured securely with modern cipher suites.

TLS 1.3

Finalized in 2018, TLS 1.3 significantly simplified the handshake and removed numerous obsolete or insecure features:

  • Fewer Round Trips: The handshake requires fewer messages, speeding up the initial connection.
  • Mandatory Forward Secrecy: Short-lived key exchanges mean that even if a long-term private key leaks, old sessions remain secure.
  • Removal of Weak Cryptography: Old key exchange methods (static RSA, older Diffie-Hellman groups, etc.) and ciphers are gone, so typical pitfalls are reduced.
  • 0-RTT Resumption: Allows clients to send data immediately upon reconnecting, though it must be deployed carefully to avoid replay attacks.

Many servers and clients now support TLS 1.3 by default, but some older software can only use TLS 1.2 or earlier.

Upgrading from TLS 1.2 to TLS 1.3

Transitioning to TLS 1.3 can yield both performance and security benefits. However, it requires making sure that servers, clients, and libraries are ready. This might involve:

  • Checking that your server software (like Apache, Nginx, or a Java-based server) supports TLS 1.3.
  • Setting the server configuration to allow TLS 1.3 in addition to TLS 1.2 for fallback.
  • Enabling modern cipher suites that align with TLS 1.3.
  • Updating or replacing older client libraries that do not support TLS 1.3. Phased rollouts, with logging to identify any legacy clients failing to connect, help make sure a smooth transition.

Carrying out TLS in Applications

Obtaining a Certificate

A TLS setup begins with acquiring a certificate. In many cases, you:

  1. Generate a private key and a Certificate Signing Request (CSR).
  2. Send the CSR to a Certificate Authority (e.g., Let’s Encrypt, DigiCert).
  3. Receive the signed certificate, which includes the public key and CA signature.

Below is an example command sequence using OpenSSL to create a private key and CSR:

openssl req -newkey rsa:2048 -nodes -keyout mysite.key -out mysite.csr

This prompts for information about your organization and domain, producing mysite.key (private key) and mysite.csr (CSR). You then submit mysite.csr to the CA.

Installing the Certificate on the Server

Once the CA returns mysite.crt, place it on the server along with mysite.key. The final steps vary by web server:

Example (Nginx snippet):

server {
    listen 443 ssl;
    server_name mysite.example.com;

    ssl_certificate     /etc/ssl/certs/mysite.crt;
    ssl_certificate_key /etc/ssl/private/mysite.key;

    # TLS 1.2 and 1.3 only
    ssl_protocols TLSv1.2 TLSv1.3;

    # A recommended set of ciphers for better security
    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:...";

    # Your site config here
    root /var/www/mysite;
}

After reloading or restarting Nginx, requests to https://mysite.example.com/ are secured by TLS.

Enforcing HTTPS in the Application

Switch code references to use https:// URLs. If users visit the site via HTTP, set up redirects or use HSTS headers to push them to HTTPS. In an Nginx config, you might add:

server {
    listen 80;
    server_name mysite.example.com;
    return 301 https://mysite.example.com$request_uri;
}

This makes sure all traffic is funneled to the secure port.

Testing

Use an external SSL checker to confirm the certificate is correctly installed and that the server’s cipher suites are modern. Tools like SSL Labs (Qualys) provide an in-depth report, highlighting potential vulnerabilities, misconfigurations, or outdated protocol versions.

TLS Best Practices

Deploying TLS effectively calls for attention to detail in configuration and key management.

  1. Prefer the Latest Versions: Aim for TLS 1.2 or 1.3.
  2. Use Strong Cipher Suites: Disable older ciphers like RC4 or 3DES.
  3. Maintain Key Security: Keep private keys in secure directories with limited permissions.
  4. Use HSTS: HTTP Strict Transport Security makes sure browsers do not attempt insecure connections.
  5. Renew Certificates Promptly: Certificates expire. Monitor expiration dates and automate renewals if possible.
  6. Remove Insecure Protocol Versions: Disable TLS 1.0/1.1 and all SSL versions unless strictly required by legacy systems.
  7. Monitor Logs: Keep an eye on server logs for handshake failures or suspicious activity.

Graph View