Worldwide adoption in 10 years...
People stop calling it SSL in 30 years.
I've found the optimist!
Huh... yes, considering that some smaller vendors (Here’s looking at you, reporting platform vendor with a cartographically named config app) don’t full support TLS1.2 (Oh! You mean you want TLS 1.2 for SMTP sending? That’s a feature request!) I would say 10 years to global acceptance is optimistic.
Huh. I know a bank cloud services provider that is adopting TLS1.2 next month...
Assuming 1.3 survives without some magic mathematical flaw found, we'll see widespread adoption sometime around 5 years after major flaws are found in 1.2.
I work for a cloud service provider. Pushing to have TLS 1.3 supported next month! Not all are terrible.
Not saying they're all terrible, and the one I'm picking on is better than some of their clients I'm aware of.
My point was just that an organization responsible for outsourced network security of banks across the country is just now adopting TLS 1.2. In contrast, Facebook went full bore TLS 1.2 as default in 2013. One desperately needs the public to trust them, the other has the public's trust and Federally backed insurance for when they fuck up.
Sad but true.
Gotta be FIS or TSYS
Guess again. Does TSYS even run TLS? :-P
TSYS would sooner pay off PCI before trying a TLS 1.2 upgrade 😆
It's been some time now, but last I dealt with them, they were prepping a legacy system a client used to move to encrypted network traffic at all. The previous security was provided by dedicated t1 leased line while sending in the clear.
As far as I'm aware a major flaw was already announced in tls1.3 that allows replay attacks. Soooo...
Yes. 0-RTT can permit replay in certain circumstances. However it’s a limited scope replay and can be guarded against by applications.
And developers have always been so good at guarding against vulnerabilities in their applications? All replay attacks are limited in scope. It doesn't make them less a problem.
A 0-RTT replay doesn’t give you entire session access, for starters.
Also, vendors and applications already have a variety of replay protections in place because this type of replay happens naturally due to network conditions and could be dangerous. So it’s protected against.
Nothing is going to be invulnerable or perfect. 1.3 is far better than 1.2. Thems the facts.
Absolutely. But not what we are discussing. We are discussing vulnerabilities being a factor of change. While true it doesn't mean the next step isn't also going to have vulnerabilities.
How long has it taken for orgs to depart from SMBv1? LANMAN? TelNet? Their successors SMBv3, NTLM/Kerb, and SSH also having long standing vulnerabilities. It's a decision of operational risk versus exploit risk with other controls being considered.
I feel like you’re saying a lot of nothing. You wouldn’t happen to work on the business side do you? :-P
Can you explain what you mean by “operational risk v exploit risk”?
Lol. Good strategy to try and call out my qualifications on the internet. I'm guessing you're just a consultant or something?
I guess my little emoji didn’t help out there eh? ‘Twas a joke. Wanna answer my question and be helpful or na?
It was more a tension cutter for you. What does operational usually mean? Lights on. What does expoitation mean? Acting on a threat. Controls? Detection/Protection security.
Change come slowly because normally organizations have to adjust for risk of outages over time. Unless we are facing an unpatchable zero day, it's safer from a continuity stand point to adopt slowly.
Copy machines! bane of my existence, I spend time turning on SMB1 and rebooting file servers because somebody's new print provider is only capable of scanning to SMB1. And it's not like the printer tech knows, I have to figure it out from spec sheets or pcaps.
So forgive my ignorance, but where does this leave encrypted SNI? Is this the nail in the coffin, or is it forthcoming? I'm having a hard time keeping track of exactly what the status is.
SNI is non-authoritative but plaintext.
The IETF is organised into Working Groups (this might be familiar to you if you've worked with any sort of Standards Organisation, although the IETF is deeply unlike any organisation most people have dealt with and arguably isn't an "organisation" at all) which each deal with a particular subject
The TLS WG deals with no only the Transport Layer Security protocol itself for which this new RFC is the latest standard, but also the optional extra features for that protocol, and related protocols or sub-protocols. Here's a list of what they "own", including 10 "Internet drafts" which are documents that might some day become RFCs, and at the bottom there's a list of documents that currently aren't owned by the TLS WG but which it might plausible choose to "adopt" and move into the first list.
A few months back, Eric Rescorla (it's his name at the top of the TLS RFC) was despairing that encrypted SNI wasn't going anywhere, you can see the last draft explaining what they believed was needed, but without proposing any way to achieve it, in the short list of adopted drafts near the top. But more recently Eric has hacked something together that might work, and that's in the related drafts list near the bottom.
If you have relevant skills you absolutely can and should pile in to help work on this, the IETF is a bit scary because it's old and famous, but if you have those skills and want to contribute they will make you welcome. There are no memberships and thus no membership fees (the IETF periodically materialises as a one week meeting in various cities around the world and attending those meetings isn't free, but it's also by no means necessary in order to contribute, whereas writing insightful emails very much is)
Thank you for the reply and the link to the datatracker (which I was unaware of). I'm still confused as to how the outlined method would not be easily spotted and blocked, but I will reread it and see if it sinks in. Thank you again.
When this does happen, bottom feeder URL filtering technologies like Cisco Umbrella will shit their pants. DNS based security will be out the door and you’ll be forced to go L7 and decrypt SSL/TLS.
Edit: added TLS
Maybe (as in the Chinese farmer parable)... lots of possible downstream possibilities when that telemetry is gone...Will they end up being better or worse?
Oh man I can’t wait to see how decryption vendors respond.
By updating their documentation to show you how to configure forward proxies and install your enterprise CA so you can still MITM and decrypt TLS 1.3?
So, not exactly. One of the biggest concerns is decrypting legally protected traffic, since TLS 1.3 encrypts the process.
Yes exactly. Non-transparent forward proxies will still work just fine.
I think we’re missing each other here. Merely saying “It will work.” is simplistic. Of course inbound and outbound explicit will work. That’s not the issue.
Decryption load will dramatically increase. The ability to determine categories requiring non-decryption will be extremely challenging. Visibility of E-W traffic will disappear. These are things decryption vendors are going to have to deal with. Over the last few years they’ve started shifting to endpoint and meta analysis. Either way, it’s a huge impact to existing operations and middleboxes. Also that IETF draft I linked probably is a better explanation. I’m not too smart.
Hey, I work for a large proxy vendor and we’ve been involved in the development of 1.3 for the past years. It’s not like the drafts are secret. Our current release already fully supports draft 28, which then became this rfc. Yes load increases, but then 1.3 adaption will take years.
Yes. I understand how the process works. I don’t believe I implied, and certainly didn’t state, vendors are just not going to do the standard.
I’m not sure if maybe I’m not being clear with the words I use. At no point did I say “lol decryption is broken forever”. It’s wildly fascinating that documented and discussed concerns or limitations get me downvoted.
Don't be so humble.
Which section mentions the legal protections?
The section covering SNI and certificate encryption. Also if you’re decrypting you should be aware what categories should not be decrypted.
Ah I see now. Ya, we've been looking into decryption. In my opinion we will run into legal issues, but all I can seem to find is that if you are doing it on company property and company network it can be decrypted.
There are various legal protections on different data types (medical, financial, some types of merchant related data). It depends on jurisdiction. Your organizations legal team should be consulted for sure.
My thoughts exactly. Specifically the medical and financial data
It'll inevitably take them awhile to support. I mean, it's not like it's just adding one more package to a linux VM you're paying hundreds to thousands a month for the support of. I expect recommendations to ban TLS 1.3 first.
You’ll get offers for DNS and endpoint protection first too. Disabling TLS downgrade will be like pulling teeth.
We have been decrypting PFS for a couple years already. There are a lot of vendors that haven't taken the time to figure out how to handle the ephemeral session keys which makes it easier for me to sell my own products. =D
Nice. What’s the increased load like
No increased load on the network itself. Without revealing too much information, the solution is entirely passive and out-of-band so it doesn't create any choke points for performance.
What’s your product or company?
This has me interested. Every vendor I know sayingthey can handle PFS requires a full inline proxy. I've never heard of a passive out-of-band solution that does this. DM the product/vendor?
Edit: no DM received, not surprising.
Extrahop can do passive out of band replays. It has to be reverse proxy, agent based (server side), and they store all of the ephemeral keys. I believe it allows them to do replays as well.
In reverse proxy and forward proxy for that matter, TLS and ciphers such as EDCHE are processor intensive that’s why everyone who knows what they are doing, do it in hardware and not CPU. Intel Has a chip, I cannot recall the name. Cavium Nitrox does it as well, their latest will do TLS 1.3 and 1.2 FWIW in hardware as well. I forget the exact trade off but what you can do with Nitrox would take about 20-25 modern CPUs.
Our enterprise proxy has draft 28 (which became the rfc) already implemented.
I'm relatively new at reading rfcs so forgive my ignorance, but why say "final rfc?" The rfc is labeled proposed standard so that means it could still become a "Internet standard," and thus the word "final" could be applied? I don't want to argue semantics just want to make sure I'm not missing anything... I've been studying the standards track recently :)
Because there have been 28 drafts of this RFC before the last draft became final.
Thank you for helping me work this out. Is there a particular place where you can see that number, 28? I looked all over this RFC and couldn't find anything.
Also, it was my understanding that they recently got rid of the concept of "drafts" so now there are only proposed standards and standards.
Here is the wikipedia article I learned this from: https://en.wikipedia.org/wiki/Internet_Standard I know wikipedia isn't always the most trust worthy but in this case the article references RFC 6410
>In October 2011, RFC 6410 merged the second and third maturity levels into one Draft Standard. Existing older Draft Standards retain that classification. The IESG can reclassify an old Draft Standard as Proposed Standard after two years (October 2013)
Again thanks for your help,
So, from that article you linked:
A specification that is to become a Standard or part of a Standard begins as an Internet Draft, and is later, usually after several revisions, accepted and published by the RFC Editor as an RFC and labeled a Proposed Standard.
Anybody can write a Internet Draft (abbreviated ID). The IETF Working Groups sometimes "adopt" a draft, often one written by their own members for that purpose, but in principle they can "adopt" any draft, and, if they decide to do so, they can drive that ID all the way from being written by perhaps one Redditor, to the RFC Editor Queue and then an RFC with "Proposed Standard" written on it.
If you look at the details in the IETF's tracker for RFC 8446 you'll see that as an ID it went though 28 versions, the last being draft-ietf-tls-tls13-28
It was also, a very long time ago now, named draft-ietf-tls-rfc5246-bis where "bis" is a French word you'd use like adding an "A" in an English address, so RFC5246-bis is the thing that comes after RFC5246 (TLS 1.2) the same way "14 bis Rue Royale" is the next front door after "14 Rue Royale".
very cool! I never knew this datatracker existed.
Can someone TLDR: did they they end up compromising this to enable passively decrypting a connection with the private key or not?
They did not.
We're just moving to 1.2 for PCI compliance.
Routers, switches and firewalls. Network blogs, news and network management articles. Cisco, Juniper, Brocade and more all welcome.