4 ms·

Encrypted SNI is great for individual privacy but terrible for business/corporate security. At the moment it is possible to MITM proxy (without the possibility

Encrypted SNI is great for individual privacy but terrible for business/corporate security. At the moment it is possible to MITM proxy (without the possibility decryption) to inspect the SNI and determine if the host is allowed, and if so the proxy does its own IP resolution and transparently proxies/forwards the TCP traffic. Ie it never engages in the TLS session. This is useful for restricting access from a LAN to services hosted on large cloud provides like AWS, GCP, etc where fixed IPs are not available (well, the third party service/website elects to use a CDN/load balancer/etc without regard to the full security impact). A good example is PCI DSS and the payment card LAN. You should firewall and lock down so devices can only communicate with necessary services. Along with actual payment services, these LANs often need to allow access out to third party loyalty systems, digital receipt systems, etc that are cloud based. With Encrypted SNI this won’t be possible to do securely anymore. A full MITM TLS decrypting proxy with explicitly configure clients will be required to ensure the encrypted SNI isn’t changed to a malicous host to eg upload captured payment data to. That’s a lot more overhead both in: 1. Configuring clients to use a proxy and custom CA (let’s hope all the various third parties apps support proxy setup and custom CAs, and no cert pinning!) 2. Running a proxy that now it has to do full decryption and encryption (to make sure you aren’t messing with the SNI and going to a host you shouldn’t). Of course I don’t expect businesses to these lengths until there has been a serious breach exploiting encrypted SNI. Even then I don’t know which side will take action (or if neither side will)— merchants installing MITM proxies (unlikely), or third party service providers ditching load balancers and sticking to fixed IPs on their cloud hosts (less unlikely).

growse 8y ago
Aren't businesses that are serious about meeting their legal/regulatory obligations for controlling internet access already using full MITM TLS interception with their own CAs? Given a malicious actor can register any old domain and get a cert for it very easily, I'm not sure what particular threat blocking TLS connections based just on the SNI is actually protecting you from.
- tialaramex 8y ago
  Backside covering at the cheapest possible price is the goal. It's not about whether it achieves the regulatory goal, just whether it gets a check on the list. The previous iteration of backside covering pondered the unencrypted server certificate, on the rationale that if this is a bad guy why do they have a good guy's certificate. If you know any cryptography, you are now thinking "But, wait, how does that secure anything?" but you aren't the target customer. The target customer verifies that this blocks them from accessing a "Bad" site in Internet Explorer and they're happy to part with $$ instead of the $$$ it would cost to do full blown HTTPS proxy for every connection. In TLS 1.3 this server certificate is encrypted. So the (perhaps slightly more untrustworthy) client SNI is pondered instead. What middlebox vendors would prefer not to mention is that in many cases they also figured TLS re-connections are always safe and can be allowed through. After all, if they didn't let bad guys make the original connection, how could those bad guys re-connect? TLS 1.3 exploited this to be "backward compatible" with such crapware, it says all its connections are "reconnections" so they pass through unmolested...
- yardstick 8y ago
  Think of all the small 1-2 employee businesses / mom & pop businesses etc that take credit cards. They have no dedicated IT person. They’d be lucky to have a dedicated LAN for payments (a PCI DSS requirement). Increasing the barriers to compliance for these people is not a good thing. In practice they will just close their eyes and pretend nothing is wrong, or they will just pay the fine charges by the banks for non compliance— which doesn’t improve your credit card security at all. You can’t tell all these small businesses they can’t take card payments, and you can’t make an already tough job harder, more complex and more expensive without an associated drop in compliance.
  - growse 8y ago
    1-2 person businesses are likely outsourcing the entire problem of payment processing (and thus, the majority of the PCI controls) to a 3rd party like Stripe. The only PCI compliance needed then is an annual self-attestation which basically asks "Did you change your router's default password?" and "do you apply patches?" [1] There may be some mildly masochistic tiny businesses that choose to process / store payment details on their own networks and try to manage all the controls needed for that, but in the presence of so many options for outsourcing the problem, this doesn't seem like a particularly rational decision. > You can’t tell all these small businesses they can’t take card payments, and you can’t make an already tough job harder, more complex and more expensive without an associated drop in compliance. This is only true if there are no sane alternatives. [1] https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2_1-SAQ-A.pdf https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2_...
tialaramex 8y ago
No, it makes no practical difference to "business/corporate security" but it's terrible for lazy and incompetent people who wanted to look as though they were effective. The "full MITM proxy" you mention is, and always has been, the only defined way to make this work. The cheaper, half-arsed solutions you describe earlier cause everybody else pain (socialising costs while privatizing profit) and often don't actually deliver any meaningful security, they're just theatre. Corporate TLS Middleboxes are the TSA screening of the Internet's security. Everybody knows they're there, everybody complains at the inconvenience, everybody ends up paying the price indirectly, and they claim they're very effective. But independent measures suggest they're basically entirely pointless.
- yardstick 8y ago
  Which independent measures do you refer to? This is for non-decrypting MITM proxies that only use the SNI to validate they are going to the right domain and proxy the TCP data between the two. What’s the attack vector?
eeZah7Ux 8y ago
Absolutely not. Full MITM proxies are required to inspect traffic. Inspecting SNI is ineffective against the majority of threats including blocking botnet traffic.
- yardstick 8y ago
  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.

growse 8y ago

Aren't businesses that are serious about meeting their legal/regulatory obligations for controlling internet access already using full MITM TLS interception with their own CAs? Given a malicious actor can register any old domain and get a cert for it very easily, I'm not sure what particular threat blocking TLS connections based just on the SNI is actually protecting you from.

tialaramex 8y ago
Backside covering at the cheapest possible price is the goal. It's not about whether it achieves the regulatory goal, just whether it gets a check on the list. The previous iteration of backside covering pondered the unencrypted server certificate, on the rationale that if this is a bad guy why do they have a good guy's certificate. If you know any cryptography, you are now thinking "But, wait, how does that secure anything?" but you aren't the target customer. The target customer verifies that this blocks them from accessing a "Bad" site in Internet Explorer and they're happy to part with $$ instead of the $$$ it would cost to do full blown HTTPS proxy for every connection. In TLS 1.3 this server certificate is encrypted. So the (perhaps slightly more untrustworthy) client SNI is pondered instead. What middlebox vendors would prefer not to mention is that in many cases they also figured TLS re-connections are always safe and can be allowed through. After all, if they didn't let bad guys make the original connection, how could those bad guys re-connect? TLS 1.3 exploited this to be "backward compatible" with such crapware, it says all its connections are "reconnections" so they pass through unmolested...
yardstick 8y ago
Think of all the small 1-2 employee businesses / mom & pop businesses etc that take credit cards. They have no dedicated IT person. They’d be lucky to have a dedicated LAN for payments (a PCI DSS requirement). Increasing the barriers to compliance for these people is not a good thing. In practice they will just close their eyes and pretend nothing is wrong, or they will just pay the fine charges by the banks for non compliance— which doesn’t improve your credit card security at all. You can’t tell all these small businesses they can’t take card payments, and you can’t make an already tough job harder, more complex and more expensive without an associated drop in compliance.
- growse 8y ago
  1-2 person businesses are likely outsourcing the entire problem of payment processing (and thus, the majority of the PCI controls) to a 3rd party like Stripe. The only PCI compliance needed then is an annual self-attestation which basically asks "Did you change your router's default password?" and "do you apply patches?" [1] There may be some mildly masochistic tiny businesses that choose to process / store payment details on their own networks and try to manage all the controls needed for that, but in the presence of so many options for outsourcing the problem, this doesn't seem like a particularly rational decision. > You can’t tell all these small businesses they can’t take card payments, and you can’t make an already tough job harder, more complex and more expensive without an associated drop in compliance. This is only true if there are no sane alternatives. [1] https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2_1-SAQ-A.pdf https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2_...

tialaramex 8y ago

No, it makes no practical difference to "business/corporate security" but it's terrible for lazy and incompetent people who wanted to look as though they were effective. The "full MITM proxy" you mention is, and always has been, the only defined way to make this work. The cheaper, half-arsed solutions you describe earlier cause everybody else pain (socialising costs while privatizing profit) and often don't actually deliver any meaningful security, they're just theatre. Corporate TLS Middleboxes are the TSA screening of the Internet's security. Everybody knows they're there, everybody complains at the inconvenience, everybody ends up paying the price indirectly, and they claim they're very effective. But independent measures suggest they're basically entirely pointless.

yardstick 8y ago
Which independent measures do you refer to? This is for non-decrypting MITM proxies that only use the SNI to validate they are going to the right domain and proxy the TCP data between the two. What’s the attack vector?

eeZah7Ux 8y ago

Absolutely not. Full MITM proxies are required to inspect traffic. Inspecting SNI is ineffective against the majority of threats including blocking botnet traffic.

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