To do TLS proxying properly, you need to verify the cert on 'trusted' domains. SNI is not verified. Thus, a proxy using SNI to identify the host would be circu

To do TLS proxying properly, you need to verify the cert on 'trusted' domains. SNI is not verified. Thus, a proxy using SNI to identify the host would be circumvented by using facebook.com or www.bankofamerica.com as the name in SNI and just ignoring SNI at the malicious endpoint. As TLS 1.3 encrypts the certificate, you can't check the certificate without actually MitMing the connection. Thus, whitelisting isn't possible in TLS 1.3. Unless you trust the (attacker controlled) SNI, at which point, why even do TLS proxying. Note that according to the article, many TLS 1.2 proxies don't actually verify the certificate by default, which means my masquerade as facebook.com ploy would also work against them. This can be done by simply using a false 'common name' field in the cert. The defense against this is easy, it is the certificate validation all browsers do. Apparently, these middle boxes by default do not use this validation. This is generally seen as a compelling argument against the deployment of TLS proxies. The argument being that they are 'security theater' as opposed to actual security, on account of them being easy to spoof.