4 ms·

Middleboxes by design MITM connections. They'll terminate the connection from the client and the server, unencrypt and reencrypt as necessary. That's the whole

Middleboxes by design MITM connections. They'll terminate the connection from the client and the server, unencrypt and reencrypt as necessary. That's the whole point of the troublesome middleboxes. They're not passive listeners. They're active participants, with fragile implementations.

cmckn 6y ago
One does not simply “unencrypt” traffic, though. That’s the whole point of TLS.
- oarsinsync 6y ago
  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.
  - floatboth 6y ago
    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.
    - jlokier 6y ago
      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.
detaro 6y ago
No, "middleboxes" does not just refer to MITM proxies, but a whole slew of things (many of which are broken in various different ways).
tialaramex 6y ago
> Middleboxes by design MITM connections. If only this was true. Almost all of TLS 1.3 would be more straight forward if you were right. As a trivial example, clients could begin by saying they want to speak TLS 1.3 rather than pretending they want TLS 1.2 even though they actually don't. Implementing a security device as back-to-back proxy in which there are two connections, one from a client to the device, then another from the device to the server, would be entirely compliant with the standard, it would trivially enable forward compatibility, and it would make it easier to reason about the provided security features (if any). But it would make them (much) more expensive. The true purpose of such middleboxes is not security, it is to transfer money from gullible customers to the vendor. "Security" is just an excuse, if they thought you'd buy it to prevent COVID-19 that's what they would claim it does. So, a common trick went like this: When a client makes an HTTPS connection, you let it ride, but you passively watch the first few packets they receive. You're looking for the X.509 certificate from the server, which you will then inspect to figure out if it's somebody you trust. If not, you reset the connection and next time they try you intercept, perhaps to display a "Warning: Unauthorized Terror Porn Gay Propaganda Web Site. Your Boss Has Been Notified" message. Notice this doesn't actually provide any security at all, X.509 certificates are public documents, my servers can give you the certificate for Google, or a local hospital, or PornHub, even though I am not in fact Google, a local hospital or PornHub. The middlebox won't know this was bogus because the protocol only proves the server knows the keys for this certificate to the client not a third party eavesdropping. But this "trick" does break TLS 1.3 as originally designed because since a plaintext X.509 certificate is only useful for snooping and provides no security benefit it is now encrypted, and these middleboxes would freak out. So what was done about that? Well they don't actually provide any security so we just sidestepped it. TLS 1.3 claims to be a TLS 1.2 resumption. "Oh you were already talking to this server about something else. I'm sure I must have checked that time and it was fine. On you go" says the middlebox. This worked very well for their actual purpose, as you can see from the revenues of middlebox suppliers.

cmckn 6y ago

One does not simply “unencrypt” traffic, though. That’s the whole point of TLS.

oarsinsync 6y ago
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.
- floatboth 6y ago
  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.
  - jlokier 6y ago
    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.

detaro 6y ago

No, "middleboxes" does not just refer to MITM proxies, but a whole slew of things (many of which are broken in various different ways).

tialaramex 6y ago

> Middleboxes by design MITM connections. If only this was true. Almost all of TLS 1.3 would be more straight forward if you were right. As a trivial example, clients could begin by saying they want to speak TLS 1.3 rather than pretending they want TLS 1.2 even though they actually don't. Implementing a security device as back-to-back proxy in which there are two connections, one from a client to the device, then another from the device to the server, would be entirely compliant with the standard, it would trivially enable forward compatibility, and it would make it easier to reason about the provided security features (if any). But it would make them (much) more expensive. The true purpose of such middleboxes is not security, it is to transfer money from gullible customers to the vendor. "Security" is just an excuse, if they thought you'd buy it to prevent COVID-19 that's what they would claim it does. So, a common trick went like this: When a client makes an HTTPS connection, you let it ride, but you passively watch the first few packets they receive. You're looking for the X.509 certificate from the server, which you will then inspect to figure out if it's somebody you trust. If not, you reset the connection and next time they try you intercept, perhaps to display a "Warning: Unauthorized Terror Porn Gay Propaganda Web Site. Your Boss Has Been Notified" message. Notice this doesn't actually provide any security at all, X.509 certificates are public documents, my servers can give you the certificate for Google, or a local hospital, or PornHub, even though I am not in fact Google, a local hospital or PornHub. The middlebox won't know this was bogus because the protocol only proves the server knows the keys for this certificate to the client not a third party eavesdropping. But this "trick" does break TLS 1.3 as originally designed because since a plaintext X.509 certificate is only useful for snooping and provides no security benefit it is now encrypted, and these middleboxes would freak out. So what was done about that? Well they don't actually provide any security so we just sidestepped it. TLS 1.3 claims to be a TLS 1.2 resumption. "Oh you were already talking to this server about something else. I'm sure I must have checked that time and it was fine. On you go" says the middlebox. This worked very well for their actual purpose, as you can see from the revenues of middlebox suppliers.