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

81–90 of 112 posts

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

#81

Post by zrm »

kevin_thibedeau wrote: post #29

> This would only require changes to servers, not clients, and would look just like the secure version of TLS 1.3. If a TLS 1.3 client will happily connect to an ETS server that isn't playing by the rules, doesn't that indicate a flaw in 1.3?

> If a TLS 1.3 client will happily connect to an ETS server that isn't playing by the rules, doesn't that indicate a flaw in 1.3?

There is a way to detect this. Record the last ephemeral public key that server used with you. If it uses the same one again, refuse to connect.

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

#82

Post by cbsmith »

funkymike wrote: post #75
cbsmith wrote: post #51

Earlier quoted context omitted.

They don't want to compromise the endpoint. They want to ensure they have a record of all communications to and from the endpoint.

In order to implement ETS they already have to compromise the endpoint to make the TLS 1.3 implementation use static keys, right?

Yeah, but it's a means to an end, not the end.

The assumptions that TLS 1.3 is based around are in direct conflict with the requirements of the secure environment they operate in.

This isn't some evil thing... a cryptographic protocol is a part of a trusted system, and whether it is appropriate for a particular context has to do with the design of the trusted system.

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

#83

Post by cbsmith »

jaas wrote: post #65
cbsmith wrote: post #39

Earlier quoted context omitted.

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

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 system, and an ability to audit that data offline.

That context is in conflict with the objectives of PFS & TLS 1.3 in general. So, understandably, they came up with another solution that fit the design goals, and understandably, rather than reinvent the wheel, they came up with a way to tweak existing solutions to fit their design goals.

> You don't need to weaken TLS in order to do what the regulated entities want to do - you just need to do the retention on the endpoints.

Yeah, you're not understanding the system. The whole point is to NOT trust the endpoints to be reliable narrators of what they are transmitting over the network (which makes sense, because if they are compromised, they wouldn't be). TLS is designed to allow two trusted endpoints to communicate, but the goal/context for eTLS is to have a full audit of communications into and out of an untrusted node. That's presumed from the start; TLS's goals therefore aren't helpful.

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

#84

Post by cbsmith »

deathanatos wrote: post #48
rocqua wrote: post #14

Earlier quoted context omitted.

If your stance is: No opaque data leaves my network Then this is the only way you can have outbound HTTPS connections. And for e.g. a bank, certain legal firms, or any company that has a lot of sensitive data they either don't want to be leaked, or at least want the option of detecting when it is leaked, that is a somewhat reasonable stance. In the case of banks, this is needed for regulatory compliance regarding ins…

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

> And I am not sure if you're attempting to address this, but instead of terminating at a more edge-ish node, why not just decrypt and re-encrypt there?

Aside from adding a ton of latency and extra performance overhead, you now have a new operational endpoint that you have to trust. That doesn't fit the trust model. They key point here is the data is getting logged and then decrypted offline, by a totally separate system.

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

#85

Post by cbsmith »

excalibur wrote: post #27
hsk0823 wrote: post #5

Earlier quoted context omitted.

There's a whole IT market segment around TLS decryption for corporate LAN. Basically corporate MITM that will decrypt TLS at the gateway / firewall, and with currently used TLS standards, will then re encrypt the traffic back to the client so the browser thinks it has a legit connection. It's used to scan packets for intrusion detection, for malware, to track for data loss like the article talks about.

But you don't NEED to kill forward secrecy to do that. TLS 1.3 doesn't seem to be a problem for the anti-malware, IPS, or even DLP use cases. You just need to decrypt, inspect, and re-encrypt traffic at the firewall, using a CA cert trusted by your clients. The problem is lazy organizations that just want to passively collect all of the encrypted traffic and then decrypt it later at their leisure, which smells much m…

Yeah, you're missing the security model.

The point is to have the decryption done on a system that is isolated from the production environment (and is consequently isolated from security compromises).

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

#86

Post by avianlyric »

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…

> as a financial institution you simply cannot have your IT system incompliant

This just isn’t true, or rather “compliance” tends to be quite fuzzy.

Regulators generally expect you follow recommendations from places like NIST. But it’s not a hard requirement, you just need to explain why deviating is better.

Unfortunately most fincial institutions trip up at the “explain why it’s better” bit. Either because they aren’t competent enough, or (more likely) can’t be bothered.

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

#87

Post by avianlyric »

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…

> The whole point is to NOT trust the endpoints to be reliable narrators of what they are transmitting over the network

That’s not the goal though. You’re not trying to monitor the systems themselves, you’re trying to monitor the people using the system.

A financial regulator doesn’t give a crap what your system does, or how it does it. They only care that they can blame (and potentially prosecute) an actual person if it goes wrong.

Using middleware boxes makes this easy. Not need to actually modify the software your using to create proper audit logs, just log everything and figure it out later.

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

#88

Post by rcchyssser »

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'…

Lol if the Feds need a warrant to access gmas compromised email, we are all screwed.

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

#89

Post by zamadatix »

avianlyric wrote: post #86
devy wrote: post #78

Earlier quoted context omitted.

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…

> as a financial institution you simply cannot have your IT system incompliant This just isn’t true, or rather “compliance” tends to be quite fuzzy. Regulators generally expect you follow recommendations from places like NIST. But it’s not a hard requirement, you just need to explain why deviating is better. Unfortunately most fincial institutions trip up at the “explain why it’s better” bit. Either because they aren…

If something was better for the entire industry one would think the compliance recommendations would be the topic of discussion, not explaining why it needed to be done differently individually.

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

#90

Post by Dylan16807 »

yfiapo wrote: post #15
Legogris wrote: post #11

Earlier quoted context omitted.

Do you have any example of such applications that would be used by a bank?

I don't work for a bank so I can't speak definitively to their applications. A few sample applications I see listed as certificate pinned in Netskope (a CASB) though include: Adobe Creative Cloud Amazon Work Spaces Docusign GitHub Google Drive GoToMeeting iCloud Microsoft Office 365 Outlook.com Microsoft Skype for Business Salesforce.com Note this typically refers to native applications and plugins which also connect…

Isn't that exactly the same between TLS 1.2 and 1.3? They won't have the private keys for google drive. How are those handled today?
Post reply on HN