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

41–50 of 112 posts

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

#41

Post by setquk »

trhway wrote: post #28
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.

dont forget the enterprise processes (in software for example it would be Agile/Scrum/Lean/Six Sigma/etc.) and the enterprise people deformed by them. Archaeologically speaking it is a whole culture layer :)

Ugh. I’ve been shafted by all of those ideologies.

It turned me grey, bald and cynical aka experienced in every possible way to fuck something up. That turned out to be quite valuable!

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

#42

Post by cbsmith »

kevin_b_er wrote: post #6
Spivak wrote: post #2

So what's the argument from the other side? Going through all this effort to allow PFS to be disabled seems like a ton of work? What's their use-case?

Breaking the security of HTTPS for surveillance and monitoring purposes. The BITS group is formally opposed to secure communications because they want to make it easier to MITM attack the secure communication. They want to make it easier to decrypt communication.

...and they want that for transparency, not for nefarious reasons.

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

#43

Post by Freak_NL »

AndyMcConachie wrote: post #33
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.

It's not a pipe dream if your only goal is to be compliant with a formal rule or regulatory structure that requires it. The reason we need stuff like ETS is really because there are organizations that otherwise could not allow any outbound HTTPS sessions. There are people who need to check off boxes in order to comply with certain rules. Their security reality is not actually all that important.

They control the devices on their side of the firewall, so they can log whatever they want before the data sent enters the encrypted tunnel, and after the data received exits it.

ETS just means they don't have to spend money on replacing their man-in-the-middle monitoring gear with client-local solutions on every workstation and server.

It al seems pretty silly though. Regulators aren't idiots; they know that HTTPS is everywhere now, and that TLS 1.3 means that third parties listening in on connections are going to be thing of the past, so the regulations will change to reflect that.

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

#44

Post by JoshTriplett »

cbsmith wrote: post #42
kevin_b_er wrote: post #6

Earlier quoted context omitted.

Breaking the security of HTTPS for surveillance and monitoring purposes. The BITS group is formally opposed to secure communications because they want to make it easier to MITM attack the secure communication. They want to make it easier to decrypt communication.

...and they want that for transparency, not for nefarious reasons.

MITMing TLS outside the endpoints is inherently nefarious, whether they think it is or not.

If you want to compromise the endpoint, compromise the endpoint. Install your own MITM certificates and terminate the connection in the middle, or install client-side malware. Either way, there should always be a giant warning sign on the client that end-to-end security is compromised.

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

#45

Post by JoshTriplett »

yfiapo wrote: post #8
snek wrote: post #7

Earlier quoted context omitted.

Why can't they just install their own self signed root ca on all their computers and continue MITM it?

Certificate pinning is used by some very common applications and can break a MITM that relies on a self-signed certificate.

Then those applications are correctly getting the behavior they desire: either they get a secure connection or they don't connect at all.

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

#46

Post by peterwwillis »

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 stuff costs a lot of money, and is complex and takes a long time to get right. Can you give us a way to do that in this new TLS standard?"

EFF: "No!! Privacy!!!"

Bank: "Ok... I guess we'll have to make our own standard, then...?"

EFF: "Don't ANYONE use that standard, it will cause REAL HARM!!!!"

Bank: "..... Nobody else was going to... except us....."

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

#48

Post by deathanatos »

rocqua wrote: post #14
Spivak wrote: post #2

So what's the argument from the other side? Going through all this effort to allow PFS to be disabled seems like a ton of work? What's their use-case?

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. Otherwise, what prevents them from negotiating an algorithm in TLS 1.2 that has PFS?

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? (So, it is still encrypted internally, but the node can inspect the data in an authorized manner.) (You seem to address it, but I'm not sure what you mean: yeah, having a centralized box decrypting your traffic means that an attacker that gets access to that can see a lot. But what were you doing in TLS 1.2 w/ a non-PFS ciphersuite that didn't involve a machine w/ the ability to decrypt everything?)

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

#49

Post by ahupp »

kevin_thibedeau wrote: post #37
tlb wrote: post #31

Earlier quoted context omitted.

Either client or server can break secrecy. Server compromise isn't a threat model the client can defend against. For example, the server could simply forward a copy of the whole communication in cleartext to someone, and the client can't know this. In this case, the server is using a predictable number instead of a random one for part of the protocol. Possibly a client could detect this by doing multiple transactions…

The expectation is that the encrypted link is not decryptable by a third party. If that isn't always true in the face of an adversary then claims of forward secrecy for TLS 1.3 are false.

This isn't a 3rd party, it's the server you're communicating with. Just like your own client could do the same.

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

#50

Post by unethical_ban »

How does ETS break MITM for corporate LANs that are trusted CAs on work devices? Why can't a proxy still MITM a connection by terminating the client side, establishing the server side, and that be that?

Also, banks seeing their own corporate traffic is ethical and moral. Whether they need to simply find another way to read all data leaving their network is another piece of the story.

Post reply on HN