←back to thread

Stop Breaking TLS

(www.markround.com)
170 points todsacerdoti | 2 comments | 10 Dec 25 07:06 UTC | HN request time: 0s | source
Show context
acdha ◴[10 Dec 25 23:41 UTC] No.46225666[source]▶
I really wish more places would enable explicit proxies: if you have a mandate to inspect all traffic, block 443 except to proxy.megacorp.com and configure clients to use it. You lose all of the bugs and security issues caused by the security software—fun fact, Palo Alto _still_ doesn’t correctly implement TLS 1.2!—which as the author points out is basically training users to disable validation or ignore errors. This is so common I’ve seen security people with the usual certs giving advice from ChatGPT to add -k to curl calls, which is especially great when that’s baked into a container which will run on other networks.

One really nice win is troubleshooting: inspection appliances break decades of performance and reliability work which groups like the Linux kernel developers have done, and they make all errors have the same symptom so the security team will now be the only people who can troubleshoot network-level issues. Explicit proxying can’t fix your network but it makes it very clear where the problem needs to be investigated.

replies(1): >>46227746 #
1. rini17 ◴[11 Dec 25 04:40 UTC] No.46227746[source]▶
Are you aware how https proxying works? Clients use CONNECT method and after that everything is opaque to the proxy. So without mitm you only know remote IP address.
replies(1): >>46231712 #
2. acdha ◴[11 Dec 25 14:21 UTC] No.46231712[source]▶
There’s another difference which is what I was referring to: in both cases, your proxy has to forge the SSL certificate for the remote server but in the transparent case it also must intercept network traffic intended for the remote IP. That means that clients can’t tell whether an error or performance problem is caused by the interception layer or the remote server (sometimes Docker Hub really is down…) and it can take more work for the proxy administrator to locate logs.

If you explicitly configure a proxy, the CONNECT method can trigger the same SSL forgery but because it’s explicit the client’s view is more obvious and explainable. If my browser gets an error connecting to proxy.megacorp.com I don’t spend time confirming that the remote service is working. If the outbound request fails, I’ll get a 5xx error clearly indicating that rather than having to guess at what node dropped a connection or why. This also provides another way to implement client authentication which could be useful if you have user-based access control policies.

It’s not a revelation, but I think this is one of the areas where trying to do things the easy way ends up being harder once you factor in frictional support costs. Transparent proxying is trading a faster rollout for years of troubleshooting.