7 ms·

Discontinue support for weak cryptographic standards

141 points by aorth 9y ago

dc_gregory 9y ago
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 9y ago
  Isn't 1.2 like 10 years old? Why would it be disabled?
  - jagger27 9y ago
    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&language=en_US&type=1 https://help.salesforce.com/articleView?id=000220586&languag...
    - user5994461 9y ago
      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.
  - craftyguy 9y ago
    Microsoft.
  - dc_gregory 9y ago
    Assuming there is a compatibility reason. Also keep in mind, 4.5 was released late 2012 (and support ended at the start of 2016).
  - jwilk 9y ago
    The spec was published in August 2008. So yes, nearly 10 years. Source: https://tools.ietf.org/html/rfc5246 https://tools.ietf.org/html/rfc5246
  - pilif 9y ago
    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 9y ago
      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.
- hannob 9y ago
  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.
  - taspeotis 9y ago
    .NET 4.5 RTM has been EOL since 2015, you need to install a newer version like .NET 4.5.2.
- taspeotis 9y ago
  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/#networking-1 https://docs.microsoft.com/en-us/dotnet/framework/whats-new/...
  - dc_gregory 9y ago
    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.
LinuxBender 9y ago
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 9y ago
  But the data was from a year ago; presumably, with a full year notice, hopefully that number has decreased.
the_mitsuhiko 9y ago
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 9y ago
  Squid proxy! (Dockerized!) We do this for some enterprise shenanigans where we need to MITM M2M. YMMV.
  - the_mitsuhiko 9y ago
    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
    - toomuchtodo 9y ago
      Happy to help!
    - cortesoft 9y ago
      The article was from over a year ago, so they have given over a year heads up.
      - the_mitsuhiko 9y ago
        Damn. My fault then. Completely missed that.
- PeterisP 9y ago
  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.
- rollcat 9y ago
  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.
jlardinois 9y ago
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 9y ago
  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 9y ago
    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..
- aorth 9y ago
  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!"
MBCook 9y ago
(2017)
ptoomey3 9y ago
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 9y ago
  That is honestly a great idea for safe-ish deprecation in uninformed environment!
  - Klathmon 9y ago
    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 9y ago
      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.
Area12 9y ago
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?
- Area12 9y ago
  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
- hannob 9y ago
  > 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 9y ago
    So ... why do they continue with tls_rsa? Is it required because of middleboxes lagging behind?

141 points by aorth 9y ago

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 9y ago
Isn't 1.2 like 10 years old? Why would it be disabled?
- jagger27 9y ago
  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&language=en_US&type=1 https://help.salesforce.com/articleView?id=000220586&languag...
  - user5994461 9y ago
    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.
- craftyguy 9y ago
  Microsoft.
- dc_gregory 9y ago
  Assuming there is a compatibility reason. Also keep in mind, 4.5 was released late 2012 (and support ended at the start of 2016).
- jwilk 9y ago
  The spec was published in August 2008. So yes, nearly 10 years. Source: https://tools.ietf.org/html/rfc5246 https://tools.ietf.org/html/rfc5246
- pilif 9y ago
  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 9y ago
    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.
hannob 9y ago
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.
- taspeotis 9y ago
  .NET 4.5 RTM has been EOL since 2015, you need to install a newer version like .NET 4.5.2.
taspeotis 9y ago
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/#networking-1 https://docs.microsoft.com/en-us/dotnet/framework/whats-new/...
- dc_gregory 9y ago
  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.

LinuxBender 9y ago

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 9y ago
But the data was from a year ago; presumably, with a full year notice, hopefully that number has decreased.

the_mitsuhiko 9y ago

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 9y ago
Squid proxy! (Dockerized!) We do this for some enterprise shenanigans where we need to MITM M2M. YMMV.
- the_mitsuhiko 9y ago
  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
  - toomuchtodo 9y ago
    Happy to help!
  - cortesoft 9y ago
    The article was from over a year ago, so they have given over a year heads up.
    - the_mitsuhiko 9y ago
      Damn. My fault then. Completely missed that.
PeterisP 9y ago
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.
rollcat 9y ago
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.

jlardinois 9y ago

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 9y ago
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 9y ago
  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..
aorth 9y ago
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!"

MBCook 9y ago

(2017)

ptoomey3 9y ago

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 9y ago
That is honestly a great idea for safe-ish deprecation in uninformed environment!
- Klathmon 9y ago
  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 9y ago
    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.

Area12 9y ago

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?

Area12 9y ago
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
hannob 9y ago
> 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 9y ago
  So ... why do they continue with tls_rsa? Is it required because of middleboxes lagging behind?