8 ms·

I think it's worth pointing out the repercussions of this and DNS-over-HTTPS. Every corporation which does SNI scanning for web filtering will require every us

I think it's worth pointing out the repercussions of this and DNS-over-HTTPS. Every corporation which does SNI scanning for web filtering will require every user to insert the company's CA cert in every client they use. This then also forces them to make a choice between requiring all apps in all networks to do this, or whitelist certain parts of the network. Not only does this reduce their security, but it limits how apps can work on their networks. Authoritarian governments will also start requiring this. I could even see federal agencies for non-authoritarian governments making a stink over it on law enforcement grounds. They already hate encryption. If they can't force you to expose what sites you are visiting, they may force new legislation to require all web service providers to provide logs to law enforcement, which is a much worse privacy violation than just seeing what domain you were hitting. I think the better solution to this would have been to improve server-side support for VPNs and Tor. Tech does not exist in a bubble, and rights can be taken away when they conflict with the interests of authority.

Buge 8y ago
They could always do IP blocking and tracking.
- peterwwillis 8y ago
  Doesn't really work if half the internet is covered by CloudFlare's free CDN.
anticensor 8y ago
> federal agencies for non-authoritarian governments You should correct it into _national_ agencies for non-authoritarian governments. Unitary states are majority in the world.
zorked 8y ago
If this makes surveillance more visible it's already a huge societal win.
michaelt 8y ago
Every corporation which does SNI scanning for web filtering will require every user to insert the company's CA cert in every client they use. Just require your employees to route port 443 traffic through a proxy, making a CONNECT request. It doesn't prevent domain fronting, of course, but neither did SNI scanning.
- peterwwillis 8y ago
  What would this accomplish? I assume the CONNECT string would simply be the IP:PORT of the destination, the same as with SNI hiding, so it doesn't seem like it would make a difference.
  - michaelt 8y ago
    I suppose that's a good point; although today the CONNECT command uses a hostname, a browser could change to using IP:PORT if they were serious about keeping hostnames secret.
kristofferR 8y ago
Forcing the installation of a root CA isn't a viable option for all but the largest authoritarian governments (China and Russia). Kazakhstan attempted [1], but abandoned the idea, likely since it was unrealistic to expect widespread adoption of the certificate. [1] https://news.ycombinator.com/item?id=10663843 https://news.ycombinator.com/item?id=10663843
- exikyut 8y ago
  Well, you could make a proxy that only allows HTTPS traffic through if it's signed by your root cert, then MITM-resign all upstream certs. ...ah, and that would break anything using cert pinning. HTTPS feels so utterly clunky.
- gsich 8y ago
  And how does that "forcing" work? You just install it voluntarily because you get annoyed by certificate errors on every other site?
- peterwwillis 8y ago
  A much easier solution is for the government to circumvent PKI entirely. Basically you issue a National Security Letter to some cert provider and require them to give you their keys. Now you can generate valid certs as that provider. You use this in combination with a MITM tool to auto-generate certs for any requested domain, and those certs are implicitly trusted by all clients because they trust that CA's keys. So the state can now MITM and listen to all secured connections, and the only giveaway is that the cert is not in the certificate transparency log, or if the CA used does not match the domain's CAA record (when it exists).
  - cesarb 8y ago
    > So the state can now MITM and listen to all secured connections, and the only giveaway is that the cert is not in the certificate transparency log, or if the CA used does not match the domain's CAA record (when it exists). Or when the domain uses HPKP to pin its certificate to a different CA. When the MITM CA has been added manually to the browser's root key store, most browsers allow HPKP bypass by that CA unless configured otherwise; but if the MITM is done by compromising one of the browser's default CAs, the browser won't allow a bypass. Or if the certificate was supposed to be an EV certificate, which can only be issued by a limited number of CAs, and the compromised CA is not one of these. And even if an EV CA is compromised, AFAIK some browsers require the certificate to be in a Certificate Transparency log, and they also require that the certificate carry proof of its submission to the CT logs.
dane-pgp 8y ago
This sounds a lot like the argument we have already seen from the anti-"TLS everywhere" crowd. The claim is something like "If people start using HTTPS even for sites which [supposedly] don't need encryption, then governments will get annoyed at not being able to spy on people any more, so they'll finally force everyone to install a root CA cert that will be used to MitM their connections". The logical extension of this line of thinking is that the tech community should never provide any extra security to anyone, in case somewhere some malicious actor is angered into retaliating against a certain group of users. If you think that there are companies that rely on surveilling DNS requests (but don't already intercept and decrypt all their employee's web traffic) then you can campaign for browsers and OSes to have an option to turn off new security features like DNS-over-HTTPS/TLS and Encrypted SNI, but please don't demand that the whole internet go without these basic protections because of the internal policies of a few corporations.
- peterwwillis 8y ago
  My argument is not that the government will require root CAs for all clients due to a lack of surveillance options. My argument is that without the ability to enforce the law, the government may force a change that allows them to enforce the law. The logical extension would not be "there should be no security features", and this is obvious, because the whole problem was not the existence of security features. The problem was the lack of ability to enforce policies, which organizations (companies, governments) are often required to do. I think the logical extension should be that security features should be developed with policy enforcement capabilities in mind. Also, it's not logical to conflate this privacy feature with security features. Secure connections do not require SNI hiding at all. DNS-over-HTTPS is closer to a security feature, because without enabling DNSSEC, exploits are possible to the DNS which can impact non-TLS connections. That has a much easier workaround, which is to point DNS-over-HTTPS to a local provider.
  - cesarb 8y ago
    > They'll probably issue an NSL to some cert vendor, or just tell the NSA to extract their keys, and then listen quietly to all secured connections. There's no "quiet" in this approach. The cert vendors do not have the certificate's private keys; all the server operators send to the cert vendors is the certificate's public keys. Therefore, the only way to listen on the secured connections through a cert vendor is to use the cert vendor's private keys to sign a counterfeit certificate, which is presented to the browser. And at this point, the browser has everything it needs to prove that the cert vendor was compromised. There are also several other gotchas: Certificate Transparency can force them to publish their counterfeit certificates to the whole world; Extended Validation is allowed only from some cert vendors (and requires Certificate Transparency); and last but not least, this (like all MITM) breaks client authentication (client certificates). Finally, this only applies to cert vendors under the USA jurisdiction. A NSL has no power over other countries.
vbezhenar 8y ago
Authoritan governments will just block by IP. Yes, they'll block all CDN's as a consequence and big parts of internet won't work. There was time when Kazakhstan blocked dozen of Google's IPs because some opposition hosted their website on blogspot and gmail was broken. It lasted monthes if not years, well, nobody rebelled because of it, LoL. All that encryption will lead to people using VPNs en masse. This will lead to laws, directly prohibiting VPN usage except for explicitly granted permissions for selected businesses. This will lead to Internet segmentation, Russian Internet, China Internet, etc, world wide web will cease to exist.
cesarb 8y ago
Every step towards "encrypt all the things" increases the cost of that interception. Back when the web was plaintext-only, a mirror port on a switch was more than enough to see everything. With SSL and TLS up to 1.2, they have to MITM to see anything more than the IP address, the SNI, and the server certificate. With TLS 1.3, they have to MITM if they want to see the server certificate. With TLS 1.3 plus encrypted DNS plus encrypted SNI, all they have without a MITM is the IP address. And on the MITM front, several measures have gradually made it harder, with a grandfathered exception for manually added root CAs. Corporations and governments have to balance the costs and the benefits of breaking encryption. The costs have increased, which increases the chance that they decide that the costs outweigh any perceived benefits.
- wahern 8y ago
  > Every step towards "encrypt all the things" increases the cost of that interception. That's not the case at all, and a very dangerous idea. Some steps drive increased centralization. Increased centralization makes interception and filtering easier. The better solution is to push domain authentication to after the secure channel is established. That doesn't protect against active MITM snoopers, but neither does TLS ESNI. Worse, TLS ESNI will drive people to use centralized DNS-over-TLS service providers. Mozilla+Cloudflare's "free" DNS service barely made it out of the gate before it was hijacked by the Great Firewall (not even simply blocked). See https://borncity.com/win/2018/05/30/cloudflare-dns-service-1-1-1-1-hacked-from-china/ https://borncity.com/win/2018/05/30/cloudflare-dns-service-1... and https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/ https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/ Of course, with DNS-over-TLS you would know (maybe) that there was a MITM. But that's no different than DNSSEC. And there's nothing you could do about it, anyhow. Securing DNS, and specifically keeping DNS queries private, is NOT a solved problem. Indeed, it's not even a solvable problem because of the nature of DNS--the need to centrally coordinate registration of human readable identifiers. The only real "solution" is anonymization via techniques like onion routing (e.g. Tor), which anonymizes the requester, not the responder. Advocates will tell you that TLS ESNI improves requester anonymity by aggregating users behind "trusted" intermediate resolvers, but that's largely based on conjecture and very little evidence--in particular without any showing that usage patterns won't naturally reconfigure to either return everybody to the status quo ante, or make everybody worse off on average. TLS ESNI is a wild goose chase and, looking back 10 years from now, will have simply served to increase the complexity of the web stack and decrease service and software diversity.

Buge 8y ago

They could always do IP blocking and tracking.

peterwwillis 8y ago
Doesn't really work if half the internet is covered by CloudFlare's free CDN.

anticensor 8y ago

> federal agencies for non-authoritarian governments You should correct it into _national_ agencies for non-authoritarian governments. Unitary states are majority in the world.

zorked 8y ago

If this makes surveillance more visible it's already a huge societal win.

michaelt 8y ago

Every corporation which does SNI scanning for web filtering will require every user to insert the company's CA cert in every client they use. Just require your employees to route port 443 traffic through a proxy, making a CONNECT request. It doesn't prevent domain fronting, of course, but neither did SNI scanning.

peterwwillis 8y ago
What would this accomplish? I assume the CONNECT string would simply be the IP:PORT of the destination, the same as with SNI hiding, so it doesn't seem like it would make a difference.
- michaelt 8y ago
  I suppose that's a good point; although today the CONNECT command uses a hostname, a browser could change to using IP:PORT if they were serious about keeping hostnames secret.

kristofferR 8y ago

Forcing the installation of a root CA isn't a viable option for all but the largest authoritarian governments (China and Russia). Kazakhstan attempted [1], but abandoned the idea, likely since it was unrealistic to expect widespread adoption of the certificate. [1] https://news.ycombinator.com/item?id=10663843 https://news.ycombinator.com/item?id=10663843

exikyut 8y ago
Well, you could make a proxy that only allows HTTPS traffic through if it's signed by your root cert, then MITM-resign all upstream certs. ...ah, and that would break anything using cert pinning. HTTPS feels so utterly clunky.
gsich 8y ago
And how does that "forcing" work? You just install it voluntarily because you get annoyed by certificate errors on every other site?
peterwwillis 8y ago
A much easier solution is for the government to circumvent PKI entirely. Basically you issue a National Security Letter to some cert provider and require them to give you their keys. Now you can generate valid certs as that provider. You use this in combination with a MITM tool to auto-generate certs for any requested domain, and those certs are implicitly trusted by all clients because they trust that CA's keys. So the state can now MITM and listen to all secured connections, and the only giveaway is that the cert is not in the certificate transparency log, or if the CA used does not match the domain's CAA record (when it exists).
- cesarb 8y ago
  > So the state can now MITM and listen to all secured connections, and the only giveaway is that the cert is not in the certificate transparency log, or if the CA used does not match the domain's CAA record (when it exists). Or when the domain uses HPKP to pin its certificate to a different CA. When the MITM CA has been added manually to the browser's root key store, most browsers allow HPKP bypass by that CA unless configured otherwise; but if the MITM is done by compromising one of the browser's default CAs, the browser won't allow a bypass. Or if the certificate was supposed to be an EV certificate, which can only be issued by a limited number of CAs, and the compromised CA is not one of these. And even if an EV CA is compromised, AFAIK some browsers require the certificate to be in a Certificate Transparency log, and they also require that the certificate carry proof of its submission to the CT logs.

dane-pgp 8y ago

This sounds a lot like the argument we have already seen from the anti-"TLS everywhere" crowd. The claim is something like "If people start using HTTPS even for sites which [supposedly] don't need encryption, then governments will get annoyed at not being able to spy on people any more, so they'll finally force everyone to install a root CA cert that will be used to MitM their connections". The logical extension of this line of thinking is that the tech community should never provide any extra security to anyone, in case somewhere some malicious actor is angered into retaliating against a certain group of users. If you think that there are companies that rely on surveilling DNS requests (but don't already intercept and decrypt all their employee's web traffic) then you can campaign for browsers and OSes to have an option to turn off new security features like DNS-over-HTTPS/TLS and Encrypted SNI, but please don't demand that the whole internet go without these basic protections because of the internal policies of a few corporations.

peterwwillis 8y ago
My argument is not that the government will require root CAs for all clients due to a lack of surveillance options. My argument is that without the ability to enforce the law, the government may force a change that allows them to enforce the law. The logical extension would not be "there should be no security features", and this is obvious, because the whole problem was not the existence of security features. The problem was the lack of ability to enforce policies, which organizations (companies, governments) are often required to do. I think the logical extension should be that security features should be developed with policy enforcement capabilities in mind. Also, it's not logical to conflate this privacy feature with security features. Secure connections do not require SNI hiding at all. DNS-over-HTTPS is closer to a security feature, because without enabling DNSSEC, exploits are possible to the DNS which can impact non-TLS connections. That has a much easier workaround, which is to point DNS-over-HTTPS to a local provider.
- cesarb 8y ago
  > They'll probably issue an NSL to some cert vendor, or just tell the NSA to extract their keys, and then listen quietly to all secured connections. There's no "quiet" in this approach. The cert vendors do not have the certificate's private keys; all the server operators send to the cert vendors is the certificate's public keys. Therefore, the only way to listen on the secured connections through a cert vendor is to use the cert vendor's private keys to sign a counterfeit certificate, which is presented to the browser. And at this point, the browser has everything it needs to prove that the cert vendor was compromised. There are also several other gotchas: Certificate Transparency can force them to publish their counterfeit certificates to the whole world; Extended Validation is allowed only from some cert vendors (and requires Certificate Transparency); and last but not least, this (like all MITM) breaks client authentication (client certificates). Finally, this only applies to cert vendors under the USA jurisdiction. A NSL has no power over other countries.

vbezhenar 8y ago

Authoritan governments will just block by IP. Yes, they'll block all CDN's as a consequence and big parts of internet won't work. There was time when Kazakhstan blocked dozen of Google's IPs because some opposition hosted their website on blogspot and gmail was broken. It lasted monthes if not years, well, nobody rebelled because of it, LoL. All that encryption will lead to people using VPNs en masse. This will lead to laws, directly prohibiting VPN usage except for explicitly granted permissions for selected businesses. This will lead to Internet segmentation, Russian Internet, China Internet, etc, world wide web will cease to exist.

cesarb 8y ago

Every step towards "encrypt all the things" increases the cost of that interception. Back when the web was plaintext-only, a mirror port on a switch was more than enough to see everything. With SSL and TLS up to 1.2, they have to MITM to see anything more than the IP address, the SNI, and the server certificate. With TLS 1.3, they have to MITM if they want to see the server certificate. With TLS 1.3 plus encrypted DNS plus encrypted SNI, all they have without a MITM is the IP address. And on the MITM front, several measures have gradually made it harder, with a grandfathered exception for manually added root CAs. Corporations and governments have to balance the costs and the benefits of breaking encryption. The costs have increased, which increases the chance that they decide that the costs outweigh any perceived benefits.

wahern 8y ago
> Every step towards "encrypt all the things" increases the cost of that interception. That's not the case at all, and a very dangerous idea. Some steps drive increased centralization. Increased centralization makes interception and filtering easier. The better solution is to push domain authentication to after the secure channel is established. That doesn't protect against active MITM snoopers, but neither does TLS ESNI. Worse, TLS ESNI will drive people to use centralized DNS-over-TLS service providers. Mozilla+Cloudflare's "free" DNS service barely made it out of the gate before it was hijacked by the Great Firewall (not even simply blocked). See https://borncity.com/win/2018/05/30/cloudflare-dns-service-1-1-1-1-hacked-from-china/ https://borncity.com/win/2018/05/30/cloudflare-dns-service-1... and https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/ https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/ Of course, with DNS-over-TLS you would know (maybe) that there was a MITM. But that's no different than DNSSEC. And there's nothing you could do about it, anyhow. Securing DNS, and specifically keeping DNS queries private, is NOT a solved problem. Indeed, it's not even a solvable problem because of the nature of DNS--the need to centrally coordinate registration of human readable identifiers. The only real "solution" is anonymization via techniques like onion routing (e.g. Tor), which anonymizes the requester, not the responder. Advocates will tell you that TLS ESNI improves requester anonymity by aggregating users behind "trusted" intermediate resolvers, but that's largely based on conjecture and very little evidence--in particular without any showing that usage patterns won't naturally reconfigure to either return everybody to the status quo ante, or make everybody worse off on average. TLS ESNI is a wild goose chase and, looking back 10 years from now, will have simply served to increase the complexity of the web stack and decrease service and software diversity.