5 ms·

Can you expand on what middleboxes are?

SamWhited 8y ago
Lots of random routers on the internet (eg. at your ISP, at their transport partners, etc.) were doing all sorts of packet inspection, parsing the plain parts of TLS messages, etc. and then dropping things they thought were invalid (including things as simple as seeing a version number they didn't recognize and dropping the connection). They made TLS 1.3 look sort of like TLS 1.2 resumption which made the protocol much less elegant, but made crappy boxes that had made bad assumptions about what the protocol should look like happy.
- vbezhenar 8y ago
  So currently it's no longer true and TLS 1.3 looks like TLS 1.3, not like TLS 1.2 wrapped something inside? It's good, it was very inelegant.
  - bcaa7f3a8bbc 8y ago
    The end result is a hack. The on-wire format of TLSv1.3 is tweaked, to make the TLS 1.3 handshake resemble TLS 1.2 session resumption requests, which is just enough to make the connection being able to pass broken middleboxes.
tolien 8y ago
https://en.wikipedia.org/wiki/Middlebox https://en.wikipedia.org/wiki/Middlebox The nature of TLS is that nobody in the middle is supposed to be able to read what's encrypted, and that either end can detect if traffic they receive has been modified in transit. Of course this is incompatible with corporate (especially financial) networks where employers have legal/compliance/noseyness reasons to want to make sure their employees aren't doing things they shouldn't (sending corporate secrets to the NYT, having their corporate knowledge siphoned out by malware, spending all their time on Facebook etc.), and repressive regimes (where, for example, Erdogan wants to know if you're a member of the Gulen movement) - Bluecoat and Cisco, for example, do a lot of business in the Middle East and China. They'll typically act as a man in the middle for TLS traffic, re-encrypting traffic using either a compliant root CA or a corporate CA that all employee machines have been made to trust. The nature of Enterprise Software is that these devices will have poor, incomplete or outdated implementations of TLS with the result that, for example, a lot of them didn't know what to do with draft TLS v1.3 traffic and just dropped it on the floor as invalid.
- wereHamster 8y ago
  I'm not buying the argument that middleboxes are incompatible with corporate networks. The IT staff can install their own root certificate on all machines, and then they can decrypt all the traffic they want. What about HSTS? IT can disable that (they have full access to all machines anyways). What about personal devices? Those should connect to a separate network. In essence: if corporate wants to spy on me, they shall provide me with devices that are set up that way, and with that I know I can't have any expectation of privacy. If I'm using my own device, I want TLS to actually provide security and confidentiality. If that means denying my personal devices access to the corporate network, so be it.
  - 3pt14159 8y ago
    Yeah it is a super dumb excuse. The real reason is this: > Our IT team is going to have to do some work and expose that traffic is sent unencrypted (or differently encrypted) to the final hop on the network. I get why IT teams don't want to, especially for huge organizations, but "lol we can MITM TLS" is not acceptable. Terminate the exterior TLS at the network, inspect / log it, then re-black it to the end device. Also, I want to take a second to complain about locally installed certs. I know we all know how they work and everything, but most users don't. The fact that I can see a green lock for google.com when Eve has put a local cert on my machine is really stupid. People check their personal email on their work computers, that's just a fact of life. Their personal email password shouldn't be in some network log somewhere without them understanding that this is possible. There should be a different colour for when trust is different. A blue lock, for example. I know IT has root anyway, but most companies don't install key loggers on their gear or do obviously shady shit, and I think it would benefit users to have a clear demarcation about who they are trusting.
    - stefan_ 8y ago
      Well, they should install keyloggers. Okay, not keyloggers per se, since they are pretty useless, but if you control the software on the device, you can monitor internet activity in a million and one ways, none of which involve breaking the internet. Looking at the Lewandowski stuff, that's what Google does. And for obvious reasons. Just logging internet traffic isn't very useful at all for compliance.
tptacek 8y ago
"Middlebox" is the IETF term for "proxy".
- tialaramex 8y ago
  If only. The biggest problem is that TLS middleboxes don't act like proxies. Proxies would suck in various ways but they're ultimately just a policy decision. TLS offers end-to-end encryption but a true proxy splits things so that you've got two end-to-end channels with the proxy in the middle. This is fine, Alice talks to the Proxy, the Proxy talks to Bob. All fine. But of course proxying sixty employees watching funny cat videos on YouTube needs lots of CPU power, which costs money, which means less profits for the middlebox vendors. So middleboxes pull all sorts of shenanigans rather than actually act as a proxy. For example one trick is pass things through at first, eavesdropping but not actually proxying, then if the middlebox decides things are OK just stop eavesdropping and use a hardware fast path, otherwise drop the connection (wasting resources for both server and client) and when it's retried intercept the retry... If you imagine this is a Black Hat talk you can probably fill in for yourself all sorts of hilarious things the bad guys might do here with this not-a-proxy. So that's why this is a terrible outcome from a security point of view. But from a protocol agility point of view it's worse. The middleboxes make all sorts of arbitrary assumptions in their frantic attempts to avoid doing actual work and a working protocol needs to cope with every one of those assumptions or break those middleboxes. Several big famous middlebox vendors shipped new firmware to make them "ready" for TLS 1.3. What that firmware does is make them TLS 1.2 full proxies. This has two consequences: 1. They now work. Both halves of the proxied connection are TLS 1.2, which works just fine as described above. As a full proxy when a client says "I want TLS 1.3" they can honestly say "Alas I only know TLS 1.2" and so there's no new considerations. So long as they proxy everything. 2. They have intolerably poor performance and will be quietly disabled outside of high threat environments. These boxes haven't anywhere near the brute power needed to really do TLS 1.2 proxy at line rate. Today's web is mostly encrypted, so everything slows to a crawl. The vendor upgrade docs explain how to "mitigate" this slowness by basically disabling the system.

Lots of random routers on the internet (eg. at your ISP, at their transport partners, etc.) were doing all sorts of packet inspection, parsing the plain parts of TLS messages, etc. and then dropping things they thought were invalid (including things as simple as seeing a version number they didn't recognize and dropping the connection). They made TLS 1.3 look sort of like TLS 1.2 resumption which made the protocol much less elegant, but made crappy boxes that had made bad assumptions about what the protocol should look like happy.

vbezhenar 8y ago
So currently it's no longer true and TLS 1.3 looks like TLS 1.3, not like TLS 1.2 wrapped something inside? It's good, it was very inelegant.
- bcaa7f3a8bbc 8y ago
  The end result is a hack. The on-wire format of TLSv1.3 is tweaked, to make the TLS 1.3 handshake resemble TLS 1.2 session resumption requests, which is just enough to make the connection being able to pass broken middleboxes.

tolien 8y ago

https://en.wikipedia.org/wiki/Middlebox https://en.wikipedia.org/wiki/Middlebox The nature of TLS is that nobody in the middle is supposed to be able to read what's encrypted, and that either end can detect if traffic they receive has been modified in transit. Of course this is incompatible with corporate (especially financial) networks where employers have legal/compliance/noseyness reasons to want to make sure their employees aren't doing things they shouldn't (sending corporate secrets to the NYT, having their corporate knowledge siphoned out by malware, spending all their time on Facebook etc.), and repressive regimes (where, for example, Erdogan wants to know if you're a member of the Gulen movement) - Bluecoat and Cisco, for example, do a lot of business in the Middle East and China. They'll typically act as a man in the middle for TLS traffic, re-encrypting traffic using either a compliant root CA or a corporate CA that all employee machines have been made to trust. The nature of Enterprise Software is that these devices will have poor, incomplete or outdated implementations of TLS with the result that, for example, a lot of them didn't know what to do with draft TLS v1.3 traffic and just dropped it on the floor as invalid.

wereHamster 8y ago
I'm not buying the argument that middleboxes are incompatible with corporate networks. The IT staff can install their own root certificate on all machines, and then they can decrypt all the traffic they want. What about HSTS? IT can disable that (they have full access to all machines anyways). What about personal devices? Those should connect to a separate network. In essence: if corporate wants to spy on me, they shall provide me with devices that are set up that way, and with that I know I can't have any expectation of privacy. If I'm using my own device, I want TLS to actually provide security and confidentiality. If that means denying my personal devices access to the corporate network, so be it.
- 3pt14159 8y ago
  Yeah it is a super dumb excuse. The real reason is this: > Our IT team is going to have to do some work and expose that traffic is sent unencrypted (or differently encrypted) to the final hop on the network. I get why IT teams don't want to, especially for huge organizations, but "lol we can MITM TLS" is not acceptable. Terminate the exterior TLS at the network, inspect / log it, then re-black it to the end device. Also, I want to take a second to complain about locally installed certs. I know we all know how they work and everything, but most users don't. The fact that I can see a green lock for google.com when Eve has put a local cert on my machine is really stupid. People check their personal email on their work computers, that's just a fact of life. Their personal email password shouldn't be in some network log somewhere without them understanding that this is possible. There should be a different colour for when trust is different. A blue lock, for example. I know IT has root anyway, but most companies don't install key loggers on their gear or do obviously shady shit, and I think it would benefit users to have a clear demarcation about who they are trusting.
  - stefan_ 8y ago
    Well, they should install keyloggers. Okay, not keyloggers per se, since they are pretty useless, but if you control the software on the device, you can monitor internet activity in a million and one ways, none of which involve breaking the internet. Looking at the Lewandowski stuff, that's what Google does. And for obvious reasons. Just logging internet traffic isn't very useful at all for compliance.

tptacek 8y ago

"Middlebox" is the IETF term for "proxy".

tialaramex 8y ago
If only. The biggest problem is that TLS middleboxes don't act like proxies. Proxies would suck in various ways but they're ultimately just a policy decision. TLS offers end-to-end encryption but a true proxy splits things so that you've got two end-to-end channels with the proxy in the middle. This is fine, Alice talks to the Proxy, the Proxy talks to Bob. All fine. But of course proxying sixty employees watching funny cat videos on YouTube needs lots of CPU power, which costs money, which means less profits for the middlebox vendors. So middleboxes pull all sorts of shenanigans rather than actually act as a proxy. For example one trick is pass things through at first, eavesdropping but not actually proxying, then if the middlebox decides things are OK just stop eavesdropping and use a hardware fast path, otherwise drop the connection (wasting resources for both server and client) and when it's retried intercept the retry... If you imagine this is a Black Hat talk you can probably fill in for yourself all sorts of hilarious things the bad guys might do here with this not-a-proxy. So that's why this is a terrible outcome from a security point of view. But from a protocol agility point of view it's worse. The middleboxes make all sorts of arbitrary assumptions in their frantic attempts to avoid doing actual work and a working protocol needs to cope with every one of those assumptions or break those middleboxes. Several big famous middlebox vendors shipped new firmware to make them "ready" for TLS 1.3. What that firmware does is make them TLS 1.2 full proxies. This has two consequences: 1. They now work. Both halves of the proxied connection are TLS 1.2, which works just fine as described above. As a full proxy when a client says "I want TLS 1.3" they can honestly say "Alas I only know TLS 1.2" and so there's no new considerations. So long as they proxy everything. 2. They have intolerably poor performance and will be quietly disabled outside of high threat environments. These boxes haven't anywhere near the brute power needed to really do TLS 1.2 proxy at line rate. Today's web is mostly encrypted, so everything slows to a crawl. The vendor upgrade docs explain how to "mitigate" this slowness by basically disabling the system.