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

31–40 of 112 posts

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

#31

Post by tlb »

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?

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 and seeing if a number gets reused, but that seems outside the scope of TLS.

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

#32

Post by acdha »

tinus_hn wrote: post #23
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…

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 decode cleanly and it's highly likely that someone trying to circumvent such a system would be required to do things which stand out more than routine usage.

As a simple example, an organization which does that kind of monitoring is unlikely to allow users to install arbitrary applications or visit any site on the web. With a standard setup, someone trying to exfiltrate data could just hit a popular site like Github, Gmail, Dropbox, etc. but if they need to use some custom encryption or steganography code they're either forced to install it somewhere far less common (i.e. more likely to stand out) or installing something locally where client monitoring can report an unusual browser extension or application.

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

#33

Post by AndyMcConachie »

tinus_hn wrote: post #23
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…

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.

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

#34

Post by rocqua »

tinus_hn wrote: post #23
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…

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.

You can ban the use of such applications a lot easier than you can ban HTTPS. This means that simply using those tools is grounds for legal action, which might suffice. Especially if the concern for confidentiality is not for internal reasons, but for legal reasons.

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

#35

Post by dcbadacd »

yfiapo wrote: post #12
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?

The other side of the argument is frequently discounted and as an IT security person myself I understand that. However, there is a real challenge for companies who deal with large amounts of very sensitive data. To be able to effectively monitor for data loss it makes a lot of sense to be able to monitor the connection points between your protected network and outside networks. The move to all traffic being encrypted…

> Or do you employ an official to help pack the belongings of each individual who you think may eventually cross the border?

Without telling the person who's things were packed that they were packed by the official.

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

#36

Post by dcbadacd »

KingMachiavelli wrote: post #21
throwaway2016a wrote: post #9

Earlier quoted context omitted.

All of those require your computer to trust a new Certificate Authority or you will get warnings all over the place. If there is a company that claims to be able to do it without trusting the CA or producing warnings I would love to see it. (seriously, I actually would love to see that). And if you are in a corporate environment using a company computer you forfeit your privacy anyway. You can always go somewhere els…

Why? If you have the private key you can decrypt TLS traffic if forward secrecy is off. Which is why forward secrecy exists, to prevent captured encrypted sessions form being decrypted out-of-band with, presumably, comprimised private keys. The issue is that TLS 1.3 deprecates the key exchange that makes this possible, essentially making (perfect) forward secrecy a requirement since the only inlcuded ciphers do so. T…

It's deceptive to call out-of-band MITM not MITM, it's still MITM just covert. TLSv1.3 forcing it to become glaringly obvious is exactly what should be happening.

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

#37

Post by kevin_thibedeau »

tlb wrote: post #31
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?

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.

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

#38

Post by nneonneo »

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 for creating fixed/static Diffie Hellman keys raise interesting possibilities. We would like to understand these ideas better at a technical level and are initiating research into this potential solution.

The core argument made by BITS is that they need a way to log TLS traffic such that it can be decrypted later, in order to provide data retention in line with regulations. While this could be done by logging all ephemeral keys generated by the servers, BITS argues that this isn’t practical due to their use of dedicated packet logging hardware that is key-ignorant. Instead they want to use non-forward-secret TLS so they can decrypt past messages easily. Their beef with TLS 1.3 is that it removes all non-FS key exchange methods, and further that by explicitly obsoleting TLS 1.2 as a standard pushes them to have to adopt 1.3 in an enterprise environment (or risk current/future regulatory scrutiny over their use of an obsoleted standard). Hence why they want to develop a competing, active standard with non-FS key exchange.

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

#39

Post by cbsmith »

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.

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

#40

Post by cbsmith »

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.

The expectation is that the encrypted link is not decryptable by a third party if both parties are implementing the protocol in good faith.
Post reply on HN