from the heat-death-of-the-universe-to-break,-or-maybe-five-years dept.
One year ago the IETF published TLS 1.3 in RFC 8446. Here is what is different from previous versions.
TLS 1.3 is the seventh iteration of the SSL/TLS protocol, having been preceded by SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2.
TLS 1.2 has been serving the internet faithfully for a decade now, yet nearly 25% of the Alexa Top 100,000 still doesn't support it. That's problematic, because making the jump from TLS 1.2 to to TLS 1.3 is already a fairly large change. Upgrading from even older protocols will require even more configuration.
Now, that's not to imply upgrading is prohibitively difficult, it's more to illustrate that one of the biggest challenges that's going to face TLS 1.3, at least for the next year or so, is the rate of adoption.
As of the end of last year, just over 17% of the Alexa Top 100,000 supported TLS 1.3.
Here are the primary differences in TLS 1.3 and prior versions:
- Eliminates support for outmoded algorithms and ciphers
- Eliminates RSA key exchange, mandates Perfect Forward Secrecy
- Reduces the number of negotiations in the handshake
- Reduces the number of algorithms in a cipher suite to 2
- Eliminates block mode ciphers and mandates AEAD bulk encryption
- Uses HKDF cryptographic extraction and key derivation
- Offers 1-RTT mode and Zero Round Trip Resumption
- Signs the entire handshake, an improvement of TLS 1.2
- Supports additional elliptic curves
In short, TLS 1.3 is faster to establish, faster to reestablish, streamlined throughout, and more secure than previous versions of SSL and TLS.
Most popular browser clients already support TLS 1.3. Server library versions supporting TLS 1.3 include
- OpenSSL 1.1.1
- GnuTLS 3.5.x
- Google's Boring SSL (current)
- Facebook's Fizz (current)
What's in your server?
(Score: 3, Informative) by Anonymous Coward on Wednesday July 17 2019, @12:44AM
Porn. And some other stuff. But mostly porn.
(Score: 5, Informative) by The Shire on Wednesday July 17 2019, @01:44AM (6 children)
This helps on the server side but will go largely unnoticed by the end user.
Actually there are three mandated by TLS 1.3:
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-256-GCM-SHA384
TLS13-AES-128-GCM-SHA256
Mostly true, however TLS 1.2 also supports ciphers with PFS (Perfect Forward Secrecy) and there are no known attacks that can crack it. Using TLS 1.2 with the proper set of ciphers is every bit as secure as TLS 1.3.
It's also worth pointing out that TLS 1.3 does not fix the SNI problem which allows anyone on the wire (like your service provider) to easily determine the domains you're communicating with. This was once something ISP's did by intercepting DNS queries but now that we have DNSSEC, DoT (DNS over TLS), and DoH (DNS over HTTPS) protecting those queries they have fallen back to intercepting the TLS SNI field. So while they cannot decrypt the traffic, they can still easily track the domains you are connecting to. In other words, they still know you're watching porn. Until there is a more widespread adoption of ESNI (Encrypted Server Name Identification) they will still be building browser histories on you. Cloudflare currently supports this but most browsers need manual settings to make it work.
(Score: 5, Interesting) by edIII on Wednesday July 17 2019, @02:59AM (1 child)
Cloudflare still causes tracking [privateinternetaccess.com].
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 2) by FatPhil on Wednesday July 17 2019, @07:21AM
So TLS1.3 is broken by design right from the off, and that, boys and girls, is "progress".
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Wednesday July 17 2019, @04:18AM (2 children)
> intercepting the TLS SNI field.
SNI was a workaround made for IPv4. Remove SNI and IPv4. IPv4 is like GeoCities. Far past its expiration date. ISPs have replaced modems with faster technologies that include WiFi with IPv6 built into them. There is as much reason to keep IPv4 around as there is Internet Explorer 6.
(Score: 4, Insightful) by The Mighty Buzzard on Wednesday July 17 2019, @10:29AM (1 child)
Dumbest quote of the day and I've barely got any coffee in me yet. IPv6 doesn't even make up a quarter of our bandwidth usage and we use it for all inter-server communication, including backups.
My rights don't end where your fear begins.
(Score: 1, Informative) by Anonymous Coward on Wednesday July 17 2019, @01:35PM
A few years ago I went fully IPv6 at home. My ISP supported it, my router supported it, my desktop supported it. Then I got an IOT thing and had to turn IPv4 back on.
(Score: 5, Interesting) by driverless on Wednesday July 17 2019, @04:34AM
That's the important thing. And it was mostly driven by Google, as a means of making Google's content delivery more efficient. The security red herring was just an excuse to replace existing algorithms with all the latest hipster stuff, but most of the motivation behind 1.3 was to make things easier for organisations like Google to push content out to clients, even when it negatively impacted security (0RTT is just a giant foot-shoot waiting to happen). Properly-implemented TLS 1.2 is no more or less secure than properly-implemented 1.3. And that's the rub, you don't get better security by throwing everything away and starting again, you get it by fixing your existing code. Since TLS 1.3 is starting again from a mostly new codebase, there's going to be lots and lots of vulns discovered that were bred out of TLS 1.2 implementations over the years. Keep an eye on anything doing 0RTT in particular, but there's lots more areas for vulnerabilities.
(Score: 4, Touché) by SomeGuy on Wednesday July 17 2019, @01:47AM (1 child)
Aw, crap. Is it time to throw everything away again?
(Score: 0) by Anonymous Coward on Thursday July 18 2019, @01:43AM
Yes. The cops are busy manufacturing registered sex offenders out of anything & everything they can find.
(Score: 3, Interesting) by FatPhil on Wednesday July 17 2019, @07:11AM (9 children)
i.e. "Make your webpage not work on my phone"
That's not progress from my point of view. I already can't see about a half of the internet that looks tempting enough to attempt to load.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by The Shire on Wednesday July 17 2019, @01:08PM (8 children)
TLS 1.2 isn't going anywhere soon - all of the systems under my control support both 1.2 and 1.3 (1.0 and 1.1 are ancient history). I also limit TLS 1.2 to the latest ciphers supporting perfect forward secrecy and the only systems that can't connect are those using Safari 8 or earlier, Windows Phone 8.0 or earlier, or Android versions earlier than 4.4.2. Basically, if you can't connect to any of my services it's probably because you're running crap so old I really don't want to talk to you anyway :P
(Score: 2) by FatPhil on Wednesday July 17 2019, @05:06PM (7 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by The Shire on Wednesday July 17 2019, @07:40PM (5 children)
Assuming you're trying to connect to a server that is locked down to TLS 1.2 and TLS 1.3 using only the latest secure ciphers these are the minimum phone configurations that will work:
Android 4.4.2
Safari 9 / iOS 9
IE11 / Windows Phone 8.1U
If the destination server allows for some of the older less secure ciphers then obviously older phone configs will work. I don't know of anyone who has plans to lock their systems down to TLS 1.3 exclusively so these specifications should hold true for the foreseeable future.
(Score: 2) by FatPhil on Thursday July 18 2019, @09:06AM (4 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by The Shire on Thursday July 18 2019, @01:47PM (3 children)
Maemo, which died almost a decade ago in favor of MeeGo, which died 7 years ago in favor of Tizen, and forked to Mer.
It sounds like you've gotten all the value you're going to get out of that one - maybe it's time to buy something a tiny bit newer.
(Score: 2) by FatPhil on Friday July 19 2019, @08:33PM (2 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by The Shire on Saturday July 20 2019, @02:25AM
Depends on how tech savy you are. If I needed a device like that I would make my own, probably out of a Raspberry Pi 4 with a cellular modem "hat" and running Raspbian which is basically Debian 10 Buster It would be terribly bulky, especially with an extended battery, but it would work and you would have full access to the hardware and most stock debian packages. It would double as an almost pocket sized portable desktop as well.
(Score: 3, Funny) by The Shire on Saturday July 20 2019, @02:29AM
https://wiki.zerophone.org/index.php/Main_Page [zerophone.org]
(Score: 0) by Anonymous Coward on Thursday July 18 2019, @01:19AM
https://www.ssllabs.com/ssltest/viewMyClient.html [ssllabs.com]
(Score: 2) by Fnord666 on Wednesday July 17 2019, @12:16PM (3 children)
(Score: 2) by The Shire on Wednesday July 17 2019, @01:16PM (1 child)
>While the banks say that they need the ability to decrypt connections in their enterprise networks in order to stay in compliance with their own regulations
I read that article and it still doesn't make sense to me. If I connect to a bank server, even using the latest and greatest ciphers, my connection is ultimately decrypted at their end so their servers can handle my requests. So they already have the unencrypted data - they're an endpoint.
If they mean they want to monitor communications of their employees, well that's another matter entirely and not one that is limited to banks - all corporations want this.
(Score: 0) by Anonymous Coward on Wednesday July 17 2019, @01:42PM
It's probably (I'm guessing here) more about the banks being able to intercept and analyse the outgoing connections that originate from within their network to make sure that data isn't being leaked out (they do handle our financial transactions and some of us might be concerned about that data leaking to people who shouldn't have it) and possibly as part of their network intrusion detection systems. While an organization can check the data of their legit applications before/after it is encrypted, there is a bit of an issue when rogue processes are involved.
At the same time, the banks probably also want to encrypt as much as they can while in-transit (even in their own networks) to reduce the chances of sensitive data being intercepted internally and misused. Those financial transactions still need to flow. It's a matter of being sure they only flow where they are supposed to and that as few people (or programs) as possible can actually see the data.
This is in no way an endorsement of the request by the financial industry on this particular issue, only a possible rational. I personally agree that we should not put back-doors into TLS (or any other encryption standard).
(Score: 0) by Anonymous Coward on Wednesday July 17 2019, @10:31PM
ROFL!
http://edition.cnn.com/TECH/computing/9807/27/security.idg/ [cnn.com]
It's gotten to the point where no vendor hip to the NSA's power will even start building products without checking in with Fort Meade first. This includes even that supposed ruler of the software universe, Microsoft Corp. "It's inevitable that you design products with specific [encryption] algorithms and key lengths in mind," said Ira Rubenstein, Microsoft attorney and a top lieutenant to Bill Gates. By his own account, Rubenstein acts as a "filter" between the NSA and Microsoft's design teams in Redmond, Wash. "Any time that you're developing a new product, you will be working closely with the NSA," he noted.