Find the TLS boundaries around HTTP

TLS protects one connection between peers; trace each termination point before reasoning about end-to-end visibility.

  • tls
  • security boundaries
  • intermediaries

TLS protects a connection between two peers

TLS provides confidentiality and integrity for records on a connection and authenticates the server according to the client’s trust and name checks. It does not hide HTTP from either TLS endpoint, prove that application content is safe, or authorize a user for a resource.

Browser == TLS connection A ==> CDN == TLS connection B ==> origin

Expected result: the CDN is an endpoint for both connections and can observe HTTP between them. Connection A does not cryptographically extend through the CDN to the origin.

Termination creates another hop

A reverse proxy, CDN, load balancer, or service mesh can terminate TLS and send a new HTTP request over another connection. The next hop can use TLS too, but it has its own peers, negotiation, certificate validation, and failure modes.

Ask “encrypted between which two systems?” rather than labelling an entire path encrypted or unencrypted. Inventory every termination point and who controls it.

The certificate answers a narrow identity question

During a typical HTTPS connection, the client checks that the presented certificate chains to a trusted authority and is valid for the requested host. That check does not prove DNS returned the intended infrastructure, that the application is uncompromised, or that an upstream proxy verified its own origin connection correctly.

Keep the observed hostname, selected address, certificate chain, TLS version, application protocol, and HTTP response as separate evidence.

HTTP versions negotiate at connection boundaries

TLS application-layer protocol negotiation can select HTTP/2. HTTP/3 uses QUIC, which incorporates TLS 1.3 into its transport handshake. A client-to-CDN hop can use HTTP/3 while the CDN-to-origin hop uses HTTP/1.1; the response fields do not by themselves reveal every upstream protocol.

Browser warnings are not HTTP statuses

If certificate or TLS negotiation fails before HTTP begins, there is no HTTP response status to diagnose. Treat a browser-generated error page separately from content returned by an origin with a 4xx or 5xx response.

Primary sources