4 ms·

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,

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 is no longer enough, you have to share a secret for every session. This necessitates some kind of software running on each endpoint to transmit these secrets. But wait, the moment you have to have software running on every endpoint, why do you need a special box? Why not do it all in software? This represents a huge threat to the DPI market. No box means no lock in, no mandatory upgrades, no support contracts. Sure, software can have these things too, but it's inherently a more open, competitive market where you are vulnerable to open source invasion. Solutions like eTLS are just a last ditch gnashing of teeth from DPI box sellers, trying to prevent a lucrative market from disappearing. Once you move everything to software: a) competition in general gets better and b) open source starts to take over, c) security will improve.

natch 8y ago
Had to duckgo it: DPI = deep packet inspection.
warkdarrior 8y ago
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 completely going around it.
- galadran 8y ago
  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.
rocqua 8y ago
> 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.
- galadran 8y ago
  > 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-2/draft/documents/sp800-52r2-draft2-comments-received.pdf 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"!
watersb 8y ago
DPI = Deep Packet Inspection

natch 8y ago

Had to duckgo it: DPI = deep packet inspection.

warkdarrior 8y ago

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 completely going around it.

galadran 8y ago
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.

rocqua 8y ago

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

galadran 8y ago
> 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-2/draft/documents/sp800-52r2-draft2-comments-received.pdf 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"!

watersb 8y ago

DPI = Deep Packet Inspection