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

71–80 of 112 posts

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

#71

Post by Animats »

skywhopper wrote: post #66
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'…

The retention requirements needed by the enterprise consumers are not terrorism related. Also, cutting the government's budget would not impact the cost of compliance to corporations.

The retention requirements for enterprises can be satisfied by transaction logging where the transactions are done. You don't need to break into TLS.

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

#73

Post by hsk0823 »

Animats wrote: post #71
skywhopper wrote: post #66

Earlier quoted context omitted.

The retention requirements needed by the enterprise consumers are not terrorism related. Also, cutting the government's budget would not impact the cost of compliance to corporations.

The retention requirements for enterprises can be satisfied by transaction logging where the transactions are done. You don't need to break into TLS.

No it can't. We're literally talking about monitoring and capturing packets for data loss prevention, something that can't be done if the packets are encrypted.

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

#74

Post by funkymike »

Freak_NL wrote: post #43
AndyMcConachie wrote: post #33

Earlier quoted context omitted.

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

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

Doesn't it still require altering the TLS implementation to use the static DH keys instead of following the TLS 1.3 standard of using random keys?

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

#75

Post by funkymike »

cbsmith wrote: post #51
JoshTriplett wrote: post #44

Earlier quoted context omitted.

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.

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?

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

#76

Post by adrianmonk »

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

Sure, ~20 years ago Sun Microsystems used to sell some "Ultra Enterprise" servers which offered nice reliability features like redundant power supplies and a backplane and slot setup where you could install several CPU/memory boards or I/O boards.

In comparison to some of their other hardware, these servers were more suited to organizations with more demanding needs like minimizing downtime or having lots of compute power or configuration flexibility.

But of course people quickly realized that a key characteristic of actual enterprise computing is large budgets, so it almost immediately turned into a game of labeling things with the word "enterprise" in hopes of vacuuming up as much of that money as possible.

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

#77

Post by cbsmith »

cesarb wrote: post #60
cbsmith wrote: post #52

Earlier quoted context omitted.

...and in this context they aren't compromising it. They're just sharing their keys so that another component, all part of the same trusted system, can also decrypt the traffic.

Sharing the key allows more than just decryption; it also allows undetectable modification of the traffic. A protocol which allowed third-party decryption but not modification would have been designed differently.

In this case the key is used by a system that is reading a log of the archived traffic. It has no direct network connectivity to the production traffic. I think we can safely say it isn't modifying the traffic... in fact, that's a requirement for the security apparatus.

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

#78

Post by devy »

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 compliance 
     during and after the transition from TLS 1.2 to TLS 1.3.
One example of that is the NIST's recommendation on password policies. Most of the time the regulatory mandates are outdated and it's hard to bring them up to speed, in the mean time, as a financial institution you simply cannot have your IT system incompliant, even that means having a less security practice.

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

#80

Post by TeMPOraL »

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.

Also "industry standard" in this industry means "lowest-common-denominator garbage, for which you can find a lot of cheap programmers".
Post reply on HN