3 ms·
Note that nothing about TLS 1.3 prevents a Proxy whose CA certificate is installed by the user from MitMing a TLS 1.3 session. This is also why certificate pins
by rocqua 9y ago
Note that nothing about TLS 1.3 prevents a Proxy whose CA certificate is installed by the user from MitMing a TLS 1.3 session.
This is also why certificate pins are ignored when a cert is signed by a manually installed certificate.
What TLS 1.3 does appear to do is make it harder to optimize this proxying, and make it impossible to be selective about what you proxy.
However, both such optimizations and selective proxying are apparently hard to implement securely.
Now, selective proxying is nice to have.
It is better if enterprises don't intercept traffic to banks or social networks. However, it seems to me like facebook would be a nice side-channel for exfiltrating data.
It seems to me that selective proxying could still be solved at the DNS level. Make any domain except for the whitelisted ones resolve to a proxy, and the have the proxy in between all traffic.
This means you also proxy all unencrypted traffic to the outside world, but if you are proxying TLS, you probably want to block or proxy plaintext outbound connections as well.
- mhils 9y ago> What TLS 1.3 does appear to do is make it harder to optimize this proxying, and make it impossible to be selective about what you proxy. You have the ServerNameIndication (SNI) in the ClientHello, so selective proxying is very easy to implement with TLS 1.3. SNI wasn't mandatory in older versions, which is why middleboxes went for this "let's inspect the certificate" dance in the first place.
- rocqua 9y agoTo 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.