HSTS preload and subdomains

[Peter Law]

Hi,

HSTS is an HTTP header which tells visitors browsers to always only
connect over HTTPS. We currently have this enabled. At the moment we
also redirect everything (TLS or not, subdomain or not) to
https://www.studentrobots.org/.

Clean browser instances can't know about HSTS requests yet, so it
turns out that Google maintain a preload list at
https://hstspreload.appspot.com/. That list also ends up being used by
Firefox & IE/Edge as well.

There are some additional requirements for inclusion in the list:
- enable the includeSubDomains token in the header
- enable the (non-standard) preload token in the header

Making these changes is fairly simple, but we'd want to make sure that
we don't end up breaking things.

On the subdomains side, we previously didn't have a wildcard cert,
though we now do. I'm guessing this is why this wasn't included in the
headers originally.

The only other caveat for preload inclusion is that doing so is a
long-term thing -- while submission is semi-automated, removal is
highly manual. The list is also part of the browsers' source code, so
takes months to cycle into the current versions. I don't think this is
an issue as we're already planning to continue supporting HTTPS for a
long time.

Thoughts on whether we should enable the subdomain and/or preload
tokens would be welcome.

Thanks,
Peter

[Jeremy Morse]

Hi,

On 30/03/16 17:04, Peter Law wrote:
> Thoughts on whether we should enable the subdomain and/or preload
> tokens would be welcome.

I can't think of any service we would want to run where we would not
also want SSL. We do, after all, want SSL everywhere.

inre preload, if I understand right, we have to add a field to the
header, then submit it to that website you linked to yers? Hopefully
this should be trivial.

Only use case I can think of where this could ever be an issue is where
someone sets up a dev VM and uses their host file to point
studentrobotics.org at a local instance, then tries to use http there. I
don't see this as a serious problem though, as that's a very-edge use case.

--
Thanks,
Jeremy

[Peter Law]

Hi,

Jeremy wrote:
> inre preload, if I understand right, we have to add a field to the
> header, then submit it to that website you linked to yers? Hopefully
> this should be trivial.

This is correct.

> Only use case I can think of where this could ever be an issue is where
> someone sets up a dev VM and uses their host file to point
> studentrobotics.org at a local instance, then tries to use http there. I
> don't see this as a serious problem though, as that's a very-edge use case.

I think that this use-case would already be complicated by our use of
HSTS and redirections since:
- any non-clean browsers would still want to connect to that dev
instance over HTTPS
- our dev instances also emit the redirections and HSTS headers

Only if someone wanted to configure a dev instance to actually serve
over HTTP (not sure if this was what you meant) would it change
anything over the current setup.

My understanding is that (at least for firefox), a server can opt-out
of preloading by serving an HSTS header with a max-age of 0. Firefox
will store that as an override of the preload value [1]; I'm not sure
what other browsers do. This would enable the above scenario to work
if someone really wanted it to.

Separately, it's just occurred to me that I think we still serve
Subversion access via some non-HTTPS subdomains, however on trying
these none of them actually work [2] for SVN access. Since no-one has
noticed this, we can probably tidy up much of the SVN special casing
in the apache handling now, which would also clarify the state of our
subdomains header.

Thanks,
Peter

[1] https://blog.mozilla.org/security/2012/11/01/preloading-hsts/
[2] http://svn.srobo.org errors "name or service not known",
https://svn.srobo.org errors "name or service not known",
http://svn.studentrobotics.org/ errors "moved temporarily to
https://www.studentrobotics.org/; please relocate"
https://svn.studentrobotics.org/ errors "XML Parsing failed:
Unexpected root element 'html'" [3]
[3] https://svn.studentrobotics.org/ serves the same HTML as
https://www.studentrobotics.org/!

[Peter Law]

Hi,

Jeremy wrote:
> inre preload, if I understand right, we have to add a field to the
> header, then submit it to that website you linked to yers? Hopefully
> this should be trivial.

I've now submitted patches to this end:
- subdomains: https://www.studentrobotics.org/gerrit/2718
- preload: https://www.studentrobotics.org/gerrit/2719

I kept them separate in case anyone could think of a reason not to add
preload too.

Thanks,
Peter

[Kier Davis]

This sounds like a very good idea.

On Wednesday, 30 March 2016 17:55:41 UTC+1, PeterJCLaw wrote:

My understanding is that (at least for firefox), a server can opt-out 
of preloading by serving an HSTS header with a max-age of 0. Firefox 
will store that as an override of the preload value [1]; I'm not sure 
what other browsers do. This would enable the above scenario to work 
if someone really wanted it to. 

It seems like Chrome, Opera, Safari [1] and IE [2] also allow disabling

HSTS either globally or per-site, though I've not tested this.

My opinion is that the situation Jeremy described is a valid use case -

it's probably how I would first approach testing a tool or script against

a locally running server going by a hostname under "studentrobotics.org".

Nevertheless, it's not a frequently-encountered use case and there are

enough workarounds (e.g. disable HSTS, change the hostname, dummy

certs) that I don't think it obstructs putting this change through.

 

Separately, it's just occurred to me that I think we still serve 
Subversion access via some non-HTTPS subdomains, however on trying 
these none of them actually work [2] for SVN access. Since no-one has 
noticed this, we can probably tidy up much of the SVN special casing 
in the apache handling now, which would also clarify the state of our 
subdomains header. 

I wasn't even aware that we had SVN endpoints - I guess they're somewhat obsolete now?

-Kier

[1] http://classically.me/blogs/how-clear-hsts-settings-major-browsers

[2] https://support.microsoft.com/en-us/kb/3071338

[Peter Law]

Hi,

I wrote:
>> Separately, it's just occurred to me that I think we still serve
>> Subversion access via some non-HTTPS subdomains, however on trying
>> these none of them actually work [2] for SVN access. Since no-one has
>> noticed this, we can probably tidy up much of the SVN special casing
>> in the apache handling now, which would also clarify the state of our
>> subdomains header.

Kier wrote:
> I wasn't even aware that we had SVN endpoints - I guess they're somewhat
> obsolete now?

Almost. I've had cause to refer to SVN a few times since we moved to
Git. Initially this was for moving content to other Git repos, though
more recently it's been to look at old history which isn't in Git. The
rules are the main thing I recall having looked at.

Thanks,
Peter

[Peter Law]

Hi,

Jeremy wrote:
>> inre preload, if I understand right, we have to add a field to the
>> header, then submit it to that website you linked to yers? Hopefully
>> this should be trivial.

I wrote:
> I've now submitted patches to this end:
> - subdomains: https://www.studentrobotics.org/gerrit/2718
> - preload: https://www.studentrobotics.org/gerrit/2719
>
> I kept them separate in case anyone could think of a reason not to add
> preload too.

No-one has since come up with a reason, and the patches are now
merged. Do we want to also actually submit ourselves for preload now?

Thanks,
Peter