Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts
167

TLS1.3 final RFC published.

62 comments
98% Upvoted
What are your thoughts? Log in or Sign uplog insign up
level 1
CCNA RS/CCNA Sec/CCNP in progress60 points · 9 days ago

Worldwide adoption in 10 years...

level 2

People stop calling it SSL in 30 years.

level 3
SPBM Zealot37 points · 9 days ago

I've found the optimist!

level 2

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.

level 1
36 points · 8 days ago

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.

level 2

I work for a cloud service provider. Pushing to have TLS 1.3 supported next month! Not all are terrible.

level 3

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.

level 2
CCNP ACCP3 points · 8 days ago

Sad but true.

level 2

Gotta be FIS or TSYS

level 3

Guess again. Does TSYS even run TLS? :-P

level 4

TSYS would sooner pay off PCI before trying a TLS 1.2 upgrade 😆

level 5

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.

level 2

As far as I'm aware a major flaw was already announced in tls1.3 that allows replay attacks. Soooo...

level 3
CCNP ACCP0 points · 7 days ago

Yes. 0-RTT can permit replay in certain circumstances. However it’s a limited scope replay and can be guarded against by applications.

https://blog.cloudflare.com/introducing-0-rtt/

level 4

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.

level 5
CCNP ACCP1 point · 7 days ago

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.

level 6

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.

level 7
CCNP ACCP1 point · 7 days ago

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”?

level 8

Lol. Good strategy to try and call out my qualifications on the internet. I'm guessing you're just a consultant or something?

level 9
CCNP ACCP1 point · 7 days ago

I guess my little emoji didn’t help out there eh? ‘Twas a joke. Wanna answer my question and be helpful or na?

level 10

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.

level 7

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.

level 1
7 points · 8 days ago · edited 8 days ago

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.

level 2
CCNP ACCP3 points · 8 days ago

SNI is non-authoritative but plaintext.

level 2

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.

https://datatracker.ietf.org/wg/tls/documents/

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)

level 3

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.

level 2
1 point · 7 days ago · edited 6 days ago

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

level 3

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?

level 1
CCNP ACCP16 points · 9 days ago

Oh man I can’t wait to see how decryption vendors respond.

level 2

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?

level 3
CCNP ACCP8 points · 8 days ago

So, not exactly. One of the biggest concerns is decrypting legally protected traffic, since TLS 1.3 encrypts the process.

https://tools.ietf.org/id/draft-camwinget-tls-use-cases-00.html

level 4

Yes exactly. Non-transparent forward proxies will still work just fine.

level 5
CCNP ACCP11 points · 8 days ago

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.

level 6

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.

level 7
CCNP ACCP6 points · 8 days ago

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.

level 6

Don't be so humble.

level 4
2 points · 8 days ago

Which section mentions the legal protections?

level 5
CCNP ACCP3 points · 8 days ago

The section covering SNI and certificate encryption. Also if you’re decrypting you should be aware what categories should not be decrypted.

level 6
2 points · 8 days ago

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.

level 7
CCNP ACCP3 points · 8 days ago

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.

level 8
2 points · 8 days ago

My thoughts exactly. Specifically the medical and financial data

level 3

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.

level 4
CCNP ACCP5 points · 8 days ago

You’ll get offers for DNS and endpoint protection first too. Disabling TLS downgrade will be like pulling teeth.

level 2
ECE3 points · 8 days ago

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

level 3
CCNP ACCP4 points · 8 days ago

Nice. What’s the increased load like

level 4
ECE3 points · 8 days ago

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.

level 5
CCNP ACCP7 points · 8 days ago

What’s your product or company?

level 5
2 points · 8 days ago · edited 7 days ago

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.

level 6
1 point · 7 days ago

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.

level 2

Our enterprise proxy has draft 28 (which became the rfc) already implemented.

level 3
CCNP ACCP1 point · 8 days ago

Cool.

level 1

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 :)

level 2
10+ years, no certs3 points · 8 days ago

Because there have been 28 drafts of this RFC before the last draft became final.

level 3

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,

level 4

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

https://datatracker.ietf.org/doc/rfc8446/

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".

level 5

very cool! I never knew this datatracker existed.

level 1
alphabets2 points · 8 days ago · edited 8 days ago

Can someone TLDR: did they they end up compromising this to enable passively decrypting a connection with the private key or not?

level 2
CCNP ACCP1 point · 7 days ago

They did not.

level 1

We're just moving to 1.2 for PCI compliance.

level 1
-9 points · 8 days ago(0 children)
Community Details

127k

Subscribers

1.1k

Online

###Enterprise Networking Routers, switches and firewalls. Network blogs, news and network management articles. Cisco, Juniper, Brocade and more all welcome.

Create Post
r/networking Rules
1.
Rule #1: No Home Networking.
2.
Rule #2: No Certification Brain Dumps / Cheating.
3.
Rule #3: No BlogSpam / Traffic re-direction.
4.
Rule #4: No Low Quality Posts.
5.
Rule #5: No Early Career Advice.
6.
Rule #6: Educational Questions must show effort.
Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.