Dear list, Two of my colleagues, Morten Marstrander and Matteo Malvica, just published a bit of research on using the SNI field to bypass middleboxes for TLS inspection / filtering. They’ve made a nice writeup and PoC (linked below), which also gives some insight into how these solutions are commonly implemented. The work reminds me of several previous discussions on this list, and I hope it may be of interest.
The quick summary is that middleboxes working as a half-open proxy often let the ClientHello through, even for disallowed domains, and that the content of those packets is not necessarily logged and alerted quite as one might expect. So they use the SNI to establish a 2-way channel that is basically invisible to the monitoring solution. Not sure if they’ve also looked into the particulars of TLS 1.3 and ESNI, otherwise that might be a good follow-up topic. I put Morten on CC, he can provide additional technical details. Products from Palo Alto, F5, and Fortinet were successfully bypassed in the lab. I expect that there are additional bug-compatible solutions out there. References: * Blogpost: https://www.mnemonic.no/blog/introducing-snicat * PoC tool: https://github.com/mnemonic-no/SNIcat * Vendor advisory: https://support.f5.com/csp/article/K20105555 * Vendor advisory: https://security.paloaltonetworks.com/CVE-2020-2035 Kind regards, Tor E. Bjørstad _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
