ETS protocol does not provide per-session forward secrecy • Hacker News Board

Re: ETS protocol does not provide per-session forward secrecy

#21

Post by rocqua » Sat, Mar 02, 2019, 4:18 PM UTC

galadran wrote: post #16

The real story here is not about security, it's about markets and profit (as always). Currently, there's a huge market in DPI boxes for inspecting TLS traffic, which are often poorly implemented, tied to expensive support contracts and super flakey. These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this…

> These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this is no longer enough, you have to share a secret for every session.

Actually, the boxes can also MitM the entire SSL connection. This just happens to be a much more efficient system. It can easily be turned off without affecting the connection, and it doesn't introduce extra latency. Moreover, this system allows for post-hoc DPI rather than requiring that it happens on-line.

> But wait, the moment you have to have software running on every endpoint, why do you need a special box?

There are reasons beyond 'market dominance' for not wanting to do this on the end-points. End-points are numerous, heterogeneous, occasionally and occasionally difficult to access. This makes actually implementing this system on all endpoints very hard. Let alone keeping all end-points up-to-date.

In general, which sounds like the nicer approach to take: "drop in solution" or "solution that affects all endpoints and needs to support all endpoints".

The discussion is a lot more about 'Is PFS an acceptable loss for getting DPI' with a very large side discussion about whether DPI should even be possible.

Re: ETS protocol does not provide per-session forward secrecy

#22

Post by stefan_ » Sat, Mar 02, 2019, 4:19 PM UTC

dogma1138 wrote: post #14

tastroder wrote: post #7

Earlier quoted context omitted.

Why wouldn't they? That group is trying to standardize a protocol that effectively negates a whole lot of progress and even tried to piggy back on the TLS name. Their stated requirements boil down to snake oil and laziness. If companies or groups thereof want to use security measures that aren't on par with the state of the art and intentionally ignore recent learnings, they of course still have that capability but I…

Because companies in some sectors are required by law to inspect all traffic, while TLS 1.3 doesn’t prevent it in principle it makes it unfeasible to do so in practice given the number of sessions created in a large organization. I work for such organization which actually took a fairly reasonable stance and told BOA to piss off when they asked us to join them in petitioning the IETF to make exemptions to PFS in TLS…

This was never about TLS. Only a stupid person would go "right, we have to decrypt traffic, we control the clients, lets break the crypto".

Surely your IT department already updates the software on client computers. Time to put on their big boy tech pants and decrypt data where the secrets are, on the clients. Then your industry can stop harassing everyone else for bad crypto.

Re: ETS protocol does not provide per-session forward secrecy

#23

Post by zaroth » Sat, Mar 02, 2019, 4:47 PM UTC

zrm wrote: post #13

kabwj wrote: post #9

Earlier quoted context omitted.

There’s no way to guarantee forward secrecy to a client. If regular TLS promises that, the committee is lying and they know it.

There are constructions that provide forward secrecy when both the client and server follow them. This is what TLS aims to provide. If the server doesn't faithfully implement the protocol, of course it will not provide the expected security guarantees. But then it isn't the committee who is lying, it's the server by claiming to implement TLS and then not.

Forward secrecy is mostly a myth anyway when the “ephemeral” keys used to generate the session are kept in memory for weeks, months, or years already (e.g. HAProxy)

Re: ETS protocol does not provide per-session forward secrecy

#24

Post by galadran » Sat, Mar 02, 2019, 5:02 PM UTC

warkdarrior wrote: post #20

galadran wrote: post #16

The real story here is not about security, it's about markets and profit (as always). Currently, there's a huge market in DPI boxes for inspecting TLS traffic, which are often poorly implemented, tied to expensive support contracts and super flakey. These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this…

From a security perspective, it is better to have the endpoints just share the session secret with a DPI box, instead of running the DPI software on the endpoint. If the endpoint in compromised, in the first scenario, the most the attacker can do it not share the session secret. This is easily detectable. In the second scenario, the attacker can pretend that the endpoint-local DPI software is still being run, while c…

Sorry if my point wasn't clear. I do mean that there should be DPI software running somewhere external, the point is just that you don't need dedicated hardware to do it. I completely agree doing everything on the endpoint isn't going to end well.

Re: ETS protocol does not provide per-session forward secrecy

#25

Post by Dylan16807 » Sat, Mar 02, 2019, 5:14 PM UTC

zaroth wrote: post #23

zrm wrote: post #13

Earlier quoted context omitted.

There are constructions that provide forward secrecy when both the client and server follow them. This is what TLS aims to provide. If the server doesn't faithfully implement the protocol, of course it will not provide the expected security guarantees. But then it isn't the committee who is lying, it's the server by claiming to implement TLS and then not.

Forward secrecy is mostly a myth anyway when the “ephemeral” keys used to generate the session are kept in memory for weeks, months, or years already (e.g. HAProxy)

Sure, if you want to pretend that an easily-fixed bug makes security a myth.

Re: ETS protocol does not provide per-session forward secrecy

#26

Post by galadran » Sat, Mar 02, 2019, 5:14 PM UTC

rocqua wrote: post #21

galadran wrote: post #16

The real story here is not about security, it's about markets and profit (as always). Currently, there's a huge market in DPI boxes for inspecting TLS traffic, which are often poorly implemented, tied to expensive support contracts and super flakey. These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this…

> These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this is no longer enough, you have to share a secret for every session. Actually, the boxes can also MitM the entire SSL connection. This just happens to be a much more efficient system. It can easily be turned off without affecting the connection, and…

> Actually, the boxes can also MitM the entire SSL connection. This just happens to be a much more efficient system. It can easily be turned off without affecting the connection, and it doesn't introduce extra latency. Moreover, this system allows for post-hoc DPI rather than requiring that it happens on-line.

Great point! As you say, it scales much worse and introduces additional points of failure though.

> There are reasons beyond 'market dominance' for not wanting to do this on the end-points. End-points are numerous, heterogeneous, occasionally and occasionally difficult to access. This makes actually implementing this system on all endpoints very hard. Let alone keeping all end-points up-to-date.

Absolutely true, but this does lead to a qualititve advantage for open standard / open source solutions where you externalise the costs of additional implementations.

> In general, which sounds like the nicer approach to take: "drop in solution" or "solution that affects all endpoints and needs to support all endpoints".

I don't think this is quite the right distinction, looking at the deployment issues middlesboxes have caused for TLS1.3 and QUIC... I think it might be better phrased as:

"do you want to deploy some static hardware which has to support all endpoint network protocols correctly and upgrade when new protocols come along or do you want to write/use the software for each endpoint you choose to use?"

My point is that software is much cheaper and more flexible (in the long run) than hardware.

> The discussion is a lot more about 'Is PFS an acceptable loss for getting DPI' with a very large side discussion about whether DPI should even be possible.

I agree this is what most of the discussion is about, but I don't think its the real issue. Here are the NIST comments that were posted a few days ago:

https://csrc.nist.gov/CSRC/media/Publications/sp/800-52/rev-...

Check out the NSA's comments on page 21!

> With respect to TLS it seems better to deprecate all non-forward secure cipher suites, not just RSA key transport

This isn't just "we support PFS in TLS1.3", this is actually "please take non-PFS TLS1.2 modes away from people"!

Re: ETS protocol does not provide per-session forward secrecy

#27

Post by Dylan16807 » Sat, Mar 02, 2019, 5:23 PM UTC

rocqua wrote: post #21

galadran wrote: post #16

The real story here is not about security, it's about markets and profit (as always). Currently, there's a huge market in DPI boxes for inspecting TLS traffic, which are often poorly implemented, tied to expensive support contracts and super flakey. These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this…

> These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this is no longer enough, you have to share a secret for every session. Actually, the boxes can also MitM the entire SSL connection. This just happens to be a much more efficient system. It can easily be turned off without affecting the connection, and…

The passive boxes aren't truly drop-in. You need to extract every single private key that will be used for traffic. This is easier than modifying the software to add logging, but not tremendously easier. Endpoints being numerous, heterogeneous, and difficult to access all apply to existing boxes. And whether the endpoint is up to date doesn't matter to either method.

It's not a big burden to install a MitM box either; most places call it a load balancer.

Re: ETS protocol does not provide per-session forward secrecy

#28

Post by dogma1138 » Sat, Mar 02, 2019, 5:41 PM UTC

stefan_ wrote: post #22

dogma1138 wrote: post #14

Earlier quoted context omitted.

Because companies in some sectors are required by law to inspect all traffic, while TLS 1.3 doesn’t prevent it in principle it makes it unfeasible to do so in practice given the number of sessions created in a large organization. I work for such organization which actually took a fairly reasonable stance and told BOA to piss off when they asked us to join them in petitioning the IETF to make exemptions to PFS in TLS…

This was never about TLS. Only a stupid person would go "right, we have to decrypt traffic, we control the clients, lets break the crypto ". Surely your IT department already updates the software on client computers. Time to put on their big boy tech pants and decrypt data where the secrets are, on the clients . Then your industry can stop harassing everyone else for bad crypto.

Decrypting traffic on the client isn’t always possible due to how modern browsers operate.

Decrypting traffic on clients is also much harder due to the multiple types of clients you have and the fact that there is no easy way to MITM every connection the the client.

The security threat model by definition defines clients as untrustworthy hence relying on them for decryption is a flawed approach.

If you are going to be cocky and disrespectful at least be right.

Re: ETS protocol does not provide per-session forward secrecy

#29

Post by jakobegger » Sat, Mar 02, 2019, 6:01 PM UTC

Dylan16807 wrote: post #27

rocqua wrote: post #21

Earlier quoted context omitted.

> These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this is no longer enough, you have to share a secret for every session. Actually, the boxes can also MitM the entire SSL connection. This just happens to be a much more efficient system. It can easily be turned off without affecting the connection, and…

The passive boxes aren't truly drop-in. You need to extract every single private key that will be used for traffic. This is easier than modifying the software to add logging, but not tremendously easier. Endpoints being numerous, heterogeneous, and difficult to access all apply to existing boxes. And whether the endpoint is up to date doesn't matter to either method. It's not a big burden to install a MitM box either…

You can make it less of a hassle by just using the same private key on every endpoint...

Re: ETS protocol does not provide per-session forward secrecy

#30

Post by stefan_ » Sat, Mar 02, 2019, 6:28 PM UTC

dogma1138 wrote: post #28

stefan_ wrote: post #22

Earlier quoted context omitted.

This was never about TLS. Only a stupid person would go "right, we have to decrypt traffic, we control the clients, lets break the crypto ". Surely your IT department already updates the software on client computers. Time to put on their big boy tech pants and decrypt data where the secrets are, on the clients . Then your industry can stop harassing everyone else for bad crypto.

Decrypting traffic on the client isn’t always possible due to how modern browsers operate. Decrypting traffic on clients is also much harder due to the multiple types of clients you have and the fact that there is no easy way to MITM every connection the the client. The security threat model by definition defines clients as untrustworthy hence relying on them for decryption is a flawed approach. If you are going to b…

You control the client. There are companies making many many millions patching Excel to do fancier charts, I'm sure whatever vendor you got now desperately trying to steer the consortiums can instead figure out how to hook the crypto library in the one browser you install on clients.

Yeah, it's a hard problem. If you don't know half the things your clients are doing, it's much easier to pretend all the security conscious stuff will be going through TLS and then we break just that. It's also obviously wrong, as we all learned when they started filling USB ports with glue.

The boxes already rely on the client, unless someone signed another CA=yes certificate.