Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ETS Isn't TLS and You Shouldn't Use It

eff.org

Post reply on HN
Print view View original

91–100 of 112 posts

Re: ETS Isn't TLS and You Shouldn't Use It

#91

Post by curryst »

cbsmith wrote: post #39
nneonneo wrote: post #38

It’s worth reading the mailing list posts by BITS (the main proponent of ETS) here: https://mailarchive.ietf.org/arch/msg/tls/KQIyNhPk8K6jOoe2Sc... . The replies are pretty informative. You can see here the message in which BITS starts to consider fixed DH keys, which were implemented in ETS: https://mailarchive.ietf.org/arch/msg/tls/3d7TM0g_EdtMzhgmcP... > Tue, 27 September 2016 18:21 UTC > The various suggestions f…

If you think about it, given the retention requirements they have, it's not clear that forward secrecy is useful in that context.

I disagree, it still protects the encryption of information they have in flight.

If they're actually recording the entirety of every TCP stream that comes into the datacenter, how many sets of credentials do you think are stored in that system? And right now, they're all encrypted with a single or small number of keys, that must be available to the system that is storing and parsing this data.

Also, given the breaches that have happened, I keep waiting for there to be a set of regulations from the other side requiring adequate protection and deletion of data. He seems entirely unconcerned with that aspect.

Re: ETS Isn't TLS and You Shouldn't Use It

#92

Post by Dylan16807 »

peterwwillis wrote: post #46

Yeah, let's just make it harder for banks to protect your money so that nobody can figure out your Facebook password in 10 years. EFF: "Everything sent over the network should be a secret! Nobody has a good reason to inspect traffic, it puts users' privacy at risk!" Bank: "We keep trillions of your dollars. Inspecting our own traffic is how we make sure nobody is stealing it. We're a pretty big organization, so this…

> Nobody else was going to

I doubt this pretty strongly.

And if they can put in enough effort to implement a new protocol, they can put in enough effort to log some keys.

They could do it in a much safer manner, too. They could have a TLS extension that appends the session key to the start of every connection, encrypted so that only the inspection device can use it. Then it would be transparent, connections not using it could be easily blocked, and you would still have forward secrecy in case the private key leaked.

Re: ETS Isn't TLS and You Shouldn't Use It

#93

Post by dagenix »

devy wrote: post #78
nneonneo wrote: post #38

It’s worth reading the mailing list posts by BITS (the main proponent of ETS) here: https://mailarchive.ietf.org/arch/msg/tls/KQIyNhPk8K6jOoe2Sc... . The replies are pretty informative. You can see here the message in which BITS starts to consider fixed DH keys, which were implemented in ETS: https://mailarchive.ietf.org/arch/msg/tls/3d7TM0g_EdtMzhgmcP... > Tue, 27 September 2016 18:21 UTC > The various suggestions f…

I've read Andrew Kennedy's email. This line hits the point for me. His argument is reasonable, sometime it's impractical or hard or costly or all the above to upgrade all the systems to meet regulatory compliance and the newer and stricter and safer security standards. It is vital to financial institutions and to their customers and regulators that these institutions be able to maintain both security and regulatory c…

I'm not sure what you are getting at with the NIST example - their recommendations for passwords are pretty reasonable. Maybe their older ones weren't, but, their newer guidelines recommend against outdated ideas such as expiring passwords. (https://pages.nist.gov/800-63-FAQ/#q-b5)

Re: ETS Isn't TLS and You Shouldn't Use It

#94

Post by Dylan16807 »

cbsmith wrote: post #83
jaas wrote: post #65

Earlier quoted context omitted.

Forward secrecy is always useful for two endpoints that want to have a secure exchange of messages. It's a core component of secure transport these days. It's not "useful" if your goal is to intercept and decrypt messages that are supposed to be secure, which is what both regulated entities and baddies want to do. If you don't require forward secrecy you introduce a weakness. The protocol won't distinguish between wh…

> If you don't require forward secrecy you introduce a weakness. The protocol won't distinguish between whether that weakness is being exploited by regulated entities or baddies. Weakness in the protocol, but not necessarily weakness in the system as a whole. This is an environment where part of the trusted nature of the system comes from having a complete record of all the network communication to and from the syste…

Getting rid of forward secrecy doesn't fix the problem of server trust. A compromised server could always use a different private key.

The only way to truly not trust the server is to verify that you can decrypt in real time.

But wait, if you're verifying that you can decrypt in real time, then you could apply that to forward-secret connections too! Have the server send session keys to the logging machine, and make it test them.

It requires a (small) modification to the server, but so does using your own protocol.

Re: ETS Isn't TLS and You Shouldn't Use It

#95

Post by bmm6o »

cbsmith wrote: post #84
deathanatos wrote: post #48

Earlier quoted context omitted.

Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.) > The statement 'Just log it on the end-points' presumes complete access to those end-points and all software running on them. There still has to be some control over the endpoints…

> Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.) When you have communication between two endpoints, over your own network, transmitting session keys OoB doesn't improve the security of your systems, but does increase the comple…

Not to mention that you have to trust the endpoint to ship their session keys. If one "forgets" or the key is "lost in the mail", there's no way to prove that message wasn't problematic.

Re: ETS Isn't TLS and You Shouldn't Use It

#96

Post by deathanatos »

bmm6o wrote: post #95
cbsmith wrote: post #84

Earlier quoted context omitted.

> Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.) When you have communication between two endpoints, over your own network, transmitting session keys OoB doesn't improve the security of your systems, but does increase the comple…

Not to mention that you have to trust the endpoint to ship their session keys. If one "forgets" or the key is "lost in the mail", there's no way to prove that message wasn't problematic.

Assume that non-PFS ciphersuites had remained in TLS: You still have to trust the endpoint to not negotiate a PFS ciphersuite.

Re: ETS Isn't TLS and You Shouldn't Use It

#97

Post by deathanatos »

cbsmith wrote: post #84
deathanatos wrote: post #48

Earlier quoted context omitted.

Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.) > The statement 'Just log it on the end-points' presumes complete access to those end-points and all software running on them. There still has to be some control over the endpoints…

> Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.) When you have communication between two endpoints, over your own network, transmitting session keys OoB doesn't improve the security of your systems, but does increase the comple…

> doesn't improve the security of your systems

Having PFS increases security for your end users. (Minus your storing of the session keys, of course; if whatever you need the session keys for doesn't require you to store them forever, then it still seems like a benefit.) Being able to use standard, well-audited libraries instead of a proprietary piece of "enterprise" code is a benefit.

> Aside from adding a ton of latency and extra performance overhead

The performance of TLS on today's hardware is negligible; CPUs have instructions to accelerate it in hardware.

> you now have a new operational endpoint that you have to trust

No: In the prior TLS 1.2 design, the decryption key was on both the node MitM'ing the traffic, and the actual end nodes dealing with the traffic. The proposed TLS 1.3 alternative does not change that. (Nor does it improve it.)

If your TLS 1.2 was that you terminated at the node doing the MitM'ing, then do the same thing in TLS 1.3.

Re: ETS Isn't TLS and You Shouldn't Use It

#98

Post by DaiPlusPlus »

pjmlp wrote: post #55
uniformlyrandom wrote: post #13

Funny how word 'Enterprise' picks up more and more negative connotation in modern software world. These days, 'enterprise' means outdated, inflexible and intentionally flawed monster of technology.

Did it ever meant anything else? Many that throw jabs at J2EE (written on purpose), never had the joys of trying out xBaseEE, CEE, C++EE (CORBA, DCOM/MTS),...

I think it’s an unfair characterisation. Let’s go with early-2000s “Enterprise” stuff: CORBA and SOAP specifically.

There are these large corporations with a significant investment in their existing infrastructure and systems - and now they all need to make them interop. The mindset is “how do we make our CORBA ERP communicate with their Java CRM without needing to make any changes to either of them?”. Hence SOAP: It packages existing method-call semantics into a HTTP message that will cross a firewall: not even the IT dept needs to get involved to change firewall rules. And they hammered out a working spec within a couple years. That’s impressive considering the slow-moving nature of large, risk-averse enterprises. We now know that REST-is-Best, but it took the industry around 10 years to figure that out, and another 5 years for the tooling and ecosystem to catch up. SOAP was a quick-fix that was needed immediately.

So I’d recharacterise “Enterprise software” as “fits into your existing system and does what you need it to, right now” - and their MC Escher-inspired architecture is a consequence of it needing to support and fit-in to whatever systems were prevalent when their project was started.

It’s not Enterprise software that’s rigid and inflexible - but cutting-edge software that I have more problems with. I was working with Neo4j in 2016 and having issues with security because it didn’t have any built-in security support until last year. I had to change what I was doing to accommodate them, instead of vice-versa.

Re: ETS Isn't TLS and You Shouldn't Use It

#99

Post by AnthonyMouse »

influx wrote: post #56
Animats wrote: post #54

We need a big budget cut in the "homeland security" area. All this interception is not paying off. The biggest "terrorist event" in the US since 2001 was the guy who shot up a gay nightclub in Orlando FL in 2017. That was a solo nutcase; there was no planning chatter to intercept. The Boston Marathon bombing was two brothers. The San Bernardino shooting was a husband and wife. What's discouraging terrorism is the US'…

I completely agree with you, but the counter argument is the only incidents that are getting through are the ones that are solo because the more complicated plots are getting intercepted and disrupted.

> I completely agree with you, but the counter argument is the only incidents that are getting through are the ones that are solo because the more complicated plots are getting intercepted and disrupted.

The problem with this argument is that it can't justify continued spending because that would make it unfalsifiable. We need to spend $450B/year on a bear-repelling rocks because we currently pay for the rocks and there are no bears. And if any bears do appear then we obviously didn't have enough bear-repelling rocks and we need to start spending $900B/year.

If there is a real question as to whether the ~0 bears is a result of the rocks, it's time to cut the bear-repelling rock budget in half and see how many bears there are next year. If it's still ~0 then it didn't need to be as high as it was and it may still be too high.

Re: ETS Isn't TLS and You Shouldn't Use It

#100

Post by paulddraper »

DaiPlusPlus wrote: post #98
pjmlp wrote: post #55

Earlier quoted context omitted.

Did it ever meant anything else? Many that throw jabs at J2EE (written on purpose), never had the joys of trying out xBaseEE, CEE, C++EE (CORBA, DCOM/MTS),...

I think it’s an unfair characterisation. Let’s go with early-2000s “Enterprise” stuff: CORBA and SOAP specifically. There are these large corporations with a significant investment in their existing infrastructure and systems - and now they all need to make them interop. The mindset is “how do we make our CORBA ERP communicate with their Java CRM without needing to make any changes to either of them?”. Hence SOAP: It…

IT ... the glue that halts technology's progress.
Post reply on HN