riscos.info enables HSTS

I’ve enabled HTTP Strict Transport Security on riscos.info, as an attempt to improve the security by encouraging users’ browsers to use HTTPS without affecting RISC OS users who can’t use it. I also fixed a broken TLS certificate, so it should be good for everyone to use HTTPS if they can. It’s looking OK from my end, but I’d appreciate some feedback – especially from those with RISC OS browsers, either those that do or don’t do HTTPS.

So what I’d like you to do is follow these steps in order, telling me what browser you have:

1. Visit http://www.riscos.info – do you end up at http or https?
2. Visit https://www.riscos.info – you should stay there
3. Visit http://www.riscos.info – do you end up at http or https?
4. Visit http://riscos.info – do you end up at http or https?
5. Does the site still work for you? Can you browse wiki pages, etc?
6. Do you see any glitches: certificate warnings, your browser complaining the page isn’t secure, etc?

HSTS is currently only active for an hour, so after that time your browser should forget the HSTS history if you leave it longer than that.

Thanks!

1 and 3 both went to HTTP for me (tested about 15 minutes ago, so within the 1-hour cutoff). 2 and 4 went to HTTPS. 5 untested, but no warnings from 6.

Now for the “but”… this is on my work PC, so who knows what crazy things it’s doing. Browser is the latest SeaMonkey, which is effectively Firefox with a different UI.

Mac Safari 11.1 Initial attempt at (1) gives error “Safari can’t open the page ‘https://www.riscos.info/index.php/RISC_OS’ because Safari can’t load any data from this location’”. A second attempt loads the page. All four access without other issues but the secure icon doesn’t appear for any though the address shown is https for all.

RISC OS NetSurf CI #4321 loads all four as HTTP without issues.

Firefox on Windows: 1 gives me http, 2-4 give me https. Nothing obviously broken.

NetSurf 3.7 on RISC OS: 1-4 give me http. For #2, it looks like it initially connects via https, but the redirect that sends you to /index.php/RISC_OS kicks the connection back to http. Manually entering https://www.riscos.info/index.php/RISC_OS works fine. A lot of other redirects seem to do the same (e.g. random wiki page). But other than that, nothing seems to be broken.

1 gives me http, 2-4 give me https. Nothing obviously broken.

Ditto for Chrome on Windows.

For completeness, current IE11 on Windows 10:

1. works, ends up at http
2. works, stays on https
3. works, ends up at https
4. works, ends up at https

Browsed a few pages, everything worked, no security warnings to be seen.

Thanks everyone. So a question: is it reasonable to expect RISC OS browser users to use HTTPS these days? It would be nice to get rid of the redirect of https://www.riscos.info/ → http://www.riscos.info/index.php to encourage browsers to use HTTPS. (We’d still need to keep HTTP around for downloads etc, and the HTTP wiki wouldn’t disappear). Would any users of ArcWeb or Webite or whatever be upset by that?

I realise that Webite or ArcWeb can’t post here, so this audience is somewhat self-selecting ;-)

It would be nice to get rid of the redirect of https://www.riscos.info/ → http://www.riscos.info/index.php to encourage browsers to use HTTPS.

On Firefox on Android, all of the links take me to SSL. If the site is reacting to browser sniffing, maybe you only need to pay attention to those few that can’t cope with SSL?

Or do what I do on my blog: https://www.heyrick.co.uk/blog/index.php?diary=20180411 vs http://www.heyrick.co.uk/blog/index.php?diary=20180411
And here’s why I don’t automatically redirect. The visitor can choose…

What I was hoping was happening is that the HTTP browser sees the HSTS header and uses that as a reason to upgrade to HTTPS if it understands HSTS, and if it doesn’t it’ll stay on HTTP. Once upgraded it’ll stay upgraded for the duration of the HSTS lifetime. Since riscos.info has user login accounts with passwords, unlike your blog, they should be protected and why I’d like to deprecate HTTP if possible, but keep it around for those few people who need it (and downloads etc). However, if people land on HTTP (eg from an old link) some browsers don’t pay attention to the HSTS header and stay on HTTP – that’s annoying.

We have to redirect / to /index.php/RISC_OS, but it seems that redirect is causing a HTTPS→HTTP downgrade on NetSurf at least. The redirect currently has the protocol in the target URL – maybe it can work in a protocol-agnostic way, but it would be better for that redirect to push people towards HTTPS so they pick up the HSTS header. However doing that would break anyone who can’t do HTTPS.

There’s no browser sniffing or anything fancy. It just serves exactly the same content on both protocols, to anyone, with an added HSTS header.

What I was hoping was happening is that the HTTP browser sees the HSTS header and uses that as a reason to upgrade to HTTPS if it understands HSTS, and if it doesn’t it’ll stay on HTTP.

No, HSTS was not designed for that. RFC 6797 explicitly states the following: “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”.

If you want to retain both http and https version of the site, you might consider recognizing the visitors by their User Agent, and then redirecting them accordingly. This has some flaws, however. First, UA usually contains a real mess and is hard to parse. Second, it can be easily forged, so by replacing it you can force the server to respond with http.

However, if people land on HTTP (eg from an old link) some browsers don’t pay attention to the HSTS header and stay on HTTP – that’s annoying.

If you send Strict-Transport-Security header back to the browser over HTTP you’re breaking the RFC, because “An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport”.

No wonder browsers don’t follow it. I’d even say those that do behave improperly.