How HTTPS Works: TLS Handshake and Encryption Explained for Beginners

When you visit a website and see the padlock icon in your browser address bar, you are using HTTPS. HTTPS is not a separate protocol from HTTP. It is HTTP running over a secure layer called TLS (Transport Layer Security). Understanding how HTTPS works is essential for every developer who builds or consumes web applications, APIs, or any networked service.

This article explains what HTTPS is, why it exists, how the TLS handshake establishes a secure connection, the role of certificates, encryption, and common misconceptions. By the end, you will understand the internal process that protects almost every secure interaction on the modern internet.

What Is HTTPS?

HTTPS stands for Hypertext Transfer Protocol Secure. It is the standard protocol for secure communication between a web browser (or any HTTP client) and a web server.

At its core, HTTPS is simply HTTP data wrapped inside an encrypted TLS tunnel. The browser and server still exchange the same HTTP methods, headers, and body content. The difference is that everything traveling over the network is encrypted and authenticated.

HTTP alone sends data in plain text. Anyone on the network path (a public Wi-Fi router, an ISP, a compromised router) can read passwords, session tokens, personal data, or API keys. HTTPS prevents that by providing three critical guarantees:

• Confidentiality — Data cannot be read by eavesdroppers.
• Integrity — Data cannot be modified without detection.
• Authentication — The client can verify it is talking to the legitimate server.

These properties are provided by the TLS protocol (formerly called SSL). TLS runs on top of TCP and below the application layer (HTTP).

Why Developers Should Understand HTTPS

Every modern web application relies on HTTPS. APIs use HTTPS. Authentication flows depend on it. Cookies marked Secure only travel over HTTPS. Mixed content warnings appear when a secure page tries to load insecure resources. Certificate errors break production deployments.

Understanding the internal mechanics helps you:

• Debug certificate and handshake failures
• Choose correct TLS versions and cipher suites
• Implement secure cookies, HSTS, and certificate pinning
• Design systems that terminate TLS correctly (load balancers, reverse proxies)
• Avoid common security mistakes such as leaking sensitive data over HTTP redirects

HTTPS is not optional infrastructure. It is part of the application surface you must reason about.

Simple Explanation of How HTTPS Works

Think of a normal HTTP connection as sending a postcard. Anyone who handles the postcard can read it. HTTPS is like putting that postcard inside a locked, tamper-evident envelope that only the intended recipient can open, and the envelope itself proves the sender’s identity.

The process has two main phases:

1. Establish a secure channel (the TLS handshake).
2. Exchange application data (HTTP requests and responses) over that encrypted channel.

The handshake happens once (or is resumed efficiently) at the beginning of a connection. After the handshake succeeds, the browser and server share secret session keys. All subsequent traffic is encrypted with those keys using fast symmetric cryptography.

The entire handshake and key agreement happens in a few hundred milliseconds or less on modern connections.

How It Works Internally: The TLS Handshake

A TLS handshake occurs after a TCP connection has already been established (the classic three-way handshake). TLS then negotiates the secure parameters.

Modern browsers and servers primarily use TLS 1.3. TLS 1.2 is still widely supported for compatibility, but TLS 1.3 is faster and more secure. We will focus on the conceptual flow that applies to both, noting key differences.

High-Level Architecture

Client (Browser)
       |
       | 1. TCP connection (port 443)
       v
Server
       |
       | 2. TLS Handshake
       |    - Agree on version & ciphers
       |    - Authenticate server (certificate)
       |    - Establish shared session keys
       v
Encrypted HTTP traffic

Step-by-Step TLS Handshake (TLS 1.3 Focus)

1. ClientHello

The client initiates the handshake. It sends:

• Supported TLS versions (preferably 1.3)
• List of supported cipher suites
• A random value (Client Random)
• Key share information for Diffie-Hellman key exchange (in TLS 1.3 this happens early)
• Extensions such as Server Name Indication (SNI) so the server knows which certificate to present for virtual hosting, and Application-Layer Protocol Negotiation (ALPN) for HTTP/2 or HTTP/3

In TLS 1.3 the client sends its key share immediately, allowing the server to begin key computation right away.

2. ServerHello

The server responds with:

• The chosen TLS version
• The selected cipher suite
• Its own random value (Server Random)
• Its key share
• The server’s certificate (or certificate chain)

At this point both sides can compute the shared secret using the Diffie-Hellman key exchange (usually ECDHE — Elliptic Curve Diffie-Hellman Ephemeral).

3. Authentication and Finished Messages

The server proves ownership of the private key corresponding to the public key in its certificate by signing a portion of the handshake (CertificateVerify). The client verifies:

• The certificate is issued by a trusted Certificate Authority (CA)
• The certificate has not expired or been revoked
• The domain name matches the certificate (hostname verification)
• The signature is valid

Both sides then send Finished messages that contain a cryptographic hash of the entire handshake transcript. This confirms that neither side has been tampered with and that both calculated the same keys.

4. Application Data

From this point forward, all traffic is encrypted using the derived session keys (symmetric encryption such as AES-GCM). The HTTP request is sent inside the encrypted TLS records.

In TLS 1.3 the handshake is more efficient: it typically requires only one round trip after the TCP connection, and many messages are encrypted earlier than in TLS 1.2.

Key Components

• Certificates — Digital documents that bind a domain name to a public key, signed by a trusted CA.
• Public / Private Key Pairs — Asymmetric cryptography used only during the handshake for authentication and key exchange.
• Session Keys — Symmetric keys derived for the actual data encryption. They are ephemeral (generated per connection or resumed carefully).
• Cipher Suites — Named combinations of algorithms for key exchange, bulk encryption, and message authentication.
• Perfect Forward Secrecy (PFS) — Because ephemeral Diffie-Hellman is used, compromising the server’s long-term private key later does not allow decryption of past recorded sessions.

Certificates and Trust

A TLS certificate is issued by a Certificate Authority after the CA verifies that the requester controls the domain (via DNS, HTTP challenge, or other methods). The certificate contains:

• The domain name (or wildcard / SAN list)
• The public key
• Validity period
• Issuer information
• Digital signature from the CA

Browsers and operating systems ship with a set of trusted root CA certificates. When a server presents its certificate (and intermediate certificates), the client builds a chain of trust back to a root CA it already trusts.

If the chain is broken, the certificate is expired, the hostname does not match, or the certificate has been revoked, the browser shows a security warning and usually refuses to proceed.

Real-World Examples

Visiting a website

You type https://example.com. The browser performs DNS resolution, opens a TCP connection to port 443, completes the TLS handshake, then sends the HTTP GET request over the encrypted channel. The response (HTML, CSS, JS) travels back encrypted.

API calls

A mobile app or backend service calling an HTTPS API follows the same process. Libraries such as fetch, axios, or curl handle the TLS details, but certificate validation still occurs. Self-signed certificates or missing intermediate certificates cause connection failures.

Load balancers and reverse proxies

In production, TLS is often terminated at a load balancer or CDN edge. The edge holds the certificate and private key, performs the handshake with clients, then forwards traffic (sometimes re-encrypted, sometimes plain) to origin servers. Understanding where TLS terminates is critical for security and debugging.

Certificate renewal

Let’s Encrypt and other ACME-based CAs allow automated issuance and renewal. Tools such as certbot or cloud provider managed certificates handle the challenge and installation so that certificates do not expire and break sites.

Code Example: Observing HTTPS in Practice

You can inspect the TLS details of a connection using OpenSSL from the command line:

openssl s_client -connect example.com:443 -servername example.com

This shows the certificate chain, the negotiated TLS version, the cipher suite, and more. Looking at the output helps debug certificate problems and confirm modern protocols are in use.

In application code (Node.js example), the https module or fetch uses the system trust store by default:

const https = require('https');

https.get('https://example.com', (res) => {
  console.log('Status:', res.statusCode);
  // The TLS handshake already succeeded before this callback
}).on('error', (err) => {
  console.error('TLS or network error:', err.message);
});

Most high-level libraries hide the handshake, but understanding what happens underneath helps when errors surface (UNABLE_TO_VERIFY_LEAF_SIGNATURE, CERTIFICATE_VERIFY_FAILED, etc.).

Common Misconceptions

• “HTTPS encrypts the URL path and query string completely from everyone.” The domain name is visible via SNI (and in DNS). The path and query are encrypted after the handshake, but the hostname itself is often observable.
• “A green padlock means the site is completely safe.” It only means the connection is encrypted and the certificate is valid for that domain. It does not guarantee the site itself is free of malware, phishing, or poor application security.
• “Self-signed certificates are fine for production.” They provide encryption but not authentication trusted by browsers. Users will see warnings. They are useful only for internal testing with explicit trust configuration.
• “TLS 1.0 / 1.1 are still okay.” They are deprecated and insecure. Modern browsers have disabled them. Always prefer TLS 1.2+ and ideally TLS 1.3.
• “Once HTTPS is enabled, all security problems are solved.” HTTPS protects data in transit. Application-level issues (XSS, CSRF, insecure session handling, SQL injection) remain the developer’s responsibility.

Best Practices and Key Takeaways

• Always serve production traffic over HTTPS. Redirect HTTP to HTTPS permanently (301) and consider HSTS headers.
• Use modern TLS versions (1.2 and 1.3). Disable older protocols and weak ciphers.
• Obtain certificates from trusted CAs. Prefer automated issuance (Let’s Encrypt, cloud-managed certificates).
• Include intermediate certificates in the chain so clients can validate the full path.
• Monitor certificate expiration. Automated renewal is essential.
• Understand where TLS is terminated in your architecture (CDN, load balancer, application server).
• For APIs and internal services, still use HTTPS or mutually authenticated TLS (mTLS) when appropriate.
• Test with tools such as SSL Labs server test or openssl s_client to verify configuration.

HTTPS is the foundation of trust on the web. The combination of certificates, asymmetric cryptography for authentication and key exchange, and fast symmetric encryption for data provides confidentiality, integrity, and authenticity at internet scale.

FAQ

What is the difference between HTTP and HTTPS?
HTTP sends data in plain text. HTTPS is HTTP over TLS, so the same HTTP messages travel inside an encrypted and authenticated tunnel.

What is a TLS handshake?
It is the initial negotiation between client and server that agrees on protocol version, cipher suite, authenticates the server via its certificate, and establishes shared session keys used for encryption.

Why does the padlock appear in the browser?
The padlock indicates that the connection used a valid TLS certificate for the domain and that the data is encrypted. It does not guarantee the site content is trustworthy.

What is a cipher suite?
A named combination of algorithms that define how keys are exchanged, how data is encrypted, and how messages are authenticated.

What is Perfect Forward Secrecy?
It means that even if the server’s long-term private key is later compromised, past recorded sessions cannot be decrypted because ephemeral keys were used for each connection.

Can HTTPS be intercepted?
With a trusted certificate it is extremely difficult. Corporate proxies or malware that install their own root certificates can perform man-in-the-middle interception, which is why trusting only official CAs is important.

What port does HTTPS use?
By default, TCP port 443. HTTP uses port 80.

Is TLS the same as SSL?
SSL is the older name. TLS is the modern standardized protocol. People still say “SSL certificate” colloquially, but the protocol in use is TLS.

Related Articles

• How HTTP Works
• How DNS Works
• What Happens When You Type a URL in Your Browser
• How Cookies and Sessions Work
• How Authentication Works

Understanding HTTPS gives you a solid foundation for every secure web technology that follows. The next time you see the padlock, you will know exactly what sequence of cryptographic steps made that secure connection possible.