[HN Gopher] The NPM registry is deprecating TLS 1.0 and TLS 1.1
___________________________________________________________________
The NPM registry is deprecating TLS 1.0 and TLS 1.1
Author : joeyespo
Score : 96 points
Date : 2021-08-24 15:46 UTC (7 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| thrower123 wrote:
| 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.
| brinox wrote:
| I don't want to know what other security holes exist in
| applications that don't even support TLS 1.2.
| selfhoster11 wrote:
| 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.
| jrochkind1 wrote:
| TIL that github runs the npm registry?
| joshxyz wrote:
| microsoft got github vscode npm typescript bruh
| spullara wrote:
| https://www.zdnet.com/article/microsoft-buys-javascript-deve...
| staticassertion wrote:
| 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.
| minitech wrote:
| `--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.)
| staticassertion wrote:
| Nice, thank you.
| modshatereality wrote:
| Are there any theoretical attacks on git's usage of sha1?
| dharmab wrote:
| Yes. For this reason, Git is transitioning to SHA256.
|
| https://git-scm.com/docs/hash-function-transition/
| jl6 wrote:
| 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.
| richardwhiuk wrote:
| Deferred to Spring 2021 -
| https://blogs.windows.com/msedgedev/2020/03/31/tls-1-0-tls-1...
| jl6 wrote:
| Which has now passed, with TLS1.0/1.1 still working.
| nicoburns wrote:
| 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.
| Lammy wrote:
| > 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/th
| e-f...
| chrismorgan wrote:
| 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.)
| iudqnolq wrote:
| > 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."
| chrismorgan wrote:
| 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.
| nerdponx wrote:
| 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.
| iudqnolq wrote:
| I agree it's strange
| kevincox wrote:
| 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.
| kens wrote:
| 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".)
| millerm wrote:
| My 82 y/o dad still "warms up" his computer.
| kens wrote:
| 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.
| globular-toast wrote:
| 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.
| Angius wrote:
| 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.
| prdonahue wrote:
| That's not true.
|
| Any plan (including Free) can set a minimum TLS version of 1.2
| --or even 1.3 if you want.
|
| Login to the dashboard, select your domain, click SSL/TLS -
| Edge Certificates - Minimum TLS Version.
|
| (former CF SSL PM here)
| regecks wrote:
| 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.
| prdonahue wrote:
| 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).
| regecks wrote:
| Thanks! And you're right, sorry for jumping on you like
| that.
| prdonahue wrote:
| 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.
| ezekg wrote:
| 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.
| IiydAbITMvJkqKf wrote:
| .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.
| will4274 wrote:
| *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.
| JonathonW wrote:
| > 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.
| tetha wrote:
| 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.
| Already__Taken wrote:
| 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.
| ezekg wrote:
| 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.
| MarkSweep wrote:
| 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...
| rodgerd wrote:
| 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).
| shadowgovt wrote:
| 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.
| umvi wrote:
| 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.
| AmericanChopper wrote:
| 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...
| coldacid wrote:
| How long has GitHub been running the NPM registry? This is the
| first I've ever heard of it.
| dharmab wrote:
| https://github.blog/2020-03-16-npm-is-joining-github/
| coldacid wrote:
| Thanks!
| di wrote:
| PyPI did this in 2018:
| https://github.com/pypa/warehouse/issues/3411
___________________________________________________________________
(page generated 2021-08-24 23:01 UTC)