4 ms·

Just read SamWhited's comment. Some middleboxes act as Man-in-the-Middle and inspect the plaintext, this is how those middleboxes were implemented in the past,

Just read SamWhited's comment. Some middleboxes act as Man-in-the-Middle and inspect the plaintext, this is how those middleboxes were implemented in the past, and still, how they are going to be implemented in the future. The middlebox disaster I mentioned is not necessarily about those boxes, but other boxes which do not decrypt traffic, but instead try to inspect visible fields and metadata in packets and protocols. One basic example is inspecting the SNI field to know the domain name you are visiting. Many of these middleboxes are poorly implemented with hardcoded assumptions (but compatible with existing implementations), not fully in compliance with the standard. They also like to reject or drop the connection if they cannot successfully parse the protocol as expected. After TLSv1.3 is released, guess what? Their assumptions don't work anymore, and they start rejecting every TLSv1.3 connection. The final solution is some tweaks of the wire format, to make it seems to be TLSv1.2 in middleboxes' perspective. In fact, this is not really a new problem - many firewalls are designed to reject things they don't understand, because it was believed to be the defense-in-depth. This was the problem that almost killed TCP ECN 20 years ago, and officially condemned by the IETF (https://tools.ietf.org/html/rfc3360 https://tools.ietf.org/html/rfc3360), but history repeats... This blogpost from CloudFlare gives an extensive introduction to this issue: https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet

ethbro 8y ago
I understand the non-compliance network appliance issue and hence the wire hacks for 1.3. I'm asking about forced TLS-stripping's (e.g. by root certs) effectiveness against malware encryption. If you're laying app level encryption on top of a connection... what are the boxes inspecting? Or are malware authors just really bad at network encryption and don't do any complex stuff?
jabl 8y ago
Thanks for the cloudflare link, that explains it pretty well. IIRC there was another middlebox kerfuffle related to some vendor complaining that removing non-PFS ciphers(?) would destroy their business. IIRC the initial response was to shove it, and for legitimate purposes like employee monitoring in enterprises there are ways around it (installing middlebox certs on managed clients?). Whatever happened to this (or was this even what the argument was about?)? Did the IETF bow to these demands or not?

ethbro 8y ago

I understand the non-compliance network appliance issue and hence the wire hacks for 1.3. I'm asking about forced TLS-stripping's (e.g. by root certs) effectiveness against malware encryption. If you're laying app level encryption on top of a connection... what are the boxes inspecting? Or are malware authors just really bad at network encryption and don't do any complex stuff?

jabl 8y ago

Thanks for the cloudflare link, that explains it pretty well. IIRC there was another middlebox kerfuffle related to some vendor complaining that removing non-PFS ciphers(?) would destroy their business. IIRC the initial response was to shove it, and for legitimate purposes like employee monitoring in enterprises there are ways around it (installing middlebox certs on managed clients?). Whatever happened to this (or was this even what the argument was about?)? Did the IETF bow to these demands or not?