skip to content

On a Known HSTS Host, why must a browser terminate the connection on any secure transport error, with no user override?

level: seniorimportance: should knowfreq 45%

answer

  1. no severity threshold at all
  2. warning and fatal treated alike
  3. terminate is required, recourse is advised
  4. the error-causer is the excluded party
  5. covered name fails closed, no workaround

basics

~20 s

Because the party able to produce the error is the party the policy exists to exclude. RFC 6797 requires termination on any secure transport error at any severity, and advises browsers to offer no way to proceed, so the click-through that would restore the attack is gone.

solid answer

~50 s

A stored HSTS policy claims something stronger than "this site offers TLS": it claims that reaching this name any other way is not possible from this browser. RFC 6797 makes that real with a hard rule — on a Known HSTS Host, **any** error with the underlying secure transport, at **any** severity including a mere warning, requires the browser to terminate the connection. The specification's implementation advice then says the failure should be presented with no user recourse, and that is what conforming browsers do. The reasoning is that an attacker positioned to force the error is exactly the attacker the policy excludes; if a user can accept it, the policy buys nothing, because users accept whatever stands between them and the page. The operational price is real: on a covered name, a secure transport failure is an outage with no workaround for anyone.

go deeper

for a junior

Recall the observable behaviour: on a name the browser holds a policy for, a transport error is a dead end rather than a warning you can accept.

for a middle

Explain that the rule covers errors at every severity, not just fatal ones, and say why a dismissible warning would leave the attack fully open.

for a senior

Demonstrate the operating consequence: a covered name whose secure transport breaks is unreachable for everyone, and the fix has to happen on the host because no policy change can be delivered meanwhile.

for a principal

Frame it as accepting a fail-closed posture across every name a policy covers, and decide what monitoring and ownership must exist before that posture is acceptable.

## The rule, stated precisely Two things are often merged into one sentence, and separating them is what a senior answer sounds like. - **Termination is required.** On a Known HSTS Host, if there is **any** error with the underlying secure transport — whether classed as a warning, as fatal, or at any other level — the browser **MUST** terminate the connection. There is no severity threshold and no category of error that is treated as advisory. - **No user recourse is advised.** The same specification's implementation guidance says such a failure should be presented without an option to proceed: not a dialog offering to continue, but something closer to how an outright failure is reported. That part is guidance rather than a protocol requirement, and conforming browsers follow it. So "a browser must terminate, and is advised to give the user no way past it" is accurate; "the specification forbids a click-through" is a little stronger than the text. In an interview, making that distinction is worth more than the rule itself, because it shows you read specifications as written rather than as remembered. ## Why a click-through would empty the policy Work through who can actually cause the error. An attacker on the path who wants to read a parent's session has two routes. The first is to keep the connection on plaintext — which is what the stored policy removes, since no plaintext request is ever built. The second is to terminate the secure connection themselves, which produces an error at the browser. If that error can be waived by a click, the second route is open again, and it is open specifically to the attacker, because a legitimate host that has deployed the policy has every reason to keep its secure transport working. The population matters too. A user staring at a warning between themselves and their child's report card will accept it. That is not a failing of the user; it is what a modal standing in front of a goal does. So a warning that can be dismissed is, in effect, an attack that always succeeds, and the specification's answer is to remove the dismissal rather than improve the wording. ## What this changes operationally This is the rule that turns HSTS from a header into a commitment. - **A secure transport failure on a covered name is a full outage.** No visitor can get to the page, not even one who understands the risk and accepts it. There is no per-user workaround to suggest to a support caller. - **The blast radius follows the entry, not the deployment.** If the entry asserted `includeSubDomains`, every name in the tree inherits both the protection and the terminal-failure behaviour, including names whose secure transport nobody is watching. - **The clock is on the browser, not on the host.** Even after the underlying problem is fixed, nothing needs to be re-sent: the policy was never the problem. But while it is broken, the host cannot tell browsers to stand down, because a policy change has to arrive over a working secure connection. In a school district this lands somewhere specific: the portal is fine, because someone owns it; the old school sites under the same parent domain are the risk, because their secure transport is nobody's job. Asserting a tree-wide policy converts every one of those into a name that fails closed. ## What the rule does not say Two boundaries matter for a precise answer: 1. **It is not a statement about which checks a browser performs.** Validity, chain construction and revocation are a separate subject with their own owners. HSTS references the *outcome* — "any error with the secure transport" — and says what to do about it. Name the rule, not the machinery. 2. **It does not make an untrusted connection trusted, or an error benign.** It removes the option to ignore one. A browser without a stored entry for the name behaves as it always did, which is why the very first visit to an unknown host is still the weak point. ## The interview version A good answer has three beats: what the rule is (terminate on any error at any severity, with no recourse offered), why it exists (the party able to cause the error is the party being excluded, and users dismiss warnings), and what it costs (a covered name that breaks its secure transport is unreachable, with no user-side escape hatch). Candidates who only know the first beat usually cannot explain why it is not simply an over-strict browser behaviour.

  • Is the no-click-through behaviour a protocol requirement or implementation advice?
    Terminating the connection on any secure transport error is required. Presenting that failure with no way for the user to proceed is stated as implementation advice in the same specification, and conforming browsers follow it. Promoting the advice to a requirement is a small inaccuracy, but it is the kind an interviewer notices, because it signals whether you read the text or repeated a summary of it.
  • Does a warning-level transport error get treated more leniently on a Known HSTS Host?
    No. The rule is explicit that any error at any level — warning, fatal, or otherwise — requires termination. There is no severity threshold to tune. That is deliberate: an attacker chooses which failure to induce, so any category left as merely advisory becomes the one they use.
  • Can a policy expressed in markup put a host into this state?
    No. A policy delivered through an `http-equiv="Strict-Transport-Security"` attribute must not be heeded, so it creates no entry and nothing about connection handling changes. The policy is a response header field carried over a secure connection, or it does not exist — which also means a document cannot commit a name simply by containing the right element.

saying these in an interview costs you the question

  • Thinks only fatal errors terminate and warnings are shown.
  • Says the specification bans any error interface at all.
  • Believes a knowledgeable user should be allowed to proceed anyway.
  • Assumes the host can lift the policy while its secure transport is broken.
  • Treats the rule as a browser quirk rather than the policy's whole point.