Nodejs.org: Can we migrate nodejs.org to strict https?

[rvagg]

The current nodejs.org has https enabled but it's not strict. See the config for details of what's enabled for plain http. In summary, URLs matching /dist/* /**.json will be served but anything else will get a 301 redirect to the equivalent https URL.

You'll see a note in the config:

    # don't redirect dist to https as it breaks nvm/travis-ci
    # probably the same is true for json

I don't know the provenance of this, perhaps TJ, perhaps @misterdjules? I can understand the caution in jumping straight to https when the redirect was first put in place, but has the time come to make a full move?

I'd really like to redirect everything to https like we do with iojs.org, the days of http are numbered and we shouldn't let it linger. The files served from /dist/* are the ones that benefit the most from being served via https yet they are also the ones getting a pass.

So, my question to @nodejs/website and @nodejs/build is what do you all want to do about this? Can we make a switch to strict https with our website change and v4 release or is there reason to maintain caution here?

@ljharb: can you give us some context about nvm? Do you have details on whether it can currently handle https and if so, when was this enabled and do you have any way of knowing how many users of those old versions are out there?

Does anyone have an entry to Travis to find out the impact there?

Any clues about the .json files? Are there people loading them from the frontend that would need them served via http?

[fhemberger]

I know someone at Travis, I can ask her.

[Fishrock123]

Doesn't nvm/Travis work with full https on io.js?

[rvagg]

My guess here is that an older version of nvm doesn't handle redirects from old http:// URLs it it uses and those are in the wild and we're being cautious. Which is why I'd like to know any more scope of this possible issue.

[ljharb]

Definitely an older version of nvm had "http:" URLs, but that's now fixed (https://github.com/creationix/nvm/issues/554). v0.17.3 is old, and v0.26.1 is what's out now. I still have some updates to make before node v4 will even work with nvm, though.

What would have the least breakage would take more time than I think you'd like:

• I update nvm to work with node v4.0 and release it (i'm out of the country for the first 3 weeks of september, so i've only got a few days left to try to get this out)
• I PR that into travis-ci
• We wait until they build and deploy new VM images for their infrastructure (i have a direct line to them and can prevail upon them to do this asap)
• turn off your https redirect with the node v4 release, thus simultaneously breaking old nvm two ways, and people can just upgrade.

[rvagg]

It'd be nice if we had a way of flagging deprecation of these URLs

We can leave them enabled if we really want to be conservative here, I'd just really like a path to moving to full strict-https and this upgrade seemed like a great opportunity to do that, users would realise the site has changed and therefore any breakage they have would logically be part of that, instead if we just change it a few months down the track then it could come out of nowhere. We could post a notice somewhere but it's unlikely to be picked up by the right people.

[rvagg]

done, pretty much identical to old nodejs.org for this now

[rvagg]

Reopening, going to track this because we need to switch, serving binaries via http is not only insecure but it makes the server config really complex and I'd love to see all of that complexity disappear.

[mikeal]

Do we have a clear list of blockers?

[rvagg]

no clear list beyond nvm and knowing that it's likely that there's still old versions out there still in active use

I think this might have to be something we trial, perhaps for a short period of a few hours and see who squeals.

[fhemberger]

Is this a case for https://github.com/nodejs/build/pull/193?

[rvagg]

yes, to verify we get all the redirects right when we change the config, but it's mostly about not knowing what's out there and what we might break, how many clients don't follow redirects that are using http, I do know that a _lot_ of users use http and I'd really like to shift that

[fhemberger]

How about announcing the planned change on our blog, so that tool authors (hopefully) react and check their code, before doing the switch? May be a smoother approach than just waiting for the squealing. ;)

I'd suggest to announce this soon and wait for 14 days before doing the actual switch. That should give everybody enough time for code changes or to get in contact with us for questions.

[mikeal]

nvm uses curl underneath, doesn't curl follow forwards?

[Fishrock123]

No, curl does not follow redirects without -L -- same as what we have to use for fetching PR patches these days.

On Oct 2, 2015, at 7:50 AM, Mikeal Rogers [email protected] wrote:

nvm uses curl underneath, doesn't curl follow forwards?

—
Reply to this email directly or view it on GitHub.

[ljharb]

Since travis-ci, as well as anyone using node 4, is using an nvm that uses https, I think it's probably OK to break those old nvm installations - but it'd be nice to have advance notice, and brownout periods. In other words, turn it off for a day, back on for a week, off for half a week, back on for half a week, etc - to give people time to be broken only for a short window while they upgrade.

[rvagg]

curl is a bit funny with redirects, I _think_ in most cases where we will be providing redirects that it should follow them even without -L, my guess is that the impact will be minimal but this is like a semver-major, you never really know what you're going to break in the ecosystem because ... workflow.

[mikeal]

Do we have a timeline? I'd like to get a blog post up if we know there is a date we're switching over to only SSL.

[rvagg]

@mikeal propose one and we'll make it so! we can take a few months if need be

[mikeal]

November 1st!

[bnb]

@mikeal You want to write the blog post, or should I create an issue in Evangelism?

[phillipj]

Postpone this to December 1st, and get a blog post out asap @mikeal @bnb @rvagg?

[mikeal]

i'm a little cautious about this because we haven't even successfully renamed the repo yet. once i see that we can coordinate that with build successfully I'd be much more confident in something like this :)

[rvagg]

Still on my TODO list, it's not hard, just another thing to be done. +1 on postponing the timeline.

[fhemberger]

@rvagg @nodejs/build Is this issue still relevant or has it been resolved?

[Starefossen]

Yes, and no. There is a permanent HTTP => HTTPS redirect in place. @jbergstroem is working on simplyfying the SSL redirects in nodejs/build#389 but in order to be _strict_ HTTPS we should add the Strict-Transport-Security header.

[rvagg]

WE HAVE A PLAN!

It may be surprising but we're actually moving closer to being able to properly do this, will update when we can move forward but I expect we'll be able to provide a date for fully removing http from nodejs.org.

[ljharb]

travis-ci images still have outdated SSL things on them, so ideally we can test this with various travis-ci images (cough cough nvm cough cough) before deploying it to prod?

[rvagg]

the migration plan would involve at least one test weekend when we turn it on temporarily and see what breaks.

[jbergstroem]

@ljharb we will soon have non-ssl alternatives available for libraries or clients that doesn't support STS (or SSL). We will obviously advise against it, but we understand there's a need. If you want to test it out, ping me on irc or email.

[fhemberger]

It's almost a year later since I asked the last time. ;)
@nodejs/build Is this issue still relevant or can we close it?

[jbergstroem]

@fhemberger its not irrelevant at least; no one is driving the progress.

[bnb]

Would love to see this happen ❤️

[fhemberger]

Closing this issue here, whatever still needs to be done about this should be discussed in @nodejs/build. Still hoping Strict-Transport-Security will land regardless of the dist discussion.