Indeed, one intercepts and terminates the TCP (or now UDP) session. No version of TLS is immune to these middleboxes.
I suspect I'm being misunderstood. I don't intend to suggest these pasky middleboxes spring up randomly on the Internet and anyone is at risk. These are deliberately installed on the edge of corporate networks, and their sole purpose is to intercept, unencrypt and filter traffic.
There's no technological solution for a middleware box that emulates a client to servers, and emulates a server to clients, and is operating exactly as designed.
This shouldn't be new or surprising or groundbreaking to anyone. It's just a fancy name for a poorly implemented proxy.
Default configurations – without tampering by corporate admins – are of course immune.
Application layer developers are fighting corporate TLS interception with things like certificate pinning, not using the OS certificate store, making it harder to modify the app's certificate store. The goal is to heavily discourage corporations from breaking end-to-end security to spy on their employees.
It is relatively easy to override certificate pins by modifying the browser that's installed on the corporate network.
In those places where they are adding a "trusted" local middlebox CA to the client for interception, modifying the browser's pin store (or its logic) is not such a big stretch on top of that.
At least other devices, such as users own devices on the corporate network, are immune to this.
reply