The naïve’s shackles cannot be undone.

2022-02-19, post № 255

web, #security, #hsts

Without the intend to trivialize the world of material possessions, possibly the novelty alone makes the many quirks and unseen effects which occur in the presence of information-centric conduct hard to grasp in its entirety. Most bizarrely, the concept of ownership admits only to a loose analogy: expected algorithmic runtimes to reproduce bit patterns. Yet if these expections are broken or systems otherwise circumvented, stolen goods are merely accurately replicated hunks of data; nothing ever gets moved or removed, only copied against the origin’s will. Still, the sig­nif­i­cance is akin to theft, only securing bits requires more than not losing them.

As such, it is no wonder that a tender technology like the web took a long and winded path before reaching present-day hardened cryptographic ubiquity. But the tolls of time and progress are plentiful: from the fundamentally inextensible to the obsolete and the undying facets kept alive through compatibility shims, one of such shims being HTTP-talking sockets whose only assignment is to appeal to the client’s senses and never to talk with them again, referring to their HTTPS comrades which are in control of the sought after pages.
Yet cannot the clients remember? Should the clients even seek port 80? What does it mean to support SSL? To enforce it? Answers to these questions are given by HSTS, yet it too has morphed over the years; and a server’s adherence is not certain.

What lead me to read RFC 6797 § 7.2 thoroughly was an inexplicably never-loading site required for authenticating internal network usage at my university: $ curl http://passwort.uni-tuebingen.de takes its sweet time until eventually timing out. Perplexed, I contacted support only to be instructed to connect securely, which leads to an STS header which instructs the browser not to attempt insecure connections in the future, one of the promises made by HSTS.

Inquiring further regarding the lack of an insecure redirect, my university expressed concerns regarding the possibility of a man-in-the-middle attack. On first glimpse such reasoning appears solid, as a bare HTTP request travels in plain text through the ISPs, unauthenticated and interceptable. Nevertheless, leaving port 80 dangling in no way benefits security and RFC 6797 advises an insecure redirect, if its wording lost vigor in the drafting phase.

Since I have seen one prominent StackOverflow answer discouraging such redirects [1] and further noticed sprinkled throughout forums a weary sentiment regarding them, combined with my local experience, I would like to quote the authoritative RFC which defines HSTS:

“If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a status code indicating a permanent redirect [...]” [2]

Although the recommendation was more prominently featured in an earlier draft [3], the endorsement remains. Under scrutiny, the unconditional hatred for HTTP does not hold up: it does not matter if an unsecured HTTP request is emitted by the client, possibly tampered with and ignored by the target server or possibly tampered with and redirected in plain text. The choice to forego a cryptographic channel is made the moment the client expects any kind of HTTP response: no server is capable to remedy ignorance, the best it can do is to suggest a superior protocol.


  1. L. Invernizzi: “Going from HTTP to HTTPS is actually a not-so-good idea.”. StackOverflow, 2014-06-26. Online: https://stackoverflow.com/a/6528138 [accessed 2022-02-19]
  2. J. Hodges, C. Jackson, A. Barth: “HTTP Strict Transport Security (HSTS)”. RFC 6797 § 7.2, November 2012.
  3. J. Hodges, C. Jackson, A. Barth: “HTTP Strict Transport Security (HSTS) draft-hodges-strict-transport-sec-02”. https://datatracker.ietf.org/doc/html/draft-hodges-strict-transport-sec-02#section-2.2, 11 July 2012.
Jonathan Frech's blog; built 2022/05/14 19:35:56 CEST