Draft text for HSTS communication

[mhdawson]

Proposed Text:

---

Heads Up !

The goal of the Node.js build team is to deliver services/resources through channels protected
by cryptography whenever possible. As part of this effort we are planning to enable HTTP Strict
Transport Security(HSTS) on nodejs.org, iojs.org and all subdomains.

With HSTS enabled, the web sites will inform browsers that the site should never be loaded using
HTTP and any such attempts should be converted to HTTPs requests. Enabling HSTS will ensure that
all resources are delivered through a protected channel and prevents a number of man in the
middle attacks. You can read more about HSTS here.

The current plan is to do the rollout in two steps:

• We will run a test the weekend of November 4-6.
• We will do the complete switch-over on December 2nd.

As an alternative for clients that can't support the new setup, we will provide unencrypted.nodejs.org and unencrypted.iojs.org as an alternative which will
support http and rsync protocols for an interim period until January 1 2022.

If you have any questions or concerns please open an issue in the build repo.

[jbergstroem]

Typo: Novembeddr -> November

We should also mention that we will offer an alternative for clients that doesn't support this at unencrypted.{nodejs,iojs}.org that allows http and rsync protocols. These services have been given an EOL at 2022-01-01 but might be extended if no other viable alternative has been made available.

@rvagg lgty?

[mhdawson]

@jbergstroem @rvagg updated based on @jbergstroem comments. Left out the part about an extension as 2022 is pretty far out anyway so I don't think softening by mentioning a possible extension helps.

[gibfahn]

ref: #55

[mhdawson]

@jbergstroem @rvagg any comments or should we plan to send this out ?

[mhdawson]

Added to WG agenda in case we don't close on it before then.

[jbergstroem]

(i have no more comments)

[MylesBorins]

quick ping to @ljharb and @qw3rtman to confirm this would not negatively affect n or nvm

[joaocgreis]

Text LGTM.

Perhaps when we enable this completely we can add a visible notice to the main page warning users about this (for one week perhaps?). Users that are not able to connect will probably try another computer/browser and if they can access there they will find an explanation.

[Trott]

Text LGTM

[gibfahn]

So presumably unencrypted.nodejs.org would be identical to the current nodejs.org?

[jbergstroem]

@gibfahn: correct. it rsyncs every N minutes (I forget) and makes it available over rsync and http. We might look at adding ipfs at some point.

[ljharb]

This will absolutely break anyone using an older version of nvm (luckily, a much much older version) that has the mirror pointed at the HTTP version - however, anyone who wants io.js support, or working node4+ support, has a version of nvm that points at the HTTPS URL, so I think this should be fine.

Note that #233 is still open and prevents older clients from accessing iojs.org even with SSL - fixing that first would be very helpful to mitigate the impact of this change.

[jbergstroem]

@ljharb seeing how not much has changed in #233 I don't think we should rely on it being supported in the near future. Is it possible for you to fallback to unencrypted or similar? Old clients is one of the reasons we offer this service in the first place.

[ljharb]

Possibly - I don't really have any way of detecting that fallback reliably, so I'd have to code it to unconditionally retry the HTTP version, and I'm loath to do that.

[rvagg]

1. there's mention of rsync in here but we haven't announced it anywhere else yet, perhaps we should roll it up into a single post? @jbergstroem did we come up with initial text for that?
2. the plan with unencrypted.nodejs.org was to just support the downloads directory, we can extend that to do all of www content, what does @nodejs/build think of that? I think I'm in favour of keeping it simple at the moment just have /downloads/ stuff like is there now (see http://unencrypted.nodejs.org, it's up rn).
3. We should probably describe the state of play right now wrt http access, it's fairly limited: location ~ ^/(?!(dist/|dist$|\.json$)) - everything else is effectively HSTS, just via redirect. Also a mention of why it's like this, i.e. old clients like nvm since nodejs.org was http-only for a lot of its life. When doing breaking changes it's always good to give people a heads-up on specifics so they know what to look out for.

[ljharb]

@rvagg the dist directory would be necessary to keep, since that's the only one nvm currently uses.

[rvagg]

@ljharb on unencrypted.nodejs.org you mean? there's no plan to remove it from nodejs.org, we're stuck with it forever methinks

[ljharb]

I suppose it doesn't matter on unencrypted, it just means my messaging to people that this change breaks would be slightly more complex (ie, rather than just "add the unencrypted cname", it'd be "use this URL")

[rvagg]

@ljharb we can do /dist/ on unencrypted if it makes it easier for nvm, that's no problem, it's just an alias for /download/release/

[jbergstroem]

1. Initial rsync text: Can't find it. I'll throw something together.
2. I'm -1 to expanding what will be available through unencrypted.nodejs.org. Downloads should have to do. It's 2016 for pete's sake.
3. Good idea. Perhaps merge suggested text into a bigger one that covers general direction.

[ljharb]

You say "it's 2016" as if this thread isn't the first moment I've (the largest consumer of it) ever heard about deprecating "dist"

[jbergstroem]

@ljharb wasn't referring to dist, rather www stuff (website, api docs, et al). I don't think we'll ever be able to move away from dist

[Trott]

Seems like this must be close-able at this point, but by all means, comment or re-open if I'm wrong.