Summary

  • A site could send Strict-Transport-Security over an error-free HTTPS connection, instructing a browser to use secure transport on later contacts. RFC 6797 identified the first HTTP visit to a site the browser did not yet know as a bootstrap attack window.
  • Chromium's June 2011 announcement described built-in HTTPS treatment for Gmail's initial navigation. The 2012 RFC described a browser vendor's preloaded HSTS list as one way to close that first-visit window for selected sites.

The rule arrived with the response

In 2008, Collin Jackson and Adam Barth proposed ForceHTTPS. Their paper gave a site or a user a way to tell a browser that HTTPS errors should stop the visit. The prototype Firefox extension redirected non-HTTPS connections, rejected certificate errors and blocked insecure embedded content. The authors were wrestling with a browser habit: compatibility made broken security look negotiable. Their proposed rule made the site's stricter intent legible to the browser.

The later HSTS standard, RFC 6797, made the timing problem explicit. A site could send a Strict-Transport-Security response field over a secure connection. The browser would then remember the host and upgrade future requests for the policy's max-age. If the field arrived over insecure HTTP, the browser had to ignore it. Letting an unprotected connection create or erase the rule would give the attacker control of the safety instruction.

That left the very first visit. A person could type a domain, or follow an http link, before the browser had learned a policy for it. RFC 6797 called this the bootstrap man-in-the-middle vulnerability. The website's instruction was waiting on the far side of the trip it was supposed to protect. A later redirect could not move the first request backward in time.

The browser packed a list before it left home

In June 2011, the Chromium Security Team described two ways to set the browser's prior knowledge. Chromium 12 let advanced users force HTTPS for chosen domains through its network settings. For Chromium 13, the team said all Gmail connections would use HTTPS, including an initial navigation when someone typed gmail.com or mail.google.com without a scheme. It also described certificate errors that users could not click past for those sensitive domains. This was a browser implementation claim, dated before the final HSTS RFC.

RFC 6797's Section 12.3 later described a preloaded list: site administrators could have a browser vendor ship HSTS policy for their sites in the software itself. Chromium's own HSTS documentation explains the remaining window for a fresh installation or cleared local state, then says its list gives selected domains protection out of the box. A site still chose to operate HTTPS and request strict treatment. The browser vendor chose which prior rules to distribute. That second choice determined whether the first request for a listed site could start in cleartext.

The allocation of power is plain. A response header let the site address browsers that had already reached it safely. A preloaded list let the browser act before the site could speak. It also made the list publisher a gatekeeper for first-visit protection. An archived Chromium 13 list and first-visit traffic measurements would show which domains and users actually received that protection; the dated announcement and RFC establish the mechanism and the decision point. The browser's box went out with a rule inside it.

Sources