WEB / WEB-05.05

HTTPS and the TLS termination chain

Browser HTTPS verifies one hop. Terminating CDNs and proxies establish new connections; HSTS and mixed content are distinct browser-local policies.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

TLS per hop

Initial context
The selected initial conditions are local state; no message arrival or application outcome has occurred yet.
Browser
http URL; HSTS active; request unsent
CDN
Hop-A ready; no HTTP message yet
Reverse proxy
No upstream request yet
Application
No request; application delivery none
HSTS local rewrite
The browser’s active HSTS entry for notes.example.org rewrites the http URL to https locally. Hop-A verification is supplied as valid; GET /notes is ready but has not reached the CDN.
Browser
GET /notes ready; hop-A verification valid
CDN
Hop-A ready; no HTTP message yet
Reverse proxy
No upstream request yet
Application
No request; application delivery none
HTTPS request at CDN
The hop-A protected request arrived at the CDN; it is the TLS endpoint and can read the HTTP plaintext in its own process.
Browser
GET /notes ready; hop-A verification valid
CDN
GET /notes received; plaintext readable at CDN
Reverse proxy
No upstream request yet
Application
No request; application delivery none
Gate for a new peer
The CDN uses successful path, reference-identity and private-key-proof predicates for proxy.example.org. It prepares GET /notes in the separate hop-B context; the reverse proxy has not received it.
Browser
GET /notes ready; hop-A verification valid
CDN
Hop-B verified; GET /notes ready
Reverse proxy
No upstream request yet
Application
No request; application delivery none
Request arrived at proxy
The request in the new hop-B context arrived at the reverse proxy; it can read plaintext at its own termination boundary.
Browser
GET /notes ready; hop-A verification valid
CDN
Hop-B verified; GET /notes ready
Reverse proxy
GET /notes received; plaintext readable at proxy
Application
No request; application delivery none
Application hop selected
The reverse proxy uses successful verification for the separate TLS peer app.example.org and prepares GET /notes in hop-C. The browser-hop key is not used on this connection.
Browser
GET /notes ready; hop-A verification valid
CDN
Hop-B verified; GET /notes ready
Reverse proxy
GET /notes ready; hop-C TLS verified
Application
No request; application delivery none
Request at application
Normal GET /notes arrived at the application over hop-C HTTPS; user authorization and the response outcome remain unmodeled.
Browser
GET /notes ready; hop-A verification valid
CDN
Hop-B verified; GET /notes ready
Reverse proxy
GET /notes ready; hop-C TLS verified
Application
Request received; transport=https; response none

HTTP upstream

Initial context
The selected initial conditions are local state; no message arrival or application outcome has occurred yet.
Browser
http URL; HSTS active; request unsent
CDN
Hop-A ready; no HTTP message yet
Reverse proxy
No upstream request yet
Application
No request; application delivery none
HSTS local rewrite
The browser’s active HSTS entry for notes.example.org rewrites the http URL to https locally. Hop-A verification is supplied as valid; GET /notes is ready but has not reached the CDN.
Browser
GET /notes ready; hop-A verification valid
CDN
Hop-A ready; no HTTP message yet
Reverse proxy
No upstream request yet
Application
No request; application delivery none
HTTPS request at CDN
The hop-A protected request arrived at the CDN; it is the TLS endpoint and can read the HTTP plaintext in its own process.
Browser
GET /notes ready; hop-A verification valid
CDN
GET /notes received; plaintext readable at CDN
Reverse proxy
No upstream request yet
Application
No request; application delivery none
Gate for a new peer
The CDN uses successful path, reference-identity and private-key-proof predicates for proxy.example.org. It prepares GET /notes in the separate hop-B context; the reverse proxy has not received it.
Browser
GET /notes ready; hop-A verification valid
CDN
Hop-B verified; GET /notes ready
Reverse proxy
No upstream request yet
Application
No request; application delivery none
Request arrived at proxy
The request in the new hop-B context arrived at the reverse proxy; it can read plaintext at its own termination boundary.
Browser
GET /notes ready; hop-A verification valid
CDN
Hop-B verified; GET /notes ready
Reverse proxy
GET /notes received; plaintext readable at proxy
Application
No request; application delivery none
Application hop selected
The reverse proxy selects HTTP plaintext for the final hop and prepares GET /notes. The browser’s HTTPS scheme remains unchanged; this server-side hop is not a browser mixed-content request.
Browser
GET /notes ready; hop-A verification valid
CDN
Hop-B verified; GET /notes ready
Reverse proxy
GET /notes ready; hop-C HTTP, no TLS
Application
No request; application delivery none
Request at application
Normal GET /notes arrived at the application over HTTP without TLS protection; user authorization and the response outcome remain unmodeled.
Browser
GET /notes ready; hop-A verification valid
CDN
Hop-B verified; GET /notes ready
Reverse proxy
GET /notes ready; hop-C HTTP, no TLS
Application
Request received; transport=http; response none

Upstream name fails

Initial context
The selected initial conditions are local state; no message arrival or application outcome has occurred yet.
Browser
http URL; HSTS active; request unsent
CDN
Hop-A ready; no HTTP message yet
Reverse proxy
No upstream request yet
Application
No request; application delivery none
Browser peer verified
The browser selects a valid notes.example.org TLS peer; that result is not evidence for the next-hop proxy certificate.
Browser
Hop-A verified; HTTPS request ready
CDN
Hop-A ready; no HTTP message yet
Reverse proxy
No upstream request yet
Application
No request; application delivery none
Request arrived at CDN
The normal protected request arrived at the CDN; no upstream request has been sent to the reverse proxy yet.
Browser
Hop-A verified; HTTPS request ready
CDN
GET /notes received; upstream unsent
Reverse proxy
No upstream request yet
Application
No request; application delivery none
Upstream name gate closed
Even with a declared valid upstream path, hostname matching is selected false; the CDN does not send the message to the next hop.
Browser
Hop-A verified; HTTPS request ready
CDN
Upstream hostname=false; gate closed; forwarded=false
Reverse proxy
No upstream request yet
Application
No request; application delivery none
Failure stays local
Reverse-proxy and application receipt states did not change; this trace does not draw TLS handshake wire messages or a browser response.
Browser
Hop-A verified; HTTPS request ready
CDN
Upstream verification failed; request stops at CDN
Reverse proxy
No upstream request yet
Application
No request; application delivery none

Script blocked

Initial context
The selected initial conditions are local state; no message arrival or application outcome has occurred yet.
Browser
Secure document; http script; request unsent
CDN
No asset request; idle
Reverse proxy
No request; idle
Application
No request; idle
Subresource context
The selected secure document requests the script http://assets.example.org/main.js; no extra CSP upgrade or prior asset HSTS policy applies.
Browser
Destination script; default mixed policy
CDN
No asset request; idle
Reverse proxy
No request; idle
Application
No request; idle
Default block decision
A script is outside the upgradeable image/audio/video category; the default secure-document profile blocks the request locally.
Browser
Blocked; networkSent=false
CDN
No asset request; idle
Reverse proxy
No request; idle
Application
No request; idle
No arrival occurred
The CDN and later actors remain idle; no server response, script receipt, or script execution outcome is produced.
Browser
Mixed request stopped locally; response none
CDN
No asset request; idle
Reverse proxy
No request; idle
Application
No request; idle

ACTORS · STATE · DATA FLOW

Between which two peers is HTTPS protected?

Atlas Notes opens at https://notes.example.org. The browser verifies its TLS peer for the service identity in the URL and protects HTTP data on that connection. The endpoint may be a CDN; a valid certificate held by an authorized CDN does not make the backend application a peer of the same TLS connection. Origin authority and a physical server program are different concepts.

The selected chain is Browser → CDN → Reverse proxy → Application. Each arrow is an independent connection. The CDN is a server on its incoming connection and a client on the next one; the reverse proxy changes roles similarly. Certificate path, hostname reference, private-key proof, and traffic-key scope are therefore assessed per hop. Successful browser verification proves conditions for the first hop, not every later connection.

Termination exposes plaintext to an endpoint

TLS termination verifies an incoming protected record and makes its HTTP message readable at the endpoint. The CDN can read headers and body there; caching and routing operate on that content. A terminator’s plaintext access is an expected architectural trust boundary, not an integrity failure. If content must remain secret from the CDN, drawing another TLS arrow alone does not solve that requirement; application confidentiality needs a separate design.

When the CDN establishes TLS on the next hop, it does not copy the original ciphertext forward as the same protection context. It needs verification for a new peer, new keying material, and a new record context. The artifact’s three-hop ledger distinguishes aliases hop-A, hop-B, and hop-C; none are actual key bytes. Each TLS hop protects network data between its own endpoints, while every terminating endpoint can read the data.

The browser does not see an HTTP upstream choice

The normal case uses TLS on all three hops. In the plaintext-upstream case the final Reverse proxy → Application hop uses HTTP while Browser → CDN remains HTTPS. The browser sees the https scheme of its own resource fetch; it does not classify a backend network segment as mixed content. Confidentiality and peer authentication on that server-side HTTP hop do not come from TLS. Calling it an internal network does not automatically supply those guarantees.

In a third branch, the CDN’s reference hostname for the reverse proxy fails to match the presented certificate identity. The CDN stops before sending the upstream request at its own TLS-client verification gate. This local failure cannot change the reverse proxy’s request-received state. Earlier successful browser verification cannot override the gate. The model uses selected outcomes rather than running DNS, certificate parsing, or TLS negotiation.

HSTS changes the URL before the request is sent

HSTS is a browser cache policy keyed by domain name. A Strict-Transport-Security header received over error-free HTTPS records the host for max-age; a header received over insecure HTTP is ignored. Before loading an http URL for a known host, the browser changes it to https. Explicit port 80 becomes 443; other explicit ports remain unchanged. This is a local URL change before a network request, not a redirect waiting for a server’s 301 response. For a known HSTS host, a certificate or secure-transport error must stop the connection; browser policy does not offer a warning bypass to accept an insecure connection.

includeSubDomains extends scope to descendant domains, not parents or siblings. Expiry is refreshed as receipt time + max-age. max-age=0 removes that host’s dynamic entry without automatically deleting independent subdomain entries. A first visit without a known policy is not yet protected by dynamic HSTS; browser preload lists are a separately distributed source of policy. Adding the word preload to a header does not prove list inclusion. HSTS does not change a CDN’s HTTP upstream choice.

Mixed content is a separate resource request

An http script URL inside an HTTPS document describes a second, insecure browser resource request. Under the selected modern standard profile, blockable requests such as scripts and fetch/XHR are stopped by default policy. Certain ordinary image, audio, and video requests can be upgraded to an https URL; image-set/srcset/picture context and IP-address hosts prevent extending that outcome to every image. CORS approval is a separate policy; a mixed-content URL upgrade does not prove it succeeds. The old passive-safe versus active-dangerous shorthand does not replace the current algorithm.

Upgrading to HTTPS does not prove the resource loads successfully: the new URL still needs a suitable server and certificate. This profile does not draw failed upgrade as successful HTTP fallback. An insecure top-level navigation is a different category, so not every http link is the same mixed-content request. The artifact distinguishes blocked script, upgraded ordinary image, blocked IP-host image, and already-HTTPS cases through context inputs. Real browser overrides, CSP upgrade policy, and the complete Fetch algorithm are outside this small table.

Read every scenario without motion

Plaintext hop

The browser verifies one specific peer
The browser verifies the CDN for https://notes.example.org/notes. hop-A is not one end-to-end TLS connection with hop-B/hop-C; public HTTPS does not describe every upstream hop.
Public-URL evidence
Browser→CDN / hop-A
Per-hop gate
No hop gate
Plaintext-scope review
No data-copy scope
Each hop has its own verifier
plaintext-upstream supplies hopSchemes=[https, https, http]. The last connection lacks hop-C TLS protection; no browser certificate failure follows.
Public-URL evidence
Browser→CDN / hop-A
Per-hop gate
Hop-C plaintext / edge HTTPS valid
Plaintext-scope review
No data-copy scope
Plaintext readers were included in scope
termination.plaintextReaders lists Browser, CDN, Reverse proxy, Application. Even TLS on every network hop lets selected terminators read the body; wire secrecy is not endpoint secrecy.
Public-URL evidence
Browser→CDN / hop-A
Per-hop gate
Hop-C plaintext / edge HTTPS valid
Plaintext-scope review
CDN/proxy/app can read plaintext
A scheme string is not channel evidence
An external https URL does not make a direct internal connection HTTPS. Trusted forwarding of an edge’s scheme and upstream reference-identity checks require separate policy and evidence.
Public-URL evidence
External scheme / internal channel separate
Per-hop gate
Hop-C plaintext / edge HTTPS valid
Plaintext-scope review
CDN/proxy/app can read plaintext
Browser policy does not repair upstream protection
HSTS has upstreamProtectionChanged=false. A plaintext server-to-server hop may have browserMixedContent=false; absence of a mixed-content warning does not prove internal TLS.
Public-URL evidence
External scheme / internal channel separate
Per-hop gate
HSTS/mixed content ≠ upstream TLS
Plaintext-scope review
CDN/proxy/app can read plaintext
The transport-boundary outcome remained explicit
RequestDeliveredToApplication=true belongs to the supplied path only; the last plaintext hop is explicitly classified. Confidentiality/log/retention policy for each copy needs separate review.
Public-URL evidence
External scheme / internal channel separate
Per-hop gate
HSTS/mixed content ≠ upstream TLS
Plaintext-scope review
Plaintext boundary identified

Upstream name

The browser verifies one specific peer
The browser verifies the CDN for https://notes.example.org/notes. hop-A is not one end-to-end TLS connection with hop-B/hop-C; public HTTPS does not describe every upstream hop.
Public-URL evidence
Browser→CDN / hop-A
Per-hop gate
No hop gate
Plaintext-scope review
No data-copy scope
Each hop has its own verifier
upstream-name-fail supplies hopIdentityAccepted=[true, false, null]. When the CDN gate for proxy.example.org closes, the request is not deemed delivered to the reverse proxy.
Public-URL evidence
Browser→CDN / hop-A
Per-hop gate
Hop-B rejected / downstream pending
Plaintext-scope review
No data-copy scope
The request reached only the earlier endpoint
The browser and CDN have access to this request. Failed hostname verification for proxy.example.org prevents the CDN from sending it to the reverse proxy; the application does not receive it either. The general plaintextReaders list describes endpoint capability, not delivery evidence in this failed branch.
Public-URL evidence
Browser→CDN / hop-A
Per-hop gate
Hop-B rejected / downstream pending
Plaintext-scope review
Request only at Browser/CDN; no downstream
A scheme string is not channel evidence
An external https URL does not make a direct internal connection HTTPS. Trusted forwarding of an edge’s scheme and upstream reference-identity checks require separate policy and evidence.
Public-URL evidence
External scheme / internal channel separate
Per-hop gate
Hop-B rejected / downstream pending
Plaintext-scope review
Request only at Browser/CDN; no downstream
HSTS does not open the failed hop
HSTS upstreamProtectionChanged=false records that browser policy does not change server-hop verification. In this branch, hop-B hostname verification fails and hop-C is never evaluated. Plaintext-upstream is a separate comparison; this failed branch gets no HTTP delivery.
Public-URL evidence
External scheme / internal channel separate
Per-hop gate
Hop-B hostname failed; hop-C not evaluated
Plaintext-scope review
Request only at Browser/CDN; no downstream
The transport-boundary outcome remained explicit
RequestDeliveredToApplication=false and downstream identity null remain. No delivery or application effect is added beyond the failed hop.
Public-URL evidence
External scheme / internal channel separate
Per-hop gate
Hop-B hostname failed; hop-C not evaluated
Plaintext-scope review
Hop failure / application not reached

ASSUMPTION · BOUNDARY · CONTROL

The trusted endpoints behind the lock

A risk review needs to state that the CDN verified by the browser can read the body. TLS confidentiality protects against network observers, not against the selected peer. TLS on hop-B and hop-C does not hide plaintext from the CDN or reverse proxy. More trusted processors enlarge secret handling, log policy, and retention scope; TLS success is not a business-trust decision.

The selected plaintext-upstream branch shows a conditional control difference: the final network hop has no TLS record protection. It does not demonstrate a failure of the browser content scheme or certificate. Ask about the correct boundary: which network segment, endpoint, and data copy? This prevents overlooking a server-side transport gap while waiting for a browser mixed-content warning.

A scheme label is not channel evidence

An application can know its external URL uses https while its direct connection uses HTTP. In a normal termination architecture, transporting the approved edge’s external-scheme context is a separate design problem. Merely seeing the string https proves neither internal certificate verification nor protection of the body on the final hop.

The reverse is also true: backend TLS does not prove the browser service identity was correct. In the selected upstream-name-fail branch the CDN gate closes and the request never reaches the reverse proxy. The failure must remain local. Naming each hop’s verifier, reference identity, and protection conditions makes the missing assumption concrete instead of relying on “TLS exists somewhere.”

The different scopes of HSTS and mixed content

HSTS depends on prior knowledge of a host policy; a dynamic entry cannot retroactively protect the first insecure request. Mixed-content policy instead considers the subresource context of a secure document. Treating HSTS as encryption of every server-to-server hop, or mixed-content checks as a blanket ban on every insecure link, incorrectly combines different controls.

A blocked script row means no request is sent; it does not mean a server response arrived or content was sanitized. An upgraded image row means a URL rewrite, not successful image decoding. Preserve the source context and normal failure boundary without conflating a local decision with data delivery or application impact.

Read every scenario without motion

HSTS scope

Policy receipt and lifetime were read together
The HSTS policy arrives over error-free HTTPS at t=1000. A 600-second max-age gives expiry 1600. It is active at t=1300 and expired at t=1600; this example has no preload.
Browser-policy evidence
Dynamic HSTS / 1000+600=1600
Host/request classification
No scope calculation
Observation and coverage
No review outcome
Host and port scope was calculated
includeSubDomains covers img.notes.example.org but not other.example.org or example.org. Explicit port 80 becomes port 443, while custom port 8080 remains. The policy does not cover the entire domain tree.
Browser-policy evidence
Dynamic HSTS / 1000+600=1600
Host/request classification
Subdomain label / 80→443 / 8080 kept
Observation and coverage
No review outcome
Policy depends on secure receipt
receivedOverErrorFreeHttps=true is a prerequisite for this entry. Seeing the same header over insecure HTTP creates no dynamic HSTS entry. With preloaded=false, this example’s decision depends only on the supplied dynamic entry.
Browser-policy evidence
Secure receipt supplied; no preload
Host/request classification
Subdomain label / 80→443 / 8080 kept
Observation and coverage
Policy source: dynamic entry
At expiry, no rewrite applies
The same notes.example.org URL is rewritten at t=1300; at t=1600 the expired entry supplies no dynamic-policy rewrite. That latter result measures neither actual HTTP transmission nor absence of other preload or policy mechanisms.
Browser-policy evidence
Expiry 1600; comparison 1300 / 1600
Host/request classification
Dynamic rewrite: active / expired
Observation and coverage
Sending and receipt unobserved
The browser policy entry produces the evidence
An actual review needs the browser’s host entry, secure receipt, includeSubDomains and evaluation time. A header sample alone does not prove that cache state exists. The supplied table explains scope calculations without measuring a browser cache or version behavior.
Browser-policy evidence
Expiry 1600; comparison 1300 / 1600
Host/request classification
Dynamic rewrite: active / expired
Observation and coverage
Producer: browser policy state; limited coverage
Rewriting is not upstream protection
Browser rewriting is a local URL decision before loading. CDN and reverse-proxy TLS identity checks, and the final HTTP-hop choice, require evidence from other producers. This HSTS table produces no request-delivery, response or pixel outcome.
Browser-policy evidence
Expiry 1600; comparison 1300 / 1600
Host/request classification
Dynamic rewrite: active / expired
Observation and coverage
HSTS scope known; upstream separate

Mixed context

A secure document requests a resource
mixedProfile selects a secure document and default policy, with no CSP upgrade, prior resource-host HSTS or top-level navigation. Browser evaluation uses destination and initiator as well as the URL.
Browser-policy evidence
Secure document; default policy
Host/request classification
Destination/initiator not yet classified
Observation and coverage
No network/render outcome
The HTTP script is blocked locally
For http://assets.example.org/main.js, destination and initiator are script. It is not upgradeable and is blocked by the selected default policy. This local decision is neither server receipt nor content sanitization.
Browser-policy evidence
HTTP script; secure initiator
Host/request classification
Blocked; request not sent
Observation and coverage
No response or execution
A hostname image gets a URL rewrite
The separate http://assets.example.org/cover.png image row, without an imageset initiator, gives upgraded-url-only. Its URL changes to HTTPS; the row measures no server, certificate, response or image-decoding success.
Browser-policy evidence
Comparison: ordinary hostname image
Host/request classification
HTTPS URL upgrade; load unknown
Observation and coverage
Delivery and pixels need separate evidence
Imageset and IP hosts differ
An imageset-initiated hostname image and the IP-host image at 192.0.2.10 are blocked in this profile. “Every image is upgraded” misses both negative rows. The already-HTTPS script needs no mixed-scheme decision; loading remains a separate outcome.
Browser-policy evidence
Imageset / IP-host / HTTPS rows
Host/request classification
Blocked / blocked / already-https
Observation and coverage
Load outcome not supplied
Fetch-policy evidence is matched to the request
An actual browser review needs secure Document context, resource URL, destination, initiator and policy together. Separate the local block/upgrade result from a network record; missing network evidence alone proves no block cause without coverage and instrumentation context.
Browser-policy evidence
Imageset / IP-host / HTTPS rows
Host/request classification
Each resource is classified in its own context
Observation and coverage
Producer: browser Fetch policy; coverage required
A policy result is not pixel success
Script and ineligible-image rows block transmission; the ordinary-image row establishes only URL upgrade. Sending, response receipt and rendering are separate stages. This selected policy table is neither browser-compatibility evidence nor an image-decoding result.
Browser-policy evidence
Selected resource rows reviewed
Host/request classification
Block / upgrade / HTTPS distinguished
Observation and coverage
Policy scope known; render unmeasured

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Keep a ledger for each hop

The Atlas ledger has separate columns for client, server, scheme, reference identity, certificate-check outcome, and key alias. Normally the CDN is the browser’s server for notes.example.org and a TLS client for proxy.example.org. The reverse proxy is another client for app.example.org. Because the selected certificate profile authenticates servers only, it does not claim upstream client identity verification; mTLS would add separate certificate and policy conditions.

Actual server identity verification matters as much as enabling TLS. Do not reduce disabled trust-anchor, hostname, or private-key-proof checks to an “encrypted” success. Inventory a plaintext hop explicitly and record the data and network boundary rationale. A positive TLS network property does not replace endpoint secret policy.

Verify browser policy state separately

HSTS evidence needs more than a header string: secure receipt, matching host scope, and an unexpired cache entry. The fixture computes expiry as 1000+600=1600; it is active at now=1300 and expired at now=1600. Label boundaries, sibling and parent exclusions, explicit port-80 conversion, and preservation of custom ports are meaningful regression points for includeSubDomains.

The fixture’s preload state is false. A production policy requires a separate assessment of HTTPS readiness for all affected subdomains; no browser-list submission or domain change is performed here. Preserve the nuance that max-age=0 removes only its own dynamic entry. The HSTS local-rewrite scene changes Browser state without a wire transfer, followed by arrival of an ordinary HTTPS request at the CDN.

Classify subresources with their actual contexts

Mixed-content review needs request destination and initiator as well as a URL list. Document scheme, image versus imageset, host type, and the selected CORS mode affect the result. Blocking an http script under a secure document’s default policy is the outcome for this case, which has no extra policy such as CSP upgrade-insecure-requests. If an additional policy is introduced, reassess upgrade/block ordering with current Fetch integration.

Keep network sending, response receipt, and content rendering as separate evidence. In the blocked-script case the CDN must remain idle; an ordinary image’s local https rewrite must not claim the new request completed successfully. Do not label this deterministic standard-profile table a browser compatibility result without testing actual versions and overrides separately.

NOW APPLY IT TO THE CASE

What do browser HTTPS, upstream TLS and subresource policy protect separately?

The browser’s TLS peer is the CDN serving notes. Other hops verify the reverse proxy and application; the final hop may use HTTP. HSTS and mixed-content policy do not automatically protect that server-side boundary.

Who is the peer of the case’s secure connection? Explain TLS peer trust, browser origin and user object permission as separate decisions.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Atlas · HTTPS and the TLS termination chain

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profile": {
    "transport": "selected HTTP over TLS 1.3 or HTTP plaintext hop",
    "actualNetworkRun": false,
    "certificateBytesPresent": false
  },
  "request": {
    "method": "GET",
    "publicUrl": "https://notes.example.org/notes",
    "body": null
  },
  "hops": [
    {
      "client": "Browser",
      "server": "CDN",
      "scheme": "https",
      "referenceIdentity": "notes.example.org",
      "pathValidSelected": true,
      "hostnameValidSelected": true,
      "privateKeyProofValidSelected": true,
      "trafficKeyAlias": "hop-A",
      "clientCertificateRequested": false
    },
    {
      "client": "CDN",
      "server": "Reverse proxy",
      "scheme": "https",
      "referenceIdentity": "proxy.example.org",
      "pathValidSelected": true,
      "hostnameValidSelected": true,
      "privateKeyProofValidSelected": true,
      "trafficKeyAlias": "hop-B",
      "clientCertificateRequested": false
    },
    {
      "client": "Reverse proxy",
      "server": "Application",
      "scheme": "https",
      "referenceIdentity": "app.example.org",
      "pathValidSelected": true,
      "hostnameValidSelected": true,
      "privateKeyProofValidSelected": true,
      "trafficKeyAlias": "hop-C",
      "clientCertificateRequested": false
    }
  ],
  "termination": {
    "plaintextReaders": [
      "Browser",
      "CDN",
      "Reverse proxy",
      "Application"
    ],
    "endToEndSingleTlsConnection": false,
    "independentTrafficContexts": [
      "hop-A",
      "hop-B",
      "hop-C"
    ]
  },
  "cases": [
    {
      "case": "normal",
      "hopSchemes": [
        "https",
        "https",
        "https"
      ],
      "hopIdentityAccepted": [
        true,
        true,
        true
      ],
      "requestDeliveredToApplication": true,
      "browserMixedContent": false
    },
    {
      "case": "plaintext-upstream",
      "hopSchemes": [
        "https",
        "https",
        "http"
      ],
      "hopIdentityAccepted": [
        true,
        true,
        null
      ],
      "requestDeliveredToApplication": true,
      "browserMixedContent": false
    },
    {
      "case": "upstream-name-fail",
      "hopSchemes": [
        "https",
        "https",
        "https"
      ],
      "hopIdentityAccepted": [
        true,
        false,
        null
      ],
      "requestDeliveredToApplication": false,
      "browserMixedContent": false
    },
    {
      "case": "mixed-script",
      "hopSchemes": [],
      "hopIdentityAccepted": [],
      "requestDeliveredToApplication": false,
      "browserMixedContent": true
    }
  ],
  "hsts": {
    "host": "notes.example.org",
    "receivedOverErrorFreeHttps": true,
    "receiptSeconds": 1000,
    "maxAgeSeconds": 600,
    "expirySeconds": 1600,
    "includeSubDomains": true,
    "preloaded": false,
    "upstreamProtectionChanged": false
  },
  "hstsCases": [
    {
      "url": "http://notes.example.org/notes",
      "now": 1300,
      "expected": "https://notes.example.org/notes"
    },
    {
      "url": "http://img.notes.example.org/p.png",
      "now": 1300,
      "expected": "https://img.notes.example.org/p.png"
    },
    {
      "url": "http://notes.example.org:80/notes",
      "now": 1300,
      "expected": "https://notes.example.org:443/notes"
    },
    {
      "url": "http://notes.example.org:8080/notes",
      "now": 1300,
      "expected": "https://notes.example.org:8080/notes"
    },
    {
      "url": "http://other.example.org/notes",
      "now": 1300,
      "expected": "http://other.example.org/notes"
    },
    {
      "url": "http://example.org/notes",
      "now": 1300,
      "expected": "http://example.org/notes"
    },
    {
      "url": "http://notes.example.org/notes",
      "now": 1600,
      "expected": "http://notes.example.org/notes"
    }
  ],
  "mixedProfile": {
    "documentSecure": true,
    "defaultUserPolicy": true,
    "cspUpgradeSelected": false,
    "noPriorHstsForResourceHost": true,
    "topLevelNavigation": false,
    "potentiallyTrustworthyLoopbackSelected": false
  },
  "mixedCases": [
    {
      "destination": "script",
      "initiator": "script",
      "url": "http://assets.example.org/main.js",
      "cors": false,
      "expected": "blocked"
    },
    {
      "destination": "image",
      "initiator": "",
      "url": "http://assets.example.org/cover.png",
      "cors": false,
      "expected": "upgraded-url-only"
    },
    {
      "destination": "image",
      "initiator": "imageset",
      "url": "http://assets.example.org/cover.png",
      "cors": false,
      "expected": "blocked"
    },
    {
      "destination": "image",
      "initiator": "",
      "url": "http://192.0.2.10/cover.png",
      "cors": false,
      "expected": "blocked"
    },
    {
      "destination": "script",
      "initiator": "script",
      "url": "https://assets.example.org/main.js",
      "cors": false,
      "expected": "already-https"
    }
  ]
}

hops: Independent peers, reference identities, and key contexts; no secret bytes.
hstsCases: Cached dynamic policy changes the local URL according to host, expiry, and port.
mixedCases: Destination and initiator distinguish outcomes under the default secure-document profile.

Hop verification outcomes are declared conditions. No actual certificates, connections, or browser cache; HSTS and mixed-content tables compute a bounded selected standard profile. No response/render outcome is manufactured.

Two reality checks

Browser HTTPS implies one TLS connection all the way to the application.

A terminating endpoint can read plaintext; an upstream hop is another connection and verification context.

HSTS makes every server hop use TLS.

HSTS is a cached browser host policy; it does not control backend transport selection.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Browser→CDN uses HTTPS, but proxy→application uses HTTP. Does browser HSTS turn the upstream hop into TLS?

No; upstream protection is separate hop policy.
Yes; HTTPS in the browser encrypts the entire server chain.

Read the explained answer

No; upstream protection is separate hop policy. — HSTS changes the browser scheme decision for a known host; it does not transform the proxy upstream channel.

If every hop uses HTTPS, is the CDN unable to read the body?

Selected lesson artifact fields; teaching example

termination.plaintextReaders: ["Browser","CDN","Reverse proxy","Application"]
termination.endToEndSingleTlsConnection: false

The CDN is a reader; there is no single end-to-end TLS connection.
Because every hop is HTTPS, only Browser and Application see plaintext.

Read the explained answer

The CDN is a reader; there is no single end-to-end TLS connection. — In the normal selected chain, the CDN is a TLS endpoint and belongs to plaintextReaders.

An HTTP script in a secure document is blocked, while an HTTP image is upgraded-url-only. Why is this not successful loading of all mixed content?

Read the explained answer

The selected default policy blocks the script and upgrades an eligible image URL to HTTPS. imageset and IP-host image branches differ. An upgraded URL is not an observation of successful fetch, TLS or decoding; mixed-content policy also does not cover server-side upstream hops.

□ I preserved the image/script/initiator distinction.

□ I did not equate rewriting with loading success.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

HTTP Semantics3.3 Connections, Clients, and Servers; 3.7 Intermediaries · 4.2.2 https; 4.3.4 Certificate Verification · 7.4 Rejecting Misdirected Requests · 7.6.1 Connection; 7.6.3 Via; 7.7 Message Transformations · 9.3.6 CONNECT
The Transport Layer Security (TLS) Protocol Version 1.31.2 Relationship to RFC8446 · 2.2 Resumption and PSK; 2.3 0-RTT · 4.3.9 PSK key exchange modes; 4.3.11 Pre-shared key · 4.7.1 New Session Ticket · 7.1 Key Schedule; 7.4.2 ECDH · 8 0-RTT and Anti-Replay; F.5
Service Identity in TLS6.1.1 independently constructed reference identifiers · 6.3 DNS-ID matching; 7.7 Certificate Trust
HTTP Strict Transport Security (HSTS)6.1 Strict-Transport-Security syntax · 8.1 Header Processing; 8.1.1 Storage · 8.2 Domain Name Matching; 8.3 URI Loading and Port Mapping · 8.4 Errors in Secure Transport Establishment
Strict-Transport-Security headerDescription; Expiration; Subdomains · Insecure HTTP requests; Preloading Strict Transport Security
Mixed Content3.1 Upgradeable Content; 3.2 Blockable Content · 4.1 Upgrade a mixed content request · 4.4 Should fetching request be blocked; 4.5 response check
Fetch Standard4.1 Main fetch, mixed-content upgrade and block hooks

YOUR NOTES / THIS BROWSER

HTTPS and the TLS termination chain

1. Core · Mechanism

TLS per hop

HTTP upstream

Upstream name fails

Script blocked

Between which two peers is HTTPS protected?

Termination exposes plaintext to an endpoint

The browser does not see an HTTP upstream choice

HSTS changes the URL before the request is sent

Mixed content is a separate resource request

2. Red · Trust & Impact

Plaintext hop

Upstream name

The trusted endpoints behind the lock

A scheme label is not channel evidence

The different scopes of HSTS and mixed content

3. Blue · Secure development & defense

HSTS scope

Mixed context

Keep a ledger for each hop

Verify browser policy state separately

Classify subresources with their actual contexts

What do browser HTTPS, upstream TLS and subresource policy protect separately?

Two reality checks

Browser→CDN uses HTTPS, but proxy→application uses HTTP. Does browser HSTS turn the upstream hop into TLS?

If every hop uses HTTPS, is the CDN unable to read the body?

An HTTP script in a secure document is blocked, while an HTTP image is upgraded-url-only. Why is this not successful loading of all mixed content?

Sources and scope