Enable HSTS on website

[mhdawson]

This was discussed a while back and we had done what was planned at the time in #516.

However, seems like we stopped short of enabling HSTS. It's been reported to the project and opening this issue to discuss in the build team and see if we can do it now.

[mmarchini]

Do we have a sense of how risky adding this would be? Do we have metrics to determine if traffic that we're handling per subdomain is mostly http or https?

[targos]

Do we have any subdomain that does something other than redirecting to https when it's accessed by http?

[richardlau]

AFAIK only http://unencrypted.nodejs.org, but if you go there it says

Only use this if you have clients that don't support SSL. This service will cease to exist 2022-01-01.

Looks like the (already past) 2022 date was already an extension from 2020-01-01 #55 (comment) (cc @jbergstroem).

There was draft communication around a plan to enable HSTS from 2016 but I don't think it ever got published: #484.

[tniessen]

I'm not quite sure I understand the concerns. AFAIK, HSTS does not prevent clients from using HTTP. In fact, clients should ignore HSTS response headers when making HTTP requests. Only when a client is connected over HTTPS already, HSTS tells the client to keep using HTTPS instead of HTTP in the future. We are already redirecting to HTTPS on the main domain (via 301 Moved Permanently), so we already make it impossible to download files over HTTP, and HSTS does not change anything about that.

[targos]

HSTS tells the client to keep using HTTPS instead of HTTP in the future.

This is what can be problematic (assuming we enable it for subdomains). After a client has accessed https://nodejs.org, it becomes impossible for them to access non-https subdomains in the future.

[tniessen]

assuming we enable it for subdomains

That's entirely optional though, and if we have any non-HTTPS subdomains, we can just secure the other subdomains.

[mhdawson]

@rvagg and @jbergstroem do either of you two remember why we did not enable HSTS when we last discussed it.

[mhdawson]

@ljharb are your past concerns listed in #516 still a concern?

[mhdawson]

@nodejs/version-management is there any concern that turning on HSTS (which may affect non-encrypted downloads from the main website)?

[coreybutler]

@mhdawson - I can only speak for NVM for Windows, but I can't think of a reason why this shouldn't be done.

NVM4W has an optional flag to ignore certificate verification, which is primarily for people hosting their own in-house mirrors. Users cannot download from nodejs.org over a non-encrypted connection, unless they have some sort of custom proxy.

[ljharb]

@mhdawson which past concerns are listed there?

[jbergstroem]

@rvagg and @jbergstroem do either of you two remember why we did not enable HSTS when we last discussed it.

The only thing I can add is that its hard to cover every scenario you are not fully aware of and HSTS is a one way street. You enable it and there is not a way back.

[ljharb]

Is there any way to enable it in general, but NOT on nodejs.org/dist/* and iojs.org/dist/* URL patterns? That way, automated tools won't have any risk of breakage, but normal website users will benefit.