
Modernizing Transport Security - edmorley
https://security.googleblog.com/2018/10/modernizing-transport-security.html
======
Panino
> Today only 0.5% of HTTPS connections made by Chrome use TLS 1.0 or 1.1.

It's nice to have this stat from Google. A lot of people make wild claims
about how widely used TLS 1.0 is based on a glance at their webserver logs.
But if you look more closely you'll see that a large percentage of 1.0 traffic
is actually just hacked machines scanning for vulnerabilities, filling your
logs and using your resources. It's not real traffic, and TLS 1.1 is
microscopic in comparison to 1.0. As a percentage, very few sites would be
harmed by disabling 1.0/1.1. Most sites can simplify their TLS stack and lose
more bad than good by going TLS 1.2-only.

So I'm very glad to see Google deprecating and planning to disable 1.0/1.1.

To see the disabling of 1.0/1.1 over time check out SSL Pulse from SSL Labs
(in the chart "Protocol Support"):

[https://www.ssllabs.com/ssl-pulse/](https://www.ssllabs.com/ssl-pulse/)

TLS 1.0 has been dropping like a rock. Maybe it's too late to be an "early
adopter" of 1.2-only but regardless I think tech sites/people should lead the
way there.

~~~
tialaramex
Note that "connections made _by_ some particular web browser" (in this case
Chrome) and "connections made _to_ some web site" (and seen in your logs) are
not the same kind of thing.

Both client and server will try to negotiate the best version they and their
peer can manage, but the populations of those peers are different so the
statistics are not necessarily well correlated.

One problem Chrome doesn't have to worry about, but your site might
(especially if its demographics skew towards people with older and possibly
out-of-support systems) is out-dated web browsers.

Also I'm going to link the diediedie draft, which is now superseded by a
version with a more corporate name but I was amused because the IETF's script
crashed when trying to render it, so rather than link the current one that
doesn't do that here's the original with the funnier name and the crash:

[https://tools.ietf.org/html/draft-moriarty-tls-
oldversions-d...](https://tools.ietf.org/html/draft-moriarty-tls-oldversions-
diediedie-00)

~~~
lathiat
This is important, from a client perspective (e.g. from Chrome) this makes
sense.

But from a server perspective, you still have trouble with old clients,
particularly Windows XP.

Slowly disappearing but not gone yet.

Fortunately SNI (i.e. not requiring a dedicated IP per SSL customer) is
becoming so commonplace that a lot of those browsers are getting broken
anyway, which will probably speed up that deprecation.

------
B-Con
> Today only 0.5% of HTTPS connections made by Chrome use TLS 1.0 or 1.1.

Curious who the 0.5% are. Presumably Chrome is doing it's best to avoid
falling back to TLS 1.0 or 1.1 unless necessary, so presumably these are sites
that just don't support 1.2.

Apache added TLS 1.2 support 6.75 years ago:
[http://svn.apache.org/viewvc?view=revision&revision=1222922](http://svn.apache.org/viewvc?view=revision&revision=1222922)

I'm curious how many of those sites just haven't upgraded their server in ~7
years.

~~~
tialaramex
One thing that really stings here is that only the past few years have OS
vendors, library vendors and so on started paying attention to how people use
their crap to build things, and so software written / custom sites developed
before that awakening are often flawed because the developers tried their best
but weren't experts and weren't given the opportunity to ask for "You know,
good security, whatever that is at the moment?" but had to pick specific
values for things they didn't understand, including protocol versions, ciper
suites, key lengths, trusted roots...

For example, in Python you can ask for a specific TLS version ("Oooh, TLS 1.1
just came out, let's use that") or you can ask for what it calls "SSLv23"
which means any protocol in the SSL/ TLS family whatsoever. But only in very
recent 3.x Python releases can you easily specify "Um, anything above TLS 1.0
is OK?" even though that is clearly both more useful AND more likely to result
in the software working as intended in future.

In fact, software developers reading this: You probably didn't implement TLS
yourself (OK, the six smug people thinking "Yes I did", this isn't for you,
you've already read and perhaps written similar rants before). TLS 1.3 was
finished earlier this year. How many programs that you wrote more than six
months ago are you sure will "just work" with TLS 1.3 if the relevant
libraries or OS features are upgraded to support it? How many do you think
will tell the library/ OS/ framework/ whatever "Oh, no, I definitely want TLS
1.2" even though actually it wants security, and TLS 1.3 would improve that?

~~~
regecks
> For example, in Python you can ask for a specific TLS version

libcurl has the same thing. A really common problem in PHP ecommerce libraries
and applications is the misuse of CURLOPT_SSLVERSION to pin a specific
protocol version. Then their payments stop working every few years ...

------
seccess
Maybe somebody more familiar with TLS can set me straight here, but I find it
surprising that SNI still exists and there isn't much effort to replace it. To
me it seems like an odd hole to punch into the encryption layer. Back when I
was doing security research I wrote a TLS MITM and I distinctly remember
thinking "wow thanks SNI this makes it so much easier".

~~~
Boulth
There are efforts to encrypt it: [https://tools.ietf.org/html/draft-ietf-tls-
esni-01](https://tools.ietf.org/html/draft-ietf-tls-esni-01)

~~~
infogulch
This is a step in the right direction but it's not perfect. The name of _at
least one_ domain that the responding server must host is still leaked. This
can be a non issue if the same ip is hosting hundreds of domains (e.g.
CloudFlare) or pointless if it's just hosting one site.

I just had an idea that might be able to work around this though:

1\. Create a new TLD: .ip. All *.ip domains are valid ip addresses (in some
encoding, e.g. 740-125-138-139.ip, or anything else) and they always resolve
to the ip address specified. 2\. Automatically issue certificates for each
host for each of the ips that they serve on. (Thank you Lets Encrypt) 3\.
Every new connection made can just use the ip-domain as the esni originating
host, because you can know that every host is serving
[https://ownip.ip](https://ownip.ip).

This doesn't solve the fact that server ips are still fairly unique, and so a
reverse dns might be enough to find the host, but it doesn't leak any more
information than what the IP header already leaks, and it doesn't require
leaning even more on increasingly centralized proxies like CloudFlare.

~~~
dsl
Certificates already support IP addresses. They just need to be public (i.e.
not RFC1918 space) and for legacy browser compatibility the IP needs to be in
the commonName and subjectAltName.

~~~
stordoff
> (i.e. not RFC1918 space)

Is this just a restriction on current CAs? I have a self-signed certificate on
my router (more out of curiosity than any practical benefit), and it comes up
fine on [https://192.168.1.1/](https://192.168.1.1/)

~~~
reaperhulk
Yes, this restriction applies only to public CAs. The purpose is to prevent
someone from getting, for example, a 192.168.1.1 cert and then using it on
another network in a mitm attack.

------
CodeM0nkey
Similar announcement for Edge / IE 11:
[https://news.ycombinator.com/item?id=18219528](https://news.ycombinator.com/item?id=18219528)

It would seem these announcements (Chrome/Safari/Edge TLS 1.0/1.1 deprecation)
were coordinated.

Edit: The Microsoft announcement says as much.

------
petecooper
[Also posted on the related Firefox thread here:
[https://news.ycombinator.com/item?id=18223672](https://news.ycombinator.com/item?id=18223672)
]

If you want Nginx to use TLS v1.2, this is what you need:

    
    
      ssl_protocols TLSv1.2;
    

…and if you compile a recent Nginx from source and bake in OpenSSL 1.1.1 while
you do that, you can have TLS v1.3 with a TLS v1.2 fallback, too:

    
    
      ssl_protocols TLSv1.3 TLSv1.2;
    

See also:

[https://caniuse.com/#feat=tls1-2](https://caniuse.com/#feat=tls1-2)

[https://caniuse.com/#feat=tls1-3](https://caniuse.com/#feat=tls1-3)

------
ncw96
A related move by WebKit/Safari:
[https://news.ycombinator.com/item?id=18221606](https://news.ycombinator.com/item?id=18221606)

~~~
floatboth
Mozilla: [https://blog.mozilla.org/security/2018/10/15/removing-old-
ve...](https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-
tls/)

------
pbarnes_1
The real issue with deprecating TLS 1.0 and CBC ciphers is that you need a
minimum of Android 4.4 for TLS 1.2.

Might not be reflected in browsing stats, but according to this:
[https://developer.android.com/about/dashboards/](https://developer.android.com/about/dashboards/)
it's 3.8% of Android users. And that number undercounts non-Google Play
Services using Android devices.

~~~
dvorak42
This particular blog post and plan is regarding removing support of old TLS
versions and options on the client. Which means that all server administrators
need to do is enable TLS 1.2 and modern options.

Old clients (such as Android) will still be fine, if the servers don't also
turn off older versions/options.

------
dajonker
I feel like Google and Mozilla are acting too lenient here. In my opinion it
doesn't matter if you wait 1 month or 2 years to remove support for old TLS
versions, affected parties probably won't notice or act until it happens. On
the other hand I understand that Google and Mozilla are very careful about
user's experiences and their market share.

------
user5994461
Meanwhile in the finance industry... Excel 2010 only supports TLS 1.0

------
pisipisipisi
Until some random IoT device from 2016 without updated firmware requires some
weird old configuration to access it ...

------
baby
Shameless plug: I've been trying to tackle this front via removal of
dependencies[1]. We have been relying on more and more complex and heavy
protocols to secure any kind of transport security, just because the browsers
do it this way. I don't think TLS is the right approach to all transport
security nowadays.

[2] is a comparison of OpenSSL with the various experimental implementations
of Disco (tl;dr: 700k LOC vs 1k LOC)

The thing is at [https://www.discocrypto.com](https://www.discocrypto.com)

(disclaimer: it's quite experimental at the moment)

[1]:
[https://pbs.twimg.com/media/DpfV2wEWwAADIze.jpg:large](https://pbs.twimg.com/media/DpfV2wEWwAADIze.jpg:large)

[2]:
[https://pbs.twimg.com/media/DpfD_43XoAANcHe.jpg:large](https://pbs.twimg.com/media/DpfD_43XoAANcHe.jpg:large)

