[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    [TLS] On SNI and middleboxes
From:       Tor Erling Bjørstad <tor=40mnemonic.no () dmarc ! ietf ! org>
Date:       2020-08-13 10:15:47
Message-ID: B6883A09-3605-4D6F-B591-263F9D743AD5 () mnemonic ! no
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]