4 ms·

> They could get everyone to open up a god damn firewall port if they wanted. No. They couldn’t. That’s the paradox. Together they control the client softwa

by comex 8y ago

> They could get everyone to open up a god damn firewall port if they wanted. No. They couldn’t. That’s the paradox. Together they control the client software running on just about everyone’s computers and phones… but they have very little control or influence over your random IT administrator running a corporate firewall or middleware box, who’s decided to block everything but 80 and 443 for “security” reasons. They don’t even have much influence over the vendors of those devices. Witness Chrome having to roll back TLS 1.3 support after initially deploying it, because BlueCoat and other vendors’ proxies were dropping all TLS 1.3 connections [1], despite TLS 1.3 having been many years in the making, and theoretically bring fully backward-compatible due to making use of the TLS version negotiation mechanism. In that case the relevant vendors did eventually release software updates, but only after Chrome forced their hand by unintentionally breaking all SSL sites for users behind those proxies – including Chrome’s own self-update server, so those users couldn’t even receive the rollback update! I’m sure that’s not an experience Google (or anyone else) is eager to repeat. Besides, for the sake of privacy, it’s best to limit the information transmitted in cleartext over the Internet to the absolute minimum – and that includes what type of service is being accessed. Why should an adversary intercepting traffic get to learn that for free from the port number, when that information could be transmitted as part of the encrypted connection instead? (Yes, the adversary might be able to figure it out anyway through traffic analysis, but at least that has limits and potential countermeasures.) [1] http://web.archive.org/web/20170311013249/https://bugs.chromium.org/p/chromium/issues/detail?id=694593 http://web.archive.org/web/20170311013249/https://bugs.chrom...

peterwwillis 8y ago
I don't buy this line for one minute. The fact that these organizations are either too weak or incompetent to roll out difficult changes in no way means it can't be done. This is just the path of least resistance. Rather than design something good, we just slap a layer of crap on top of another layer of crap and call it an improvement. But dressing up a turd doesn't make it smell like roses. The fact is that half (if not more) of the world depends on Google, Mozilla and CloudFlare. If they actually committed to breaking networks with a new standard, the vendors and network admins would have no choice but to slowly but surely roll out fixes, because the users need it. Maybe they should actually roll out a product that would update networks to fit an application's needs, like Kubernetes for SDN. This feature is literally "Oh, we're having problems with DNS, but changing the protocol could be hard, so let's hide a new version of it inside some other protocol." They should stop screwing around and just release a Google Chrome VPN, which you just know they're going to release. AMP was just the amuse bouche. Let's be real here, an advertising company does not care about privacy. Chrome implemented DNS over HTTPS a long time ago because it was a technical fix for a browser issue, not for privacy. Mozilla was slow to adopt but it got on the bandwagon. And let's not pretend that "hiding" a port number is a security feature, security by obscurity is a joke.
- crunchatized 8y ago
  Well, an advertising company doesn't care about protecting your privacy from themselves as the threat. But protecting you from rival data-miners like unscrupulous ISPs could actually help their business model, if you want to look at things cynically. And protecting DNS queries from local poisoning or outright censorship is the security feature. Having to resort to the 'easy,' non-boat-rocking encryption port of 443 is an implementation detail.
  - peterwwillis 8y ago
    First of all, censorship is censorship. It's not an exploit or a bug, it's a purposeful set of laws, policies or regulations meant to restrict the use of something. DNS over HTTPS "improving security" in a censorship context is the same as saying that when a corporate web proxy prevents you from going to PornHub, circumventing that proxy is "improving security". And btw, circumventing censorship may be illegal, or at the very least against official policies. It's also not a security feature because you don't need this to protect against cache poisoning, as DNSSEC already does that.
- comex 8y ago
  Chrome implemented DNS over HTTPS only three months ago[1], and I don't believe it currently uses it by default (overriding the OS default DNS server choice) like Mozilla is planning to do. The initial IETF draft[2] lists authors from ICANN and Mozilla, not Google. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=799753 https://bugs.chromium.org/p/chromium/issues/detail?id=799753 [2] https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-01 https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-01

by comex 8y ago

peterwwillis 8y ago

I don't buy this line for one minute. The fact that these organizations are either too weak or incompetent to roll out difficult changes in no way means it can't be done. This is just the path of least resistance. Rather than design something good, we just slap a layer of crap on top of another layer of crap and call it an improvement. But dressing up a turd doesn't make it smell like roses. The fact is that half (if not more) of the world depends on Google, Mozilla and CloudFlare. If they actually committed to breaking networks with a new standard, the vendors and network admins would have no choice but to slowly but surely roll out fixes, because the users need it. Maybe they should actually roll out a product that would update networks to fit an application's needs, like Kubernetes for SDN. This feature is literally "Oh, we're having problems with DNS, but changing the protocol could be hard, so let's hide a new version of it inside some other protocol." They should stop screwing around and just release a Google Chrome VPN, which you just know they're going to release. AMP was just the amuse bouche. Let's be real here, an advertising company does not care about privacy. Chrome implemented DNS over HTTPS a long time ago because it was a technical fix for a browser issue, not for privacy. Mozilla was slow to adopt but it got on the bandwagon. And let's not pretend that "hiding" a port number is a security feature, security by obscurity is a joke.

crunchatized 8y ago
Well, an advertising company doesn't care about protecting your privacy from themselves as the threat. But protecting you from rival data-miners like unscrupulous ISPs could actually help their business model, if you want to look at things cynically. And protecting DNS queries from local poisoning or outright censorship is the security feature. Having to resort to the 'easy,' non-boat-rocking encryption port of 443 is an implementation detail.
- peterwwillis 8y ago
  First of all, censorship is censorship. It's not an exploit or a bug, it's a purposeful set of laws, policies or regulations meant to restrict the use of something. DNS over HTTPS "improving security" in a censorship context is the same as saying that when a corporate web proxy prevents you from going to PornHub, circumventing that proxy is "improving security". And btw, circumventing censorship may be illegal, or at the very least against official policies. It's also not a security feature because you don't need this to protect against cache poisoning, as DNSSEC already does that.
comex 8y ago
Chrome implemented DNS over HTTPS only three months ago[1], and I don't believe it currently uses it by default (overriding the OS default DNS server choice) like Mozilla is planning to do. The initial IETF draft[2] lists authors from ICANN and Mozilla, not Google. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=799753 https://bugs.chromium.org/p/chromium/issues/detail?id=799753 [2] https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-01 https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-01