4 ms·

Re commentary #1, it is due to websites being hosted on ever changing IPs such as with AWS and GCP allowing them to fire up additional resources easily, or usin

Re commentary #1, it is due to websites being hosted on ever changing IPs such as with AWS and GCP allowing them to fire up additional resources easily, or using a fronting load balancer, or even a DDOS protection tool like CloudFront. In these cases only the domain name is known in advance by the intercepting firewall. It can’t get this info via reverse lookup on the requested destination IP (nor should it; reverse dns doesn’t always work and performance doing this for every connection would be bad). I’ve also looked at other options, like dns based firewall rules that are populated by the firewall also being the local dns server and so is able to see the resolved IP(s), but if those IPs are to CloudFront etc then it would be granting access to everything else also hosted by CloudFront etc. TLS SNI is the only way of knowing where the client is trying to reach — short of the expensive and difficult to deploy explicit/non-transparent HTTPS proxy. Re commentary #2, since all the TLS traffic is going through the proxy, the original request and any subsequent requests would go to the same IP each time.

tialaramex 8y ago
If you're whitelisting names that point into arbitrary cloud stuff then you're screwed, the bad guys just get themselves co-located so that you'll happily connect to them because hey, this name was whitelisted and so the IP address must be OK. TLS SNI does NOT tell you where the client was trying to reach, you've made a classic security mistake of assuming bad guys are honest. Honest people will truthfully write good.example and be allowed past, bad guys will dishonestly write good.example, and thereby connect to bad.example on the same IP address and laugh at your ridiculous "security". Caching all DNS answers for some indeterminate amount of time makes your security story worse, but even if you do this the worst case stands, ClientHello isn't required to work if you do this. It may work today, in fact it probably does, but it may break with no notice, and it'll be your fault.
- yardstick 8y ago
  You are correct that if the bad guy co-locates at the same IP then it is a problem. However that then becomes an issue with the service that chose to host on a shared IP. For other services that use dedicated IPs but spin up/down machines based on load etc it is still much more useful and secure than running a proxy with a CA that generates fake certificates, especially when you can’t update the trust root of the client device (often the case with embedded devices and those that are managed by the third party service provider)
  - hakfoo 8y ago
    The colocation would be trivial to fake. Just buy a second benign domain name, register it privately, and point a few A records at your servers. You're back to seeing SNI requests for cdn12345.catpics.com which happens to be the same as command-and-control.suspicious-site.kp

tialaramex 8y ago

If you're whitelisting names that point into arbitrary cloud stuff then you're screwed, the bad guys just get themselves co-located so that you'll happily connect to them because hey, this name was whitelisted and so the IP address must be OK. TLS SNI does NOT tell you where the client was trying to reach, you've made a classic security mistake of assuming bad guys are honest. Honest people will truthfully write good.example and be allowed past, bad guys will dishonestly write good.example, and thereby connect to bad.example on the same IP address and laugh at your ridiculous "security". Caching all DNS answers for some indeterminate amount of time makes your security story worse, but even if you do this the worst case stands, ClientHello isn't required to work if you do this. It may work today, in fact it probably does, but it may break with no notice, and it'll be your fault.

yardstick 8y ago
You are correct that if the bad guy co-locates at the same IP then it is a problem. However that then becomes an issue with the service that chose to host on a shared IP. For other services that use dedicated IPs but spin up/down machines based on load etc it is still much more useful and secure than running a proxy with a CA that generates fake certificates, especially when you can’t update the trust root of the client device (often the case with embedded devices and those that are managed by the third party service provider)
- hakfoo 8y ago
  The colocation would be trivial to fake. Just buy a second benign domain name, register it privately, and point a few A records at your servers. You're back to seeing SNI requests for cdn12345.catpics.com which happens to be the same as command-and-control.suspicious-site.kp