Comment by yardstick | Hacker News Reader

Comment by yardstick | Hacker News Reader

Parent Full thread

Encrypted SNI was never about hiding which specific articles in Wikipedia you are looking at. It was about hiding the fact you are looking at Wikipedia at all.

There are valid use cases for TLS middleboxes. Anyone having to secure a networks outbound access to only essential services has run into the “I have to allow all of AWS/GCP/Azure/CloudFlare/…” for some critical tool to work.

Options are:

- Allow all out (nope, not secure)

- Allow all to the cloud providers IP range (still terrible)

- Filter on SNI but don’t inspect the payload (better than no security, and doesn’t require plaintext access).

- Full MITM TLS proxy (performance bottleneck, and now we have plaintext access to all your data, which we really don’t want and didn’t previously require to do the filtering).

- Try convince the third party service to run on a handful of static IPs that aren’t behind a global load balancer with access to the rest of the cloud providers customer domains. (Yeah right)

See: Hospitals. Payment Networks. IoT networks.

> There are valid use cases for TLS middleboxes

There are, and always have been, people who are sure that they "need" to do things which don't work because the correct solution would be inconvenient for them. Those people should instead suck it up and accept the inconvenience or, as is more likely, remember they don't "need" this after all considering how inconvenient it is.

It won't suddenly work just because that would be more convenient and it's very annoying technically that we have to keep having this conversation, it's not going to stop being true just because that would make your life easier.

Imho, clients like browsers should just indicate to the user whether their traffic can be intercepted or not (fully encrypted including client hello).

And those clients should offer an option to downgrade the TLS connection to make traffic interceptable.

You can always manipulate your client into making a connection interceptable by installing your own trusted root CA that can then do MitM. That possibility has always been there and didn't go away with TLS1.3.

It's just that many are too lazy to take control of their clients like that. Or they want to do surveillance on clients that aren't theirs to control.

Certificate pinning has made this very difficult/impossible.

We are currently failing legal compliance audits at my work due to this and are having to move cloud things (legal,financial, customer NDA'd data, etc.) back to on-premise because if it. Our cloud HR and payroll systems are really having a tough time staying compliant as the data crosses compliance domains.

Agreed, didn't think of pinning. That does of course make it very difficult.

However, compliance-wise, I'm of the opinion that anything cloud is a bad idea in general. It will just take some time for the bean-counters to realize (if ever).

> And those clients should offer an option to downgrade the TLS connection to make traffic interceptable.

They do, it's called http://

and the other option is installing a root cert, of course.

HSTS is closing this gap, too...

Well, just give up using shared hosting for services that need to be locked down. Ain’t going to happen though, because a different and at times overlapping group of people would be inconvenienced.

None of them are sane options

The only sane security lies at the endpoints

From a network operators perspective, endpoints can be compromised. How can I trust the endpoint will enforce all the security rules required to be attached to the lan? How can I trust they won’t try send data to malicious hosts?

Allow none out. Get your tool vendor to tell you which IP address they have to allow and stand by it. Amazon has "Elastic IPs" where you can lease a specific IP and keep using it even as you change virtual machines. And if you use IPv6 you can have a specific subnet on your account and tell your customers to whitelist the whole subnet.

If your vendor is incompatible with your security desires, fire your vendor or fire your security people. Pick one. You can't eat your cake and have it. (Deliberately reversed so the algorithm will think I'm Ted Kaczynski)

Reply on news.ycombinator.com