liveBook · Manning

HTTPS

As explained in Grokking Web Application Security

HTTPS is HTTP protected by Transport Layer Security for authenticated and encrypted communication.

HTTPS protects HTTP traffic with Transport Layer Security (TLS). It encrypts data moving between a browser or other client and a server, helping prevent an interceptor from reading it. It also authenticates the destination and detects unexpected changes to traffic, so the browser can establish that it is talking to the intended site. section 3.3 section 7.1

The browser’s padlock represents an HTTPS connection, not a guarantee that every part of an application is safe. TLS starts with a handshake in which client and server negotiate a cipher suite: key exchange establishes keys, authentication verifies the destination, bulk encryption protects traffic efficiently, and a message authentication code detects altered packets. section 3.3

A digital certificate connects a public key to a domain or IP address. Browsers trust certificates issued by recognized certificate authorities and warn about an unrecognized signer, such as a self-signed certificate. Deploying HTTPS means obtaining a certificate, hosting it with the application, and replacing or revoking it when it expires or its private key may be compromised. section 3.3 section 3.4

Treat HTTPS as an application-wide requirement:

  • Redirect HTTP traffic to HTTPS, but mark sensitive cookies Secure so a browser never sends them on the initial insecure request. section 2.12
  • Send all session traffic over HTTPS and configure session cookies with Secure; add HttpOnly as well to reduce cookie theft through injected JavaScript. section 9.6 section 2.13
  • Use HSTS to require HTTPS, require a current minimum TLS version to resist downgrade attacks, and maintain a scripted certificate revocation and reissuance process. section 7.13
  • When server-side code fetches a supplied URL, require HTTPS with a valid certificate, reject nonstandard ports and IP-address hosts, and still restrict reachable internal servers. section 14.4

Keep a session cookie off HTTP

Without Secure, a browser can attach a session cookie to an HTTP request before a redirect reaches HTTPS, allowing an attacker who intercepts that request to steal it. Set Secure so the cookie travels only on HTTPS; pair it with HttpOnly when JavaScript does not need cookie access. section 2.12 section 2.13

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: session_id=9264be3c7df125; Secure     #1

The Set-Cookie header shows the Secure attribute that tells a browser to send the session cookie only with HTTPS requests. section 2.12

How Grokking Web Application Security covers it

How deep it goes
Explains TLS handshake roles and certificate trust, while deferring TLS internals and hosting-specific certificate-management details.
Examples
Uses Secure and HttpOnly Set-Cookie headers, a Wi-Fi session-hijacking demonstration, and Python validation of HTTPS URLs.
What it assumes
Introduces HTTPS from plain HTTP traffic and TLS terminology without requiring knowledge of TLS internals.
What you can do after
Operate/configure it by deploying certificates, enforcing HTTPS-only traffic, securing cookies, validating outbound URLs, and responding to certificate compromise.
How it connects
Connects TLS, digital certificates, certificate authorities, Secure cookies, HttpOnly cookies, HSTS, and session hijacking.

Also explained in

Compare how 7 books explain HTTPS →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Grokking Web Application Security. The section links point to the parts of the book it draws on.