How Does TLS/SSL Security Work

What is TLS and Why Does Every HTTPS Connection Need It? #

Transport Layer Security (TLS) is the protocol that encrypts data traveling between a web browser and a server. When you see "https://" in a URL, TLS is the technology making that connection private. Without it, everything a user sends or receives, including passwords, credit card numbers, and personal data, travels across the network in plain text where anyone on the same network segment can read it.

TLS is the modern successor to Secure Sockets Layer (SSL), an older protocol that is no longer considered safe. Although many people still say "SSL" out of habit, all current secure connections use TLS. The two names are often used interchangeably, but the underlying protocol in use today is always TLS.

TLS provides three guarantees for every connection. First, encryption makes the data unreadable to anyone except the intended recipient. Second, authentication confirms the server is who it claims to be through a digital certificate. Third, integrity ensures the data has not been tampered with during transit. Together, these protections form the foundation of trust on the web.

Running a website without TLS has real consequences. Search engines penalize HTTP sites in rankings. Browsers display "Not Secure" warnings in the address bar, which drives away visitors. And regulatory frameworks like PCI DSS (the standard governing credit card processing) require encryption for any page that handles payment data.

TLS Versions: Which to Support and Which to Disable #

Not all TLS versions are created equal. Older versions contain known vulnerabilities that attackers can exploit, while newer versions offer stronger encryption and better performance. Your server should support TLS 1.2 at minimum and TLS 1.3 as the preferred protocol.

TLS 1.3

Recommended

The latest version, finalized in 2018. It removes outdated cryptographic primitives, mandates forward secrecy (explained below), and completes the handshake in a single round trip, making connections both more secure and faster. All major browsers support TLS 1.3.

TLS 1.2

Acceptable

Still widely used and considered secure when configured with strong cipher suites. It supports forward secrecy through ECDHE key exchange but also allows weaker options that should be disabled. TLS 1.2 is the minimum version required for PCI DSS compliance.

TLS 1.1 and TLS 1.0

Deprecated

Both versions were officially deprecated by the IETF in 2021 (RFC 8996). They are vulnerable to attacks like BEAST and POODLE. All major browsers have dropped support. Disable these on your server.

PCI DSS requirement

PCI DSS (Payment Card Industry Data Security Standard) version 4.0 requires TLS 1.2 or higher for any system that stores, processes, or transmits cardholder data. Sites still allowing TLS 1.0 or 1.1 will fail compliance audits.

Cipher Suites: What They Are and Which Ones to Use #

A cipher suite is a set of algorithms that together handle encryption, authentication, and data integrity for a TLS connection. When a browser connects to your server, the two sides negotiate which cipher suite to use. The server should be configured to prefer strong suites and reject weak ones.

A typical cipher suite name like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 describes four components: the key exchange method (ECDHE, which provides forward secrecy), the authentication algorithm (RSA), the encryption cipher (AES-256 in GCM mode), and the hash function (SHA-384). In TLS 1.3, cipher suite names are simpler because the protocol mandates forward secrecy and only allows strong algorithms.

Forward secrecy (also called perfect forward secrecy or PFS) means that each connection uses a unique, temporary key. If someone records your encrypted traffic and later obtains your server's private key, they still cannot decrypt past sessions because the session keys were never stored. ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) is the key exchange method that provides this property. TLS 1.3 requires forward secrecy for all connections.

Strong Cipher Suites

TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

TLS_AES_128_GCM_SHA256

ECDHE-RSA-AES256-GCM-SHA384

Weak Cipher Suites (Disable These)

RC4 (stream cipher, multiple vulnerabilities)

DES (56-bit key, trivially broken)

3DES (vulnerable to Sweet32 attack)

MD5-based ciphers (collision attacks)

Certificate Types and What They Validate #

A TLS certificate is a digital document that proves your server's identity to visitors. It is issued by a Certificate Authority (CA), a trusted organization that verifies your claim to a domain or organization name. The browser checks the certificate against its built-in list of trusted CAs. If the certificate is valid and the chain of trust is intact, the browser establishes an encrypted connection.

The certificate chain (also called the chain of trust) is the sequence of certificates linking your server's certificate back to a root CA that the browser trusts. Your server certificate is signed by an intermediate CA, which is in turn signed by the root CA. If any link in this chain is missing or invalid, the browser will show a security warning.

Domain Validated (DV)

Basic

The CA confirms you control the domain, typically through a DNS record or email challenge. DV certificates are issued in minutes and are free from providers like Let's Encrypt. They are sufficient for most websites, blogs, and applications where the organization's legal identity does not need to be displayed.

Organization Validated (OV)

Enhanced

The CA verifies the organization's legal existence and domain ownership. OV certificates take one to three business days to issue. They include the organization name in the certificate details, which users can view by clicking the padlock icon. Suitable for business websites and e-commerce platforms.

Extended Validation (EV)

Maximum

The most thorough validation level. The CA verifies domain ownership, legal identity, physical address, and operational status. EV certificates historically displayed the organization name in a green address bar, though most modern browsers no longer show this distinction visually. They remain common in financial institutions and high-security environments.

Avoid self-signed certificates in production

A self-signed certificate is one you create yourself without a CA. Browsers will display a full-page security warning because there is no trusted third party vouching for the certificate. Self-signed certificates are fine for local development but should never be used on public-facing websites. Free DV certificates from Let's Encrypt eliminate any cost barrier.

HSTS and Why It Must Accompany TLS #

HTTP Strict Transport Security (HSTS) is a response header that tells the browser to only connect to your site over HTTPS, even if the user types "http://" or clicks an HTTP link. Without HSTS, the very first request to your site might go over plain HTTP before your server can redirect it to HTTPS. That brief unencrypted moment is enough for an attacker on the same network to intercept or modify the traffic, a technique called an SSL stripping attack.

The HSTS header has three parameters. max-age sets how long (in seconds) the browser should remember to use HTTPS. A value of 31536000 (one year) is standard. includeSubDomains extends the policy to all subdomains. preload signals that you want your domain added to the HSTS preload list, a hardcoded list of HTTPS-only domains shipped with every browser. Once preloaded, browsers will never make an HTTP request to your domain, even on the very first visit.

Apache HSTS configuration

# Enable HSTS (add to .htaccess or VirtualHost block)
Header always set Strict-Transport-Security \
  "max-age=31536000; includeSubDomains; preload"

Nginx HSTS configuration

# Enable HSTS (add to server block)
add_header Strict-Transport-Security
  "max-age=31536000; includeSubDomains; preload" always;

Node.js / Express HSTS

app.use((req, res, next) => {
  res.setHeader(
    'Strict-Transport-Security',
    'max-age=31536000; includeSubDomains; preload'
  );
  next();
});

Read the full HSTS Generator Guide

Testing Your TLS Configuration #

After configuring TLS, verify that everything works as expected. A misconfigured certificate chain, an accidentally enabled legacy protocol, or a missing cipher suite can silently weaken your security without any visible error on the page.

Command Line with OpenSSL

The openssl command-line tool lets you inspect exactly which TLS version, cipher suite, and certificate your server is using. These commands work on macOS, Linux, and Windows (with Git Bash or WSL).

OpenSSL TLS testing commands

# Connect and show the negotiated protocol and cipher
openssl s_client -connect example.com:443 -tls1_3

# View the full certificate chain
openssl s_client -connect example.com:443 -showcerts

# Check certificate expiration date
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# Verify that TLS 1.0 and 1.1 are rejected
openssl s_client -connect example.com:443 -tls1    # Should fail
openssl s_client -connect example.com:443 -tls1_1  # Should fail

Browser Developer Tools

Every modern browser shows TLS connection details. In Chrome or Edge, open Developer Tools (F12), go to the Security tab, and click "View certificate" to see the full chain. Firefox shows similar information under the padlock icon in the address bar. Look for the protocol version (should say TLS 1.2 or 1.3), the cipher suite in use, and whether the certificate chain is complete.

Verify the padlock icon appears without warnings
Check the Security tab for protocol and cipher details
Look for mixed content warnings in the Console tab

Automated Scanning

Run a full scan on SiteSecurityScore to check your TLS configuration alongside all your security headers. Automated scans catch issues like deprecated protocol versions, weak cipher suites, missing HSTS headers, and incomplete certificate chains in a single report.

MDN: Transport Layer Security reference

TLS Server Configuration for Apache, Nginx, and Node.js #

These configurations disable legacy protocols, set strong cipher preferences, and enable forward secrecy. Adjust certificate paths to match your environment.

Apache (httpd.conf or ssl.conf)

# TLS configuration
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLCertificateFile      /etc/ssl/certs/example.com.crt
SSLCertificateKeyFile   /etc/ssl/private/example.com.key
SSLCertificateChainFile /etc/ssl/certs/chain.crt

Header always set Strict-Transport-Security \
  "max-age=31536000; includeSubDomains; preload"

Nginx (nginx.conf or site block)

# TLS configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
ssl_session_tickets off;

ssl_certificate     /etc/ssl/certs/example.com.crt;
ssl_certificate_key /etc/ssl/private/example.com.key;

add_header Strict-Transport-Security
  "max-age=31536000; includeSubDomains; preload" always;

Node.js / Express (with HTTPS module)

const https = require('https');
const fs = require('fs');
const express = require('express');

const app = express();

// HSTS middleware
app.use((req, res, next) => {
  res.setHeader(
    'Strict-Transport-Security',
    'max-age=31536000; includeSubDomains; preload'
  );
  next();
});

const options = {
  key: fs.readFileSync('/etc/ssl/private/example.com.key'),
  cert: fs.readFileSync('/etc/ssl/certs/example.com.crt'),
  ca: fs.readFileSync('/etc/ssl/certs/chain.crt'),
  minVersion: 'TLSv1.2',
  ciphers: [
    'ECDHE-ECDSA-AES128-GCM-SHA256',
    'ECDHE-RSA-AES128-GCM-SHA256',
    'ECDHE-ECDSA-AES256-GCM-SHA384',
    'ECDHE-RSA-AES256-GCM-SHA384'
  ].join(':')
};

https.createServer(options, app).listen(443);