undefined | Better HN

0 pointsgaladran7y ago0 comments

> 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"!

0 comments

1 comments · 1 top-level

rocqua7y ago

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

This subject doesn't seem like the most attractive for open-source solutions. Especially when it comes to supporting legacy enterprise systems. This feels more like a case of a consortium of companies creating a standards body.

> looking at the deployment issues middlesboxes have caused for TLS1.3 and QUIC (snip) My point is that software is much cheaper and more flexible (in the long run) than hardware.

I don't think middle-boxes as ETS intends them need hardware acceleration. As such, they could just as easily be implemented in software. This would give the same software-flexibility as modifying endpoints, with the advantage of only needing to support a few systems in your network rather than every single one.

I'd expect the same ossification and bad behavior in software middleboxes as we have had so far. But honestly, I see the same thing happening by supporting this on the end-points.

I'd summarize my position as follows:

If we want to support inspection of traffic by network owners, I see real advantages to selectively breaking forward secrecy for them. But that is a big if. We might be better off just telling those network owners to suck it up and MitM everything.

j / k navigate · click thread line to collapse