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.
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.
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.
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.
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.
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.
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.
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!"
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.
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?
> 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.)
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.
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.
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.
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.
