
Discontinue support for weak cryptographic standards - aorth
https://githubengineering.com/crypto-deprecation-notice/
======
ptoomey3
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.

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

~~~
Klathmon
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.

~~~
myelin
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.

------
dc_gregory
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.

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

~~~
pilif
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.

~~~
tootie
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.

------
jlardinois
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.

~~~
ihuman
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.

~~~
hvindin
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..

------
Area12
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?

~~~
hannob
> 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.)

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

------
the_mitsuhiko
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.

~~~
toomuchtodo
Squid proxy! (Dockerized!)

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

~~~
the_mitsuhiko
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

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

~~~
the_mitsuhiko
Damn. My fault then. Completely missed that.

------
LinuxBender
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.

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

------
MBCook
(2017)

