LFCA 99 🐧 HTTPS and TLS — How It Works - KandZ

Every time you visit a website that starts with https://, a handshake happens behind the scenes. It is fast — usually measured in milliseconds — and it is one of the most consequential exchanges in modern computing. The handshake authenticates the server, negotiates cryptographic algorithms, and establishes a shared secret key that encrypts everything that follows. This chapter covers what HTTPS is, how the TLS handshake works, and the cryptographic machinery that makes secure communication on the internet possible.

The LFCA exam places HTTPS and TLS under Security Fundamentals, which carries 14–16% of the total weight. TLS is the practical application of everything covered in the earlier security chapters: asymmetric encryption for key exchange, symmetric encryption for data, certificates for authentication, and hashing for integrity. It is the protocol that ties them all together.

Key point: HTTPS is not a different protocol from HTTP. It is HTTP running over a secure channel created by TLS. The TLS handshake happens first, before any HTTP request is sent. Once the handshake completes, the client and server share a symmetric session key, and every HTTP message is encrypted with that key. The web application developer does not need to think about encryption at all — the TLS layer handles it transparently.

Why HTTPS Exists

The original HTTP protocol was designed for a simpler internet. It sent every request and response in plaintext. Anyone on the network path — a coffee shop Wi-Fi operator, an internet service provider, a malicious actor — could read the traffic, modify it, or impersonate the server. HTTPS solves all three problems.

The eavesdropping problem. Without encryption, anyone who can see the network packets can read the content. Login credentials, session cookies, personal messages, and payment details are all exposed. HTTPS encrypts the entire HTTP conversation, so an eavesdropper sees only ciphertext.

The tampering problem. Without integrity protection, an attacker can modify the content in transit. They can inject malicious JavaScript into a page, alter the response from an API, or redirect the user to a different site. HTTPS uses message authentication codes to detect any modification. If a single byte changes, the receiver detects it and discards the message .

The impersonation problem. Without authentication, a client cannot know whether the server it is talking to is the real server or an attacker who has redirected the connection. HTTPS uses digital certificates to prove the server’s identity. The client verifies the certificate against a trusted certificate authority before trusting the connection .

The trade-off. HTTPS adds latency. The TLS handshake requires additional round trips before the first byte of application data is sent. Modern TLS versions (TLS 1.3) have reduced the handshake to a single round trip, and session resumption allows a returning client to skip most of the handshake entirely . The performance cost is now measured in tens of milliseconds, and the security benefit is substantial.

a. The TLS Handshake

The handshake is the negotiation that happens before any application data is exchanged. It has a defined sequence of messages. The exact sequence depends on the TLS version and the cipher suite, but the core steps are the same.

The ClientHello is the first message. The client sends the TLS versions it supports, the cipher suites it supports, a random value, and optionally a server name indication (SNI) to tell the server which domain it is trying to reach .

The ServerHello is the server’s response. The server selects the TLS version and cipher suite from the client’s list, and sends its own random value .

The Certificate message follows. The server sends its certificate, or a certificate chain, so the client can authenticate it. The certificate contains the server’s public key and the domain name it is valid for .

The ServerHelloDone message indicates that the server has finished its part of the initial negotiation .

The ClientKeyExchange message is where the client and server agree on a shared secret. In older cipher suites based on RSA, the client generates a pre-master secret, encrypts it with the server’s public key from the certificate, and sends it to the server. Only the server can decrypt it with its private key . In modern cipher suites based on Diffie-Hellman, the client sends its DH public key, and both sides compute the shared secret independently .

The ChangeCipherSpec message tells the other party that all subsequent messages will be encrypted with the negotiated session key .

The Finished message is the final verification. Each side sends a hash of the entire handshake transcript, encrypted with the session key. If the hash matches on the other side, the handshake is confirmed as successful and untampered .

Once the handshake completes, the client and server share a symmetric session key. Every application data message — the HTTP requests and responses — is encrypted with that key using AES or another symmetric algorithm .

b. Cipher Suites and Key Exchange

A cipher suite is the set of algorithms used for a TLS connection. It includes the key exchange algorithm, the authentication algorithm, the symmetric encryption algorithm, and the hash function .

The client sends a list of cipher suites it supports in the ClientHello. The server picks the strongest one that both sides support. This negotiation ensures compatibility while preferring the most secure option available .

The key exchange algorithm determines how the client and server agree on the shared secret. RSA key exchange uses the server’s public key to encrypt the pre-master secret. It is simple but does not provide forward secrecy — if the server’s private key is later compromised, all past sessions can be decrypted . Diffie-Hellman (including elliptic curve variants) allows both sides to compute the shared secret without ever transmitting it. It provides forward secrecy: a compromised private key does not compromise past session keys .

The symmetric encryption algorithm is used for the actual data. AES is the standard, with 128-bit or 256-bit keys. It is fast and secure . The hash function — SHA-256 or SHA-384 — is used for message authentication and the Finished message verification .

c. TLS Versions and Modern Improvements

TLS has evolved through several versions. SSL 2.0 and 3.0 are deprecated and should not be used. TLS 1.0 and 1.1 are also deprecated. TLS 1.2 remains widely supported and is still considered secure when configured with modern cipher suites . TLS 1.3 is the current version and includes several improvements.

TLS 1.3 reduces the handshake to a single round trip. The client sends its key share in the first message, so the server can compute the shared secret immediately. This cuts the latency of the handshake in half compared to TLS 1.2 .

TLS 1.3 also removes obsolete algorithms. RSA key exchange, CBC-mode ciphers, and other legacy features are gone. The cipher suites are simplified, and only forward-secret key exchanges are supported .

Session resumption allows a returning client to skip the full handshake. In TLS 1.2 and earlier, the server issued a session ID or session ticket. In TLS 1.3, a pre-shared key (PSK) is used. The client presents the PSK identity, and if the server accepts it, the handshake is abbreviated .

0-RTT data is a TLS 1.3 feature that allows the client to send application data in the first flight, before the handshake completes. This eliminates the round trip entirely for returning clients. The security properties are weaker — 0-RTT data is not forward-secret and can be replayed — so it is optional and should be used only for idempotent requests .

Complete Example Session

This session demonstrates the TLS handshake and certificate verification using OpenSSL.

# ============================================
# PART 1: CONNECT AND VIEW THE HANDSHAKE
# ============================================

openssl s_client -connect example.com:443 -tls1_3

# Output (abbreviated):
# CONNECTED(00000003)
# ---
# Certificate chain
#  0 s:CN = www.example.org
#    i:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
#  1 s:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
#    i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
# ---
# SSL handshake has read 3104 bytes and written 361 bytes
# Verification: OK
# ---
# New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
# Server public key is 2048 bit
# Secure Renegotiation IS NOT supported
# Compression: NONE
# Expansion: NONE
# No ALPN negotiated
# SSL-Session:
#     Protocol  : TLSv1.3
#     Cipher    : TLS_AES_256_GCM_SHA384
#     Session-ID:
#     Session-ID-ctx:
#     Resumption PSK:
#     PSK identity: None
#     PSK identity hint: None
#     Start Time: ...
#     Timeout   : 7200 (sec)
#     Verify return code: 0 (ok)

# The handshake is complete.
# The cipher suite is TLS_AES_256_GCM_SHA384.
# The protocol is TLSv1.3.
# The verification is OK.

# ============================================
# PART 2: FORCE TLS 1.2 AND COMPARE
# ============================================

openssl s_client -connect example.com:443 -tls1_2

# Output (abbreviated):
# New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
# Server public key is 2048 bit
# ...
# SSL-Session:
#     Protocol  : TLSv1.2
#     Cipher    : ECDHE-RSA-AES256-GCM-SHA384

# TLS 1.2 uses a different cipher suite.
# The key exchange is ECDHE (Elliptic Curve Diffie-Hellman).
# The symmetric encryption is AES-256-GCM.
# The hash is SHA-384.

# ============================================
# PART 3: VIEW THE CERTIFICATE
# ============================================

openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | \
  openssl x509 -noout -text

# The output shows the certificate details:
# Subject: CN = www.example.org
# Issuer: DigiCert TLS RSA SHA256 2020 CA1
# Validity: 2026-01-15 to 2027-01-14
# Public Key: RSA 2048-bit
# Subject Alternative Name: DNS:www.example.org, DNS:example.com

# ============================================
# PART 4: TEST THE TLS VERSION
# ============================================

openssl s_client -connect example.com:443 -tls1_3 2>&1 | grep "Protocol"

# Output:
#     Protocol  : TLSv1.3

# The server supports TLS 1.3.

# ============================================
# PART 5: CHECK THE CIPHER SUITE
# ============================================

openssl s_client -connect example.com:443 2>&1 | grep "Cipher"

# Output:
# New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

# The cipher suite is negotiated.

# ============================================
# PART 6: VERIFY THE CERTIFICATE CHAIN
# ============================================

openssl s_client -connect example.com:443 -verify_return_error

# Output:
# Verify return code: 0 (ok)

# The chain is valid.
# The certificate is signed by a trusted CA.

# ============================================
# PART 7: TEST A CERTIFICATE ERROR
# ============================================

openssl s_client -connect self-signed.badssl.com:443

# Output:
# Verify return code: 18 (self-signed certificate)

# The self-signed certificate is not trusted.
# The verification fails.

# ============================================
# PART 8: THE HANDSHAKE TIMING
# ============================================

time openssl s_client -connect example.com:443 </dev/null

# The time command shows how long the handshake takes.
# Modern TLS handshakes complete in tens of milliseconds.

# ============================================
# PART 9: THE SESSION RESUMPTION
# ============================================

# First connection
openssl s_client -connect example.com:443 -sess_out session.pem

# Second connection with resumption
openssl s_client -connect example.com:443 -sess_in session.pem

# The second connection is faster.
# The session is resumed with a PSK.
# The full handshake is skipped.

# ============================================
# PART 10: THE SUMMARY
# ============================================

# HTTPS = HTTP over TLS
# TLS handshake = authenticate + key exchange
# Certificate = server identity + public key
# Cipher suite = algorithms for the session
# Session key = symmetric key for the data
# TLS 1.3 = single round trip, forward secrecy

The ten parts cover connecting and viewing the handshake, forcing TLS 1.2, viewing the certificate, testing the TLS version, checking the cipher suite, verifying the certificate chain, testing a certificate error, the handshake timing, session resumption, and the summary.

Quick Reference

The TLS Handshake Steps

Step	Message	Purpose
1	ClientHello	Client proposes TLS versions and cipher suites
2	ServerHello	Server selects the version and cipher suite
3	Certificate	Server sends its certificate chain
4	ServerHelloDone	Server finishes its initial messages
5	ClientKeyExchange	Client and server agree on the shared secret
6	ChangeCipherSpec	Switch to encrypted communication
7	Finished	Verify the handshake transcript

The TLS Versions

Version	Status	Handshake
SSL 2.0	Deprecated	Broken
SSL 3.0	Deprecated	Broken (POODLE)
TLS 1.0	Deprecated	Legacy
TLS 1.1	Deprecated	Legacy
TLS 1.2	Supported	2 round trips
TLS 1.3	Current	1 round trip

The Key Exchange Methods

Method	Forward Secrecy	Notes
RSA	No	Deprecated in TLS 1.3
Diffie-Hellman	Yes	Standard for TLS 1.3
ECDHE	Yes	Elliptic curve variant

The OpenSSL Commands

Command	Purpose
`openssl s_client -connect host:443`	Connect and view the handshake
`openssl s_client -connect host:443 -showcerts`	View the certificate chain
`openssl s_client -connect host:443 -tls1_3`	Force TLS 1.3
`openssl s_client -connect host:443 -verify_return_error`	Abort on verification failure

Best Practices

✅ Do This:

# Use TLS 1.3 when possible
openssl s_client -connect example.com:443 -tls1_3                  # ✅

# Verify the certificate chain
openssl s_client -connect example.com:443 -verify_return_error      # ✅

# Use forward-secret cipher suites
# ECDHE or DHE key exchange provides forward secrecy                 # ✅

# Enable session resumption for performance
# Use session tickets or PSK                                         # ✅

❌ Don’t Do This:

# Don't use SSL 3.0 or TLS 1.0
# They are deprecated and vulnerable                                 # ❌

# Don't use RSA key exchange in TLS 1.3
# It is not supported                                                # ❌

# Don't use 0-RTT for non-idempotent requests
# 0-RTT data can be replayed                                         # ❌

# Don't ignore certificate errors
# They indicate a security problem                                   # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Certificate verification failed	Self-signed or expired	Use a CA-signed, valid certificate
Handshake slow	Full handshake every time	Enable session resumption
Cipher suite mismatch	Client and server have no common suite	Update the server or client
0-RTT replay	Non-idempotent request	Use 1-RTT for those requests
TLS version downgrade	Server only supports old versions	Upgrade the server

Real-World Examples

1. Connect to an HTTPS Site

openssl s_client -connect example.com:443

2. View the Certificate Chain

openssl s_client -connect example.com:443 -showcerts

3. Force TLS 1.3

openssl s_client -connect example.com:443 -tls1_3

4. Verify the Chain

openssl s_client -connect example.com:443 -verify_return_error

5. Check the Cipher Suite

openssl s_client -connect example.com:443 2>&1 | grep Cipher

6. Test a Bad Certificate

openssl s_client -connect self-signed.badssl.com:443

7. Session Resumption

openssl s_client -connect example.com:443 -sess_out session.pem

8. Resume a Session

openssl s_client -connect example.com:443 -sess_in session.pem

9. Check the Protocol

openssl s_client -connect example.com:443 2>&1 | grep Protocol

10. Time the Handshake

time openssl s_client -connect example.com:443 </dev/null

Visual

The TLS Handshake

┌──────────────────────────────────────────────┐
│  CLIENT                          SERVER      │
│    │                               │         │
│    │──── ClientHello ─────────────>│         │
│    │     (versions, ciphers,       │         │
│    │      random, SNI)             │         │
│    │                               │         │
│    │<─── ServerHello ──────────────│         │
│    │     (version, cipher,         │         │
│    │      random)                  │         │
│    │                               │         │
│    │<─── Certificate ──────────────│         │
│    │     (server cert + chain)     │         │
│    │                               │         │
│    │<─── ServerHelloDone ──────────│         │
│    │                               │         │
│    │──── ClientKeyExchange ───────>│         │
│    │     (pre-master secret or     │         │
│    │      DH public key)           │         │
│    │                               │         │
│    │──── ChangeCipherSpec ────────>│         │
│    │──── Finished ────────────────>│         │
│    │                               │         │
│    │<─── ChangeCipherSpec ─────────│         │
│    │<─── Finished ─────────────────│         │
│    │                               │         │
│    │<═══ Application Data ════════>│         │
│    │     (encrypted with session   │         │
│    │      key)                     │         │
│                                              │
└──────────────────────────────────────────────┘

The Certificate Verification

┌──────────────────────────────────────────────┐
│  CERTIFICATE CHAIN VALIDATION                │
│                                              │
│  Server Certificate                          │
│    └─ Signed by Intermediate CA              │
│       │                                      │
│       ▼                                      │
│  Intermediate CA Certificate                 │
│    └─ Signed by Root CA                      │
│       │                                      │
│       ▼                                      │
│  Root CA Certificate                         │
│    └─ In the trust store                     │
│    └─ Self-signed                            │
│                                              │
│  The client verifies each signature.         │
│  The root is trusted without question.       │
│                                              │
└──────────────────────────────────────────────┘

The Cipher Suite Components

┌──────────────────────────────────────────────┐
│  CIPHER SUITE                                │
│                                              │
│  Key Exchange:                               │
│    ECDHE, DHE, RSA                           │
│                                              │
│  Authentication:                             │
│    RSA, ECDSA                                │
│                                              │
│  Symmetric Encryption:                       │
│    AES-256-GCM, AES-128-GCM, ChaCha20        │
│                                              │
│  Hash:                                       │
│    SHA-256, SHA-384                          │
│                                              │
│  Example: TLS_AES_256_GCM_SHA384             │
│                                              │
└──────────────────────────────────────────────┘

The TLS Versions

┌──────────────────────────────────────────────┐
│  SSL 2.0 / 3.0                               │
│    └─ Deprecated, broken                     │
│                                              │
│  TLS 1.0 / 1.1                               │
│    └─ Deprecated                             │
│                                              │
│  TLS 1.2                                     │
│    └─ Supported, 2 round trips               │
│    └─ RSA and DH key exchange                │
│                                              │
│  TLS 1.3                                     │
│    └─ Current, 1 round trip                  │
│    └─ Forward secrecy only                   │
│    └─ Session resumption, 0-RTT              │
│                                              │
└──────────────────────────────────────────────┘

Summary

Item	Value
HTTPS	HTTP over TLS
TLS handshake	Authenticate + key exchange
ClientHello	Client proposes versions and ciphers
ServerHello	Server selects version and cipher
Certificate	Server’s identity and public key
ClientKeyExchange	Shared secret agreement
Finished	Handshake verification
Session key	Symmetric key for data encryption
TLS 1.3	Single round trip, forward secrecy
Session resumption	Skip full handshake for returning clients
0-RTT	Early data, weaker security

Key takeaways:

HTTPS is HTTP running over a TLS-encrypted channel. The TLS handshake happens first. Once it completes, the client and server share a symmetric session key, and every HTTP message is encrypted with that key .
The TLS handshake authenticates the server, negotiates algorithms, and establishes a shared secret. The client sends a ClientHello, the server responds with a ServerHello and its certificate, and the two sides agree on a session key .
The certificate binds the server’s public key to its domain name. The client verifies the certificate against a chain of trust that ends at a root CA in the trust store. If the certificate is valid, the client knows it is talking to the real server .
The cipher suite defines the algorithms used for the connection. It includes the key exchange, authentication, symmetric encryption, and hash algorithms. The client proposes a list, and the server selects the strongest mutually supported option .
TLS 1.3 is the current version and improves on TLS 1.2. It reduces the handshake to a single round trip, removes obsolete algorithms, and requires forward secrecy. Session resumption and 0-RTT further reduce latency for returning clients .
Forward secrecy protects past sessions. With Diffie-Hellman key exchange, a compromised server private key does not compromise the session keys of past connections. RSA key exchange does not provide this property and is removed in TLS 1.3 .
The handshake is transparent to the application. The web application developer does not write encryption code. The browser and server handle the handshake and the encryption. The application sends HTTP, and the TLS layer secures it.

Remember: HTTPS is HTTP wrapped in TLS. The handshake authenticates the server, negotiates the algorithms, and establishes a session key. The certificate proves the server’s identity. The cipher suite defines the cryptography. The session key encrypts the data. TLS 1.3 makes the handshake faster and more secure. The browser does the work. The application just sends HTTP.

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!