Discontinue support for weak cryptographic standards | Hacker News Reader

Discontinue support for weak cryptographic standards

githubengineering.com

141 pointsaorth36 comments

Just a quick preview...we will be posting a blog post tomorrow morning with an update. Because of the delayed final blog post, we are delaying things by one week. The plan is to do a 1hr brownout on February 8th, followed by a permanent deployment on February 22nd. We realize that no matter how much notice (announced roughly a year ago), there are bound to be some systems that are both incompatible and unknowingly running on production systems. So, the hope is that a 1hr brownout will help to unearth such systems and give folks time to get them updated.

That is honestly a great idea for safe-ish deprecation in uninformed environment!

I always loved a similar idea that I believe Google uses (or used at one point) for sunsetting APIs.

You start by making 1% of requests fail on the scheduled date, then gradually increase that percentage over time until 100% of requests are failing.

This gives anyone that doesn't follow your blog or news to start realizing that there's a problem and find a solution before it completely cuts off.

I personally feel a brownout of 1 hour will barely register as a blip at many places, and if it goes back to working 100% they are liable to just ignore it after it resolves itself.

Last time we deprecated something in App Engine, we made an "opt out" flag, that customers could manually flip to keep the old way working for another week. This was reset every 7 days, until the final switchoff date. This worked pretty well; we saw fewer and fewer customers opting out as everyone updated their code, and the final deadline didn't come as a surprise to anyone.

This is a bit of a pain for .net devs on 4.5, as it by default has TLS1.2 disabled.

You can fix it with

        System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;

but note that its a somewhat global setting (for your appdomain?) so don't just set it to Tls12 and wonder why some of your connections don't work anymore.

Isn't 1.2 like 10 years old? Why would it be disabled?

IE either did not support it or had it disabled by default up until version 11. That's my guess, anyway. Firefox and Chrome took quite a while to fully implement it too.

https://help.salesforce.com/articleView?id=000220586&languag...

XP and IE and office up to 2013 and redhat and debian and curl and python and java and openssl and...

It took a while for TLS 1.2 to be supported by major platforms and tools.

Microsoft.

Assuming there is a compatibility reason. Also keep in mind, 4.5 was released late 2012 (and support ended at the start of 2016).

The spec was published in August 2008. So yes, nearly 10 years.

Source: https://tools.ietf.org/html/rfc5246

Because of broken interception proxies. In many cases, these prevented connections from being established at all if either side of the connection even just announced 1.2 support.

So it was disabled by default and in consequence it remained niche which didn’t exactly improve the situation with broken middle boxes. It also made implementing it in various SSL libraries somewhat low priority (see OpenSSL)

Only as the security of pre 1.2 started really crumbling and once the Snowden revelations moved security to somewhat higher priority in the public perception, it started to at least become possible to enable 1.2 at least on servers.

Frankly, I'm impressed we actually got to where we are at now. For a long time between 2008 and maybe 2015 it really looked like 1.2 was dead in the water.

Now we're transitioning to 1.3 and history is repeating itself: despite going great lengths to hide the differentness of 1.3 to existing middleboxes, they are still breaking 1.3 connections causing more and more bad hacks to be added to the protocol. A protocol which supports version negotiation since the beginnings in the early 90ies btw.

Crumble? AFAIK, there are no known attacks against any version of TLS. Only SSL. Heartbleed was an implementation defect, not a problem with the spec. Same with Snowden. They basically just opened the front door to him.

I just checked, .net 4.5 has been end of life since 2015. So if this causes people to realize that this can only be good.

.NET 4.5 RTM has been EOL since 2015, you need to install a newer version like .NET 4.5.2.

This is "fixed" in .NET 4.7 [1], which will take its cues from the operating system by default. So if Windows has TLS 1.2 support enabled, your apps will too.

[1] https://docs.microsoft.com/en-us/dotnet/framework/whats-new/...

I think in 4.6.1 (maybe 4.6), the default was set to TLS1.2 as well, so the problem was mostly solved a bit earlier. Much cleaner solution to listen to the OS though.

Can someone add (2017) to the title? Without seeing the date it makes it look like GitHub is discontinuing support with a few days' notice.

If the mods do that, they should also add the date it will be disabled. If it just had 2017 in the title, it could mislead people to think support ended last year.

I feel like a less confusing title would be something like "Github to discontinue support for weak cryptographic standards Feb 2018 (2017)"

I saw this with the original 2018 in the title and immediately had a pretty bad "what the f* Github? Deprecation periods aren't a thing?" reaction..

By the way, I submitted this with the title "GitHub will discontinue TLSv1 and TLSv1.1 on February, 2018" but when I looked a few minutes later it was already changed to be the title of the original blog post. I'm sure this article was posted last year (clearly GitHub gave plenty of timing), but I saw this as a public service announcement on Twitter and thought, "Oh crap, lots of people are going to have weird issues tomorrow, I'd better go tell some people!"

I notice that ssllabs.com/ssltest lists the cipher suites uses at github engineering as:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH x25519 (eq. 3072 bits RSA) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH x25519 (eq. 3072 bits RSA) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH x25519 (eq. 3072 bits RSA) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH x25519 (eq. 3072 bits RSA) TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK

Why still support the TLS_RSA_* ciphers, given that they, unlike TLS 1.1, have a known vulnerability? Is it mainly because of middleboxes that can't handle ciphers that all modern up-to-date browsers can?

Oh boy did that list come out poorly, let me try again:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA)

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA)

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH x25519 (eq. 3072 bits RSA)

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH x25519 (eq. 3072 bits RSA)

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH x25519 (eq. 3072 bits RSA)

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH x25519 (eq. 3072 bits RSA)

TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK

TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK

TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK

> Why still support the TLS_RSA_* ciphers, given that they, unlike TLS 1.1, have a known vulnerability?

TLS 1.1 also has known by design vulnerabilities. It only supports two cipher modes, RC4 and CBC/HMAC. The first is vulnerable to biases, the second to padding oracles + Lucky 13.

Yeah, padding oracles can be avoided by implementing crazy, complicated countermeasures. Same is true for TLS_RSA. (Though I do agree that TLS_RSA is probably more problematic.)

So ... why do they continue with tls_rsa? Is it required because of middleboxes lagging behind?

Oh boy. This will be fun for me. I am forced to build some binaries in a dockerized Centos 5 currently to make them portable. No support for TLS 1.2 in it.

Squid proxy! (Dockerized!)

We do this for some enterprise shenanigans where we need to MITM M2M. YMMV.

Yeah. I see some ways to fix this. But it looks like unless I change something now this will break tomorrow. Nice heads up in any case :P

Happy to help!

The article was from over a year ago, so they have given over a year heads up.

Damn. My fault then. Completely missed that.

If it's a particular fixed channel where you can sort out trusting certificates, then stunnel (possibly on the same machine will happily re-plug an older TLS/SSL connection to a TLS1.2 channel.

Try a multi-stage build. Fetch your build dependencies in a "modern" environment, like "FROM centos:7 AS build", then drop a "FROM centos:5" in the middle, and "COPY --from=build" the stuff you need.

Do all command line / API utilities support TLS 1.2+ now? Many linux distros ship really old libraries, is why I ask. Then there are the older unix systems with even older libraries.

Based on their stats about 5% of connections will fail. I presume some of these are bots. I am looking forward to how this plays out.

But the data was from a year ago; presumably, with a full year notice, hopefully that number has decreased.

(2017)

Reply on news.ycombinator.com