Hacker News Reader

Comment by jrockway | Hacker News Reader

I don't understand why the banks need to change TLS 1.3 to spy on their employees. When I was working at a bank, there were literally no routes from the Intranet to the Internet. Everything went through a proxy that blocked 95% of the Internet. Had to run a proxy server on jrock.us in order to get anything done. (They just bought the list of sites to block, and jrock.us never ended up on it. Blacklisting, very good security technique...)

View on HN

The guy's rationale may be kind of dubious but it's clearly stated: there aren't any tools that do DPI on TLS 1.3 sessions right now.

You don't need to do deep packet inspection when you just MITM all the traffic.

Infrastructure upgrades are required. tls1.3 will be expensive

So let the CEOs have a year of $40M bonuses instead of $50M bonuses. A small price to pay for better security for the rest of us.

MITM introduces significant delays, yet another single point of failure, adds significant risk of leakage. Current DPI are passive, so they have no such problems.

It's technical problem, that can be solved. Dedicated hardware optimized for MITM, probably.

It's already in use, in fact.

Who'd have thought banks would look for ways to save money?

Madness!

Could you elaborate a bit on what kind of passive DPI you can usefully do on an encrypted TLS session? Do you mean something like this? https://arxiv.org/pdf/1607.01639v1.pdf

Deliberately weakening encryption also adds significant risk of leakage, this time on a global scale.

There are absolutely "bump-in-the-wire" intrusion prevention systems with MITM capability.

You're getting mixed up. DPI on TLS sessions requires a MITM. The problem is (apparently) that there are no enterprise-grade MITM solutions that support TLS 1.3

That argument is a non-starter. Surely somebody will build and market such solutions once TLS 1.3 becomes widely used.

The protocol must be finalized before enterprise-grade products can use it, not the other way around.

So here's how I'm imagining the current solution, as implemented at the bank I worked at. Remember first off, there is no route to the Internet from workstations. Everything goes through a regular old HTTP proxy running on a server that accesses both the intra and Inter nets. You send it the host you want ("GET https://example.com/"), it fetches it and returns the HTML. It is nothing more complicated than:

socat tcp-listen:8080,reuseaddr,fork 'system:curl $(grep -m 1 GET | cut -d " " -f 2)'

with a little logging to put Nefarious Sites on your Permanent Record.

> I don't understand why the banks need to change TLS 1.3 to spy on their employees ..... run a proxy server....

You answered your own question. They need it in order to spy on YOU!

Their problem isn't the "good" employees who don't do stuff like that, their problem is exactly people like you who try (and succeed) to bypass things.

Another proxy doesn't bypass the first proxy. I suppose I could have encrypted everything going through the proxy, but didn't.

To be clear, you did have a route to the internet from the intranet, it was just proxied through your bank's proxy server. Presumably you could run TLS through that Proxy Server?

Who doesn't love a game of wack-a-mole?

Why else is OP still employed?

Reply on news.ycombinator.com