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

101–110 of 112 posts

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

#101

Post by pjmlp »

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…

Except for two year pause, all my career has been in the enterprise space.

More often than not, those MC Escher-inspired architecture as you call it, are the result of corporate politics with each department having a say in how their tooling should look like, and bringing in externals to actually build it for them at lowest bid with fixed cost projects.

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

#102

Post by cbsmith »

deathanatos wrote: post #97
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…

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

> Having PFS increases security for your end users.

The context of ETS/eTLS is that you yourself are the end user.

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

Uh-huh. I like that you believe that, but with a lot of HFT systems, even the latency of going from the NIC to the CPU is too much. Adding a hop in between that decodes and then reencodes, the the inherent buffering involved, is way, way too much latency.

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

Yeah... see, that's the part you aren't getting. The old model was also not terminating through a proxy with TLS 1.2. That actually doesn't address the needs of the trusted system.

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

#103

Post by cbsmith »

deathanatos wrote: post #96
bmm6o wrote: post #95

Earlier quoted context omitted.

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.

Yes, but a failure to do so would be considered a compromise, as opposed to a simple network failure.

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

#104

Post by cbsmith »

Dylan16807 wrote: post #94
cbsmith wrote: post #83

Earlier quoted context omitted.

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

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

Yes, but what it solves is that when it does so, you know it has been compromised.

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

No. That is the way to know that you can not trust the server in real time. That isn't the objective. The objective is to be able to, after the fact, prove that you could trust it at that point in time.

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

#105

Post by cbsmith »

avianlyric wrote: post #87
cbsmith wrote: post #83

Earlier quoted context omitted.

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

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

From a systems perspective, they aren't logically different.

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

Yeah, you tell that to the regulator when it becomes clear that trades were being published to a competitor a millisecond before they were being listed.

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

The log everything part, you are totally right about. The "middleware" box that actually is part of the operational path... that's a different story. You want something that watches the system without actually being part of the system.

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

#106

Post by TheOperator »

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

So what would things look like if that homeland security spending was useful and needed? How do we know its okay to cut? Cut the programs and see if people start getting blown up?

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

#107

Post by Dylan16807 »

cbsmith wrote: post #104
Dylan16807 wrote: post #94

Earlier quoted context omitted.

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

> Getting rid of forward secrecy doesn't fix the problem of server trust. A compromised server could always use a different private key. Yes, but what it solves is that when it does so, you know it has been compromised. > The only way to truly not trust the server is to verify that you can decrypt in real time. No. That is the way to know that you can not trust the server in real time. That isn't the objective. The o…

When a server doesn't use forward secrecy, it looks like this:

While it's working correctly (which involves you knowing the private key), you know everything it sends. If it gets compromised, it might keep using the same key and you know what it sent, or it might start using a different key and you'll never figure out what it sent while compromised.

When a server does use forward secrecy, it looks like this:

While it's working correctly (which includes logging session keys), you know everything it sends. If it gets compromised, it might keep logging session keys and you know what it sent, or it might start logging fake keys and you'll never figure out what it sent while compromised.

What meaningful difference is there?

You don't trust the server to tell you what it sent. You record what it sent, and at some point you can check if it decrypts or not. This acts the same whether or not you have FS enabled.

> The objective is to be able to, after the fact, prove that you could trust it at that point in time.

You can verify what it sent, but that doesn't prove it wasn't compromised.

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

#108

Post by tinus_hn »

acdha wrote: post #32
tinus_hn wrote: post #23

Earlier quoted context omitted.

It’s a pipe dream. The webpage or application can easily include its own encryption that can’t be broken by these proxies. If your stance is ‘no opaque data leaves my network’ your only option is an air gap.

Engineering is all about making trade-offs (“perfect is the enemy of the good and all”) and security engineering is no different. The same logic could be used to say that you don't need an edge firewall because each client should have one but it's much easier to simplify the baseline. If nothing else, it would make the remaining traffic stand out more since you wouldn't be spending time auditing normal apps which dec…

A cute excuse until one of your popular sites starts to do this. Now it happens to be that Google hates these proxies as they are a popular target for repressive governments, who technically can’t be distinguished from a snooping ‘enterprise’.

The reality is that world kept turning without these proxies and it will keep turning once they are made obsolete.

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

#110

Post by cbsmith »

Dylan16807 wrote: post #107
cbsmith wrote: post #104

Earlier quoted context omitted.

> Getting rid of forward secrecy doesn't fix the problem of server trust. A compromised server could always use a different private key. Yes, but what it solves is that when it does so, you know it has been compromised. > The only way to truly not trust the server is to verify that you can decrypt in real time. No. That is the way to know that you can not trust the server in real time. That isn't the objective. The o…

When a server doesn't use forward secrecy, it looks like this: While it's working correctly (which involves you knowing the private key), you know everything it sends. If it gets compromised, it might keep using the same key and you know what it sent, or it might start using a different key and you'll never figure out what it sent while compromised. When a server does use forward secrecy, it looks like this: While it…

> What meaningful difference is there?

There would not be a meaningful difference in terms of being able to tell if it was compromised. There would be a meaningful difference that you would now have an operational exposure of the session keys, that fundamentally undermines not just PFS but potentially the encryption protecting the session in general.

> You can verify what it sent, but that doesn't prove it wasn't compromised.

You're right. The semantics of what you are trying to prove isn't so much that it wasn't compromised, but rather to verify that there wasn't some kind of leakage of data from the system, which is a subtly different thing.

Post reply on HN