The NPM registry is deprecating TLS 1.0 and TLS 1.1 | Hacker News Reader

The NPM registry is deprecating TLS 1.0 and TLS 1.1

github.blog

111 pointsjoeyespo48 comments

That’s a pretty nice set of steps, a genuine deprecation including even as good an attempt as is possible at notifying where it’s needed, rather than just a removal. It’s interesting to note that they don’t say when they’ll finally remove it.

(One of my pet peeves is people abusing the word “deprecate” when they mean “remove”. The word “deprecate” means just discouraging something without actually removing it, though it’s typically a precursor to subsequent removal.)

> It’s interesting to note that they don’t say when they’ll finally remove it.

It's right at the start of the detailed timeline section:

"While we will enforce a minimum of TLS 1.2 beginning October 4, 2021, we will also take steps to alert affected users to this change ahead of the deprecation."

It is a bit odd that it isn't in the timeline though. I also got to the end of the timeline and though for a second "what about the full disable" before reading the start of the article again and finding it.

Failing to notice that (twice, even, apparently!) was surprisingly careless of me. Thanks for the correction. But yeah, I do think it would be significantly better restructured to put that at the end of the bullet list.

… actually, reading this all more carefully now, I retract my praise of this as “a genuine deprecation”. They’ve abused the word deprecation like so many others. I fear the word will soon be lost to us, as more and more people misuse it.

“This year, we will similarly deprecate non-HTTPS access and TLS 1.0 and TLS 1.1 for npmjs.com, the public npm registry.” No, you will similarly remove it.

“we will also take steps to alert affected users to this change ahead of the deprecation.” — no, you’ve deprecated it now, and are taking steps to alert users ahead of the removal.

“The npm registry is removing TLS 1.0 and TLS 1.1 support” would have been a more accurate title.

I agree it's strange

Right. It is now currently deprecated as a result of this announcement. It will then be removed according to the schedule in the announcement.

Super confusing because they do not mean the same thing and I can't imagine why anyone would think they do.

Yes, misusing "deprecate" as a synonym for "remove" is a pet peeve of mine too, since the meaning is completely different. (There were a few word usages at Google that always annoyed me; "deprecate" was one, along with using LDAP as a synonym for "user id" and "turn down" for "shut off".)

My 82 y/o dad still “warms up” his computer.

Since some people might not know the history here, back in the vacuum tube days, you needed to let something like a TV warm up for a few minutes before it would work. Vacuum tubes contain a filament (much like the one in a light bulb) and it needed to heat up the cathode before the tube would start working. Later, manufacturers introduced "instant on" TVs that would keep the filaments powered even when the set was "off". This wasted electricity but you didn't need to wait for the tubes to warm up.

I didn't realise this was a problem until recently. We decided to deprecate a feature and an engineer immediately submitted a merge request to remove it. I asked wtf they were doing and they said they didn't know the difference. All this time I've thought everyone understood but now I see misuses everywhere and need to clarify all the time.

When Heroku removed support for TLS 1.0 and TLS 1.1 this year, I was surprised at how many of my customers were effected. I didn't give the deprecation much thought, assuming everyone was using a secure TLS version, but I guess enterprises like their legacy technology.

It's not that enterprises "like" legacy technology, it's just that it costs (potentially a lot of) time and money to audit and fix legacy code.

The biggest problem the PCI SSC had with deprecating old TLS versions was the sheer number of devices running XP Embedded (which doesn’t support newer TLS versions). It was THE operating system for point of sale devices for a very long time, and replacing or upgrading these devices was a very complicated and expensive process for a lot of organisations.

I haven’t worked with PCI for a couple of years, so I’m not sure where they got to. But that was the main issue that kept getting the depreciation deadlines pushed back. The ubiquity of that operating system was an issue in lots of other industries too. I worked in a place recently that had a large industrial robotics system, all of it was running on XP Embedded, and the most feasible approach they came up with for addresses the security issues created by that was to implement increasingly more strict network segmentation controls for their robots. I know it was also running on a fair amount of military hardware too (maybe still is? I have no idea), I don’t think you’ll find many helpful Stack Overflow threads for how to upgrade your Lockheed AC-130 from Windows XP…

.net framework (NOT core) on windows did (does?) Not support tls 1.2 by default. Enabling it takes either one line of code or a registry change.

It surprised me as well.

*Windows 7. Which was released in 2009, 1 year after TLS 1.2 was finalized. Windows 8.1 and 10 support TLS 1.2 without opt in.

In case someone is hardening these settings, we had a weird issue with Windows Server 2016 (iirc) based on this. The mozilla SSL config generator is going to give you a cipher configuration and happily claims Windows 7 and Win2016 both can connect to these servers.

However, that's only true if you use a certificate with an elliptic key. With a certificate with an RSA key, Win 7 and Windows Server 2016 cannot connect. That was a mess to figure out.

> Windows 8.1 and 10 support TLS 1.2 without opt in.

Not necessarily true depending on the application and when it was compiled. For example, older versions of Nuget will not connect to the current Nuget registry (after they removed support for TLS 1.0/1.1 a while back) without a registry change to require TLS 1.2, even on fully-patched Windows 10.

Compile against current .NET Framework and IIRC you get it by default, but old code still has to opt-in.

Supported yes but windows won't do it until you turn it on and that change was a very very recent change.

It's not even in the UI options were you enable it for TLS but down in the windows registry.

Yep, the .NET thing was the biggest cause of issue for my customers. Thankfully, all were a pretty quick fix but I also thought this was really weird.

On recent versions of .NET gotten easier. If your app targets a new enough version, you automatically get support for the most recent version of TLS.

https://docs.microsoft.com/dotnet/framework/network-programm...

If it ain't broke(1), standard operating procedure is not to fix it. So a lot of corps (and orgs, and individual devs) end up on TLS <1.2 without giving it any thought.

It can even be hard to reach them... A lot of stuff gets automated, and it takes a level of discipline to avoid routing some of the low-level error messaging to /dev/null (or its spiritual sister, an infolog nobody ever reads) that surprisingly many institutions lack.

(1) Security is extra-hard, because it ain't broke until it's broken into from the point of view of the end user.

One challenge for a lot of enterprise shops is an addiction to things like MITM middleware boxes, which often lag far behind, and long approval cycles for updates - demanding that software be repackaged for deployment and the like.

The biggest blocker on 1.3 deployment will be that it deliberately breaks middleboxes, which many, many enterprises have as a hard requirement (foolishly, in my opinion).

PyPI did this in 2018: https://github.com/pypa/warehouse/issues/3411

So I was curious and tried to figure out how to, client side, enforce TLS 1.2+ for npm. It is surprisingly not straightforward to me. I also had an annoying time due to 'npm' being the tool name and the repo name.

It seems you have to set an environment variable,

    NODE_OPTIONS=--tls-max-v1.2

But that's for node in general and I'm not sure if it even works for npm. I was expecting this to be something I could do in a package.json

I've done this for Rust for a long time by just setting a flag in `project/.cargo/config.toml`

    [http]
    ssl-version.min = "tlsv1.2"

(side note - I've had 0 issues with tlsv1.3 in cargo with crates.io)

I also wasn't able to figure out how to do this for `pip`. I honestly expected this to be super straightforward, but I guess I was sort of spoiled by how easy it was with cargo.

`--tls-max-v1.2` does what it sounds like and sets the maximum version to 1.2. You want `--tls-min-v1.2`. (Also, this just controls the default minimum version when code doesn’t specify one explicitly, and the default minimum is already TLS 1.2 on the latest Node.)

Nice, thank you.

TIL that github runs the npm registry?

https://www.zdnet.com/article/microsoft-buys-javascript-deve...

microsoft got github vscode npm typescript bruh

I know it has been a huge pain in the ass for some applications that use older ODBC drivers when Azure made TLS 1.2 the default for Azure SQL databases.

I don't want to know what other security holes exist in applications that don't even support TLS 1.2.

Sometimes it's the OS that is obsolete: modern versions of Chrome (from questionable sources) can run just fine in Windows XP, but any application that depends on the OS for its TLS support will be greatly disappointed that XP is now effectively locked out of modern crypto due to lack of updates.

A year or so back, Microsoft made an announcement of dropping TLS 1.0 and 1.1 support in Internet Explorer (and IE mode in Edge) but that seems to have gone quiet, and I now wonder whether they intend to keep support going until Internet Explorer (and IE mode in Edge) itself falls out of support.

Deferred to Spring 2021 - https://blogs.windows.com/msedgedev/2020/03/31/tls-1-0-tls-1...

Which has now passed, with TLS1.0/1.1 still working.

From that same link:

> Update as of 04/23/2021: The plan to disable TLS 1.0/1.1 by default is being updated for Internet Explorer and EdgeHTML (the rendering engine for the WebView control). TLS 1.0 and TLS 1.1 will not be disabled by default for both until early 2022. Organizations that wish to disable TLS 1.0 and TLS 1.1 before that time may do so using Group Policy. Microsoft Edge Legacy is no longer in scope for this plan as the support ended on March 9, 2021.

> There are no changes to the plan for the new Microsoft Edge (based on Chromium). TLS 1.0/1.1 were disabled by default starting in Microsoft Edge version 84, and the SSLVersionMin policy that permitted enabling the legacy protocol versions will be removed in version 91.

I'm guessing postponed due to not wanting to interrupt business during the pandemic where they may be short-staffed or other preoccupied.

> TLS 1.0 and TLS 1.1 will not be disabled by default for both until early 2022.

Because this is when they're killing both of those products, not just changing the default on this setting: https://blogs.windows.com/windowsexperience/2021/05/19/the-f...

How long has GitHub been running the NPM registry? This is the first I've ever heard of it.

https://github.blog/2020-03-16-npm-is-joining-github/

Thanks!

Are there any theoretical attacks on git's usage of sha1?

Yes. For this reason, Git is transitioning to SHA256.

https://git-scm.com/docs/hash-function-transition/

Everything is deprecating those old TLS versions, meanwhile Cloudflare still requires you to pay for a Business account to be able to disable them. Even though they also planned to deprecated them way back in 2018.

That's not true.

Any plan (including Free) can set a minimum TLS version of 1.2—or even 1.3 if you want.

(former CF SSL PM here)

It's kinda true.

I haven't been able to disable older TLS for my Cloudflare Pages domains. The setting you mentioned is ineffective for that product.

Based on what I've read on the Cloudflare forums and Discord, it's a known restriction.

My point was there are no plan-specific limitations on disabling old TLS versions.

If you're unable to set a minimum version for Cloudflare Pages, that's a separate issue, which I'm going to flag for the team now (though sounds like they're probably already aware and planning to resolve when they can).

Thanks! And you're right, sorry for jumping on you like that.

No problem! Team is telling me that it was fixed in late May.

Can you check and confirm?

If you're still having issues please file a support ticket and email it to pat at cloudflare and I'll flag.

Reply on news.ycombinator.com