5 ms·

How so? If I as the MITM (non-decrypting) proxy intercept the request, look at the SNI to ensure it’s on my whitelist, and then do my own DNS lookup and open my

How so? If I as the MITM (non-decrypting) proxy intercept the request, look at the SNI to ensure it’s on my whitelist, and then do my own DNS lookup and open my own TCP connection to that IP and relay the traffic between the two, what’s the attack vector?

tialaramex 8y ago
I agree that whitelisting only "known good" IP addresses (supposing for a moment that there are such things) achieves your goal of preventing bad guys from non-good IP addresses communicating. I observe this has nothing whatsoever to do with TLS. I'll base my response on your description of how you think this device would work rather than your confusing term "MITM (non-decrypting) proxy". A1. Alice sends a TCP SYN to 1.2.3.4 port 443 Presumably you intercept this, and synthesise the appropriate SYN-ACK pretending to be from 1.2.3.4 port 443 which Alice ACKs A2. Alice sends an SSL/TLS ClientHello. It has some parameters you may not understand, and a SNI which says good.example which is on your whitelist A3. You DNS lookup good.example, the response suggests 5.6.7.8, so you TCP connect to port 443 of 5.6.7.8 and play back Alice's ClientHello and try to stitch things together in your NAT layer. Meanwhile B1. Bob sends a TCP SYN to 9.8.7.6 port 443 Presumably you intercept this, and synthesise the appropriate SYN-ACK pretending to be from 9.8.7.6 port 443 which Bob ACKs B2. Bob sends an SSL/TLS ClientHello. It has some parameters you may not understand, and a SNI which says bad.example which is NOT on your whitelist B3. You drop or reset Bob's connection, he cannot connect. Commentary #1: With the imagined comprehensive whitelist AND a following tail wind this doesn't give you anything better than just whitelisting the IPs in a conventional Firewall. Why spend all this extra money? Why involve TLS at all? It's complicated, but what for? Commentary #2: This ClientHello may not work when redirected to some other IP address. In reality there's a good chance you just cause a fallback and things are pointlessly slower, but in principle it may just not work at all.
- yardstick 8y ago
  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
eeZah7Ux 8y ago
Attackers can break into legitimate, low security, websites and use them as attack vectors. It's often easier that attacking the target directly and it's been done for decades. Also, botnets uses legitimate services to rely C&C traffic. Forums, pastebins, github gits, IRC and email gateways, VMs on AWS and other cloud services...
- yardstick 8y ago
  In my original comment I referred to the need to only allow access to necessary services. No forums, email gateways, IRC, etc. Just whitelisted domains and IPs:ports (if dedicated hosting) of the services required to handle the payments aspect of a business. An attacker would have to break into the sites I whitelisted— in which case the liability falls on the site for not maintaining adequate security. It doesn’t alleviate the need for the merchant to have good security themselves.

tialaramex 8y ago

I agree that whitelisting only "known good" IP addresses (supposing for a moment that there are such things) achieves your goal of preventing bad guys from non-good IP addresses communicating. I observe this has nothing whatsoever to do with TLS. I'll base my response on your description of how you think this device would work rather than your confusing term "MITM (non-decrypting) proxy". A1. Alice sends a TCP SYN to 1.2.3.4 port 443 Presumably you intercept this, and synthesise the appropriate SYN-ACK pretending to be from 1.2.3.4 port 443 which Alice ACKs A2. Alice sends an SSL/TLS ClientHello. It has some parameters you may not understand, and a SNI which says good.example which is on your whitelist A3. You DNS lookup good.example, the response suggests 5.6.7.8, so you TCP connect to port 443 of 5.6.7.8 and play back Alice's ClientHello and try to stitch things together in your NAT layer. Meanwhile B1. Bob sends a TCP SYN to 9.8.7.6 port 443 Presumably you intercept this, and synthesise the appropriate SYN-ACK pretending to be from 9.8.7.6 port 443 which Bob ACKs B2. Bob sends an SSL/TLS ClientHello. It has some parameters you may not understand, and a SNI which says bad.example which is NOT on your whitelist B3. You drop or reset Bob's connection, he cannot connect. Commentary #1: With the imagined comprehensive whitelist AND a following tail wind this doesn't give you anything better than just whitelisting the IPs in a conventional Firewall. Why spend all this extra money? Why involve TLS at all? It's complicated, but what for? Commentary #2: This ClientHello may not work when redirected to some other IP address. In reality there's a good chance you just cause a fallback and things are pointlessly slower, but in principle it may just not work at all.

yardstick 8y ago
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

eeZah7Ux 8y ago

Attackers can break into legitimate, low security, websites and use them as attack vectors. It's often easier that attacking the target directly and it's been done for decades. Also, botnets uses legitimate services to rely C&C traffic. Forums, pastebins, github gits, IRC and email gateways, VMs on AWS and other cloud services...

yardstick 8y ago
In my original comment I referred to the need to only allow access to necessary services. No forums, email gateways, IRC, etc. Just whitelisted domains and IPs:ports (if dedicated hosting) of the services required to handle the payments aspect of a business. An attacker would have to break into the sites I whitelisted— in which case the liability falls on the site for not maintaining adequate security. It doesn’t alleviate the need for the merchant to have good security themselves.