Networking and Protocols

HTTPS

HTTP layered on top of TLS to provide encryption and authentication in transit.

Where you will see it: Shows up in packet captures, network diagrams, firewall rules, and system or network logs.

What it is

HTTPS means HTTP over TLS. The browser first establishes a TLS session with the server, then sends normal HTTP requests inside that encrypted tunnel. To the application, it still looks like HTTP.

Key points
  • Adds confidentiality and integrity to web traffic on untrusted networks.
  • Depends on correct certificate validation and hostname checks.
  • Does not make a vulnerable web app safe, it only protects data in transit.

How it works in broad strokes

  1. The client resolves the hostname, then opens a connection to the server's HTTPS port.
  2. A TLS handshake occurs: the server presents a certificate, the client validates it and the hostname, and both sides derive shared keys.
  3. Once the handshake completes, all HTTP bytes are encrypted inside TLS records.
  4. The client sends an HTTP request and receives an HTTP response, just like with HTTP, but intermediaries cannot read or change the payload without terminating TLS.
  5. Modern setups negotiate protocol versions like HTTP/2 using ALPN during the TLS handshake.
  6. Connections can be reused, and sessions can be resumed to speed up later visits.
  7. Security headers like HSTS can force future connections to use HTTPS and reduce downgrade risk.

Concrete example

On public WiFi, an attacker can read and modify HTTP traffic. With HTTPS, the attacker still sees that you connected to a bank's IP, but cannot read your passwords or swap the page content without triggering certificate errors.

Why it matters

Plain HTTP exposes everything to the network, including cookies and credentials, and allows active attackers to modify responses. HTTPS exists to make the web safe to use on shared networks and across the public Internet.

Security angle

  • The security of HTTPS rests on certificate issuance and validation. Automate renewals and monitor for misissued certs.
  • Use modern TLS configurations and disable legacy versions where possible.
  • If you terminate TLS, protect the internal network too. Otherwise you create an unencrypted gap inside your environment.

Common pitfalls

  • Treating certificate warnings as ignorable. They often indicate interception or misconfiguration.
  • Mixed content: loading some resources over HTTP defeats the security promise.
  • TLS termination at a load balancer can hide the real client IP and change trust boundaries.
  • Assuming encryption hides metadata. DNS, IP addresses, and sometimes SNI can still reveal where you connect.
  • Believing HTTPS replaces application security. It does not prevent XSS, SQL injection, or broken auth logic.

DEEP DIVE

▾

The full stack: name to content

When you load an HTTPS site, several layers cooperate. First DNS maps the hostname to an IP address. Then the client establishes a TCP connection to the server, usually to port 443. Next the TLS handshake runs to authenticate the server and derive encryption keys. Only after TLS is established does the client send the HTTP request.

This layering is why you can diagnose failures by stage. A DNS failure means you never got an IP. A TCP failure means you could not reach the host and port. A TLS failure means the server identity or cryptographic negotiation failed. An HTTP failure means the secure channel exists but the application returned an error or unexpected content.

In packet captures, HTTPS looks like a TLS handshake followed by encrypted application data. You can usually see the server name via SNI during the handshake, but you cannot see URLs, headers, or bodies after encryption begins.

Server authentication and certificate validation

The defining feature of HTTPS is authentication. The browser does not just encrypt. It checks that the server certificate matches the hostname in the URL and chains to a trusted root certificate authority. If those checks fail, the browser warns you because encryption alone without identity would not stop man in the middle attacks.

Certificate chains are common points of failure. A server must present the right intermediate certificates. The certificate must not be expired or revoked by policy. The hostname must match, including subdomain rules. Misconfigurations here can cause a site to work in one browser but fail in another depending on trust store details.

Modern deployments also use features like OCSP stapling, certificate transparency logs, and automated renewal. These reduce the risk of silent compromise, but they add moving parts that can break if not monitored.

Browser security policies that ride on HTTPS

Once a site is HTTPS, browsers enable stronger protections. Secure cookies can be marked so they are only sent over HTTPS. Mixed content rules block or warn when an HTTPS page tries to load scripts over plain HTTP because that would reintroduce tampering risk.

HSTS is another key policy. It tells the browser to always use HTTPS for a domain, even if the user types HTTP. This prevents downgrade attacks where an attacker tries to keep you on an insecure version of the site.

From a security engineering standpoint, HTTPS is the baseline. Many modern web APIs and features are restricted to secure contexts, which is essentially a synonym for being served over HTTPS.

Performance in the real world

HTTPS adds handshake cost, but modern TLS has reduced it. TLS 1.3 usually completes in one round trip, and session resumption can reduce repeat visits further. Connection reuse means the cost is amortized across many requests.

CDNs often terminate TLS at the edge, which shortens the path and improves latency. The secure connection from your browser ends at the CDN, and the CDN then connects to the origin using its own security settings. This is still secure, but it changes where certificates live and where logs and controls apply.

If a site feels slow, measure whether the delay is in DNS, TCP, TLS, or the server response. Many people blame TLS for slowness when the real issue is server processing time or a congested network.