Security requirements that break accessibility: 301 redirects to HTTPS
In recent years, partly due to the so called “Snowden effect”, a lot of sites have added HTTPS support, while most of them even made it mandatory. I believe this is largely a good thing because it enhances user privacy, but that it is implemented in such a way that it needlessly breaks backwards compatibility with older software (and therefore hardware that does not receive software updates anymore).
An average webhost listens on two ports: 80 for HTTP and 443 for HTTPS. Back in the day, a lot of websites did not implemented a HTTP 301 redirect from the :80 service to the :443 service, so the HTTPS Everywhere browser plugin was born which did this by using a list of websites that lacked this redirect. Since then, a lot of websites have implemented this redirect, making the plugin largely obsolete and is scheduled to be retired in 2022.
How can a website be implemented that is both secure for modern users and accessible for older software? The HTTP Strict Transport Security (HSTS) specification written in RFC6797 gives room for exceptions to not implement a 301 redirect and let the HTTP version still work:
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, such as status code 301
(Section 10.3.2 of [RFC2616]), and a Location header field value
containing either the HTTP request's original Effective Request URI
(see Section 9 ("Constructing an Effective Request URI")) altered as
necessary to have a URI scheme of "https", or a URI generated
according to local policy with a URI scheme of "https".
NOTE: The above behavior is a "SHOULD" rather than a "MUST" due to:
* Risks in server-side non-secure-to-secure redirects
[OWASP-TLSGuide].
* Site deployment characteristics. For example, a site that
incorporates third-party components may not behave correctly
when doing server-side non-secure-to-secure redirects in the
case of being accessed over non-secure transport but does
behave correctly when accessed uniformly over secure transport.
The latter is the case given an HSTS-capable UA that has
already noted the site as a Known HSTS Host (by whatever means,
e.g., prior interaction or UA configuration).
Implementing a website with HSTS without a 301 redirect works fine, but this gives a potential security regression on the first visit where the user is unaware of the existence of the HTTPS version (this is why HTTPSEverywhere was made).
What could be solution to this? HSTS pre-loading, so the HSTS entry is already in the browser storage before even loading the page. Except that it isn’t a solution.
Google, who is the author of the pre-loading list that is used in most browsers, requires the website to implement a redirect to HTTPS. In my view, this should not be required, because the browser is already aware that the site cannot use HTTP from the information in the pre-loading list. I suspect the reason they made this required is because the the browser then does not have to implement a redirect themselves as a special edge-case if the site does not provide the redirect. As long as this is the case, the only option that can work without making a security sarcifice for users with modern software is running separate hosts with an HTTP versions of the website. Or simply keep going on the current path and drop the support for old software. ¯\_(ツ)_/¯
Availability is also part of the CIA triad. Everything is a tradeoff. Users should be able to make the tradeoff for themselves as much as possible, regardless of the hardware and software they use. I think forcing HTTPS is fine for banking, but for most other stuff, people should be able to turn it off willingly.
I made http://retrowikipedia.org (only works on the desktop at the moment) some time ago as a fun proxy to use best encyclopdia on the web on older devices. Luckily the Wikimedia Foundation is blocking all edits through the IP range of my VPS provider, so I won’t be responsible for any vandalism.
And yes, HTTP can be wiretapped and specifically HTTP connections to Wikipedia too. Are you personally being a target of the NSA? The answer is most likely: no.
Some people have kept maintaining older versions of software, such as RetroZilla which is a fork of an old Gecko version that has TLS 1.2 which is widely supported on the web.