5 ms·

This attitude always amazes me. You have obviously mastered a set of system administration skills over several years, and you are comfortable with a particular

by s_tec 7y ago

This attitude always amazes me. You have obviously mastered a set of system administration skills over several years, and you are comfortable with a particular way of doing things. When somebody points out a weakness with the status quo and tries to offer something better, though, you react with hostility. Why do you think that is? I understand that their solution is not perfect (nothing ever starts out that way), but the amount of aggression in your comment suggests that something deeper is going on. Do you feel threatened? I suspect it's fear of change. As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption. This means you, the administrator, will have to learn more skills and do more work to keep things running. Things like `.local:` printers may break, and you may have to upgrade your internal DNS servers to RFC8484 so you can keep your split-horizon stuff working. Security is never free. Or not. None of this is mandatory, and you can just switch it off (and Mozilla will automatically switch it off if they detect an environment like yours, as it says in TFA). The threat isn't Mozilla "deciding policy" for you (they aren't), the threat is that they are calling the industry out for running old & vulnerable DNS standards, and we all know deep inside that they are right.

xg15 7y ago
I think the underlying issue is absolutely a power struggle. Until recently, the general understanding was that each network operator was responsible for the clients inside their network - and therefore also had the ability to set the network's configuration. In 99.99% of the cases, this included access to nonlocal sites on other, public network's, aka "the web", but this was nowhere technically required. Browsers and other DNS-consuming apps were perfectly capable of working within other networks. What a DNS name resolved to was technically a property of the network. By now, this model is shifted towards the Web as a platform with browsers and DNS as clear parts of it - a platform that is incidentally pay-to-play and centrally controlled by the US because at the very least you need recurring payments for your domain and you need to give companies and institutions located in the US control over your machine. This shift has been going on for a long time, but I believe HTTPS-everywhere and DoH have served to make this unignorably obvious because those bring the concept of the web platform into the technology stack itself. To make the tired old car analogy again: In the vast majority of cases, you will drive your car on the public road network and nowhere else. However your car is technically capable of driving off-road or performing highly questionable maneuvers in your backyard because the car itself doesn't have any concept of "public roads", "private roads" or "non-roads". DoH would be adding a device that turns off the engine as soon as you're not on a public road. What exactly constitutes as a "public road" is determined by the car manufacturer. I do agree that in the long run it might be better for ensuring that "the web" is the same no matter from where you visit, but I think it's definitely more than a simple technical change. I also think all the heuristics, opt-outs and special rules for corporate network's don't cut it, because they relegate the current default case to an uncommon special case - and developers have a habit of ignoring uncommon special cases. I wouldn't be surprised if we see a lot of non-browser apps and devices in the future that use DoH by default and that an administrator would have to reconfigure by hand for each single installation - or that are simply hardwired to some set of DoH servers without any way to configure them at all.
- s_tec 7y ago
  Wow, I had not considered the deeper power shifts from this perspective. The root the problem, I suppose, lies with public-key cryptography. We all know encryption is a good thing (unless you want to broadcast private information to the world), but encryption is useless unless you know who you are talking to. When someone comes to you in a ski mask and says, "It's me, your best friend", you probably want to see their face before you tell them any secrets - they could be anybody. Online, though, how do we know who anybody is? The current answer, for better or worse, is TLS with pay-to-play domain registration and certificate authorities. Decentralized, peer-to-peer systems like PGP have never been easy for consumers to use. You can "off-road" encrypted DNS by running your own DoH server & installing self-signed certificates on your client devices, but that's not an easy option. "My LAN is my castle" may work for some cases, but most of us conduct business with people all over the world, thanks to the internet. This is the primary use-case for most networks & computer systems. I'm afraid individuals will continue losing the power struggle as long as decentralized identity systems remain obscure. We need something that's as easy and compelling to use as our current centralized systems. It needs to be something consumers can use it to secure their every-day communications, as easy as visiting an HTTPS web site or chatting with a friend on Facebook. I just don't know how we get from here to there.
  - throw0101a 7y ago
    > ... but encryption is useless unless you know who you are talking to. False. Opportunistic encryption is useful even if you don't know the other person's identity. This is because it helps prevent wholesale surveillance and "tapping glass": * https://en.wikipedia.org/wiki/Room_641A https://en.wikipedia.org/wiki/Room_641A * https://en.wikipedia.org/wiki/PRISM_(surveillance_program) https://en.wikipedia.org/wiki/PRISM_(surveillance_program) For the majority of the website I go to on a casual basis, I don't really care who is behind running them. Certainly I want that for my banks and webmail, but not so much for some random weblog that has an article comparing Rust and C. I'm all for Let's Encrypt, and pushed for it to be introduced at work (both for internal and external sites), but we could have gotten encryption in more places, a lot sooner if connections over plaint-HTTP (tcp/80) could have been upgraded automatically to encryption: * https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header There would have been no lock icon in web browsers, but it would have scrambled a lot of bits. Yes, MITM would still have been possible, but MITM is a targeted attack that takes way more resources than simply vacuuming up everything that goes across the wire. The insistence of providing identity, IMHO, delayed the securing (or at least 'confidentializing') of communications by many years. LE/ACME is getting us there, but we could have had a lot more encrypted traffic already but for the desire for the little lock icon.
throw0101a 7y ago
> When somebody points out a weakness with the status quo and tries to offer something better, though, you react with hostility. What weakness? > As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption. Then use DNS-over-TLS (DoT). It was an RFC (7858) two years before DoH (8484, 2016 vs 2018). Why does yet another protocol have to be shoehorned into HTTP(S)?

by s_tec 7y ago

xg15 7y ago

I think the underlying issue is absolutely a power struggle. Until recently, the general understanding was that each network operator was responsible for the clients inside their network - and therefore also had the ability to set the network's configuration. In 99.99% of the cases, this included access to nonlocal sites on other, public network's, aka "the web", but this was nowhere technically required. Browsers and other DNS-consuming apps were perfectly capable of working within other networks. What a DNS name resolved to was technically a property of the network. By now, this model is shifted towards the Web as a platform with browsers and DNS as clear parts of it - a platform that is incidentally pay-to-play and centrally controlled by the US because at the very least you need recurring payments for your domain and you need to give companies and institutions located in the US control over your machine. This shift has been going on for a long time, but I believe HTTPS-everywhere and DoH have served to make this unignorably obvious because those bring the concept of the web platform into the technology stack itself. To make the tired old car analogy again: In the vast majority of cases, you will drive your car on the public road network and nowhere else. However your car is technically capable of driving off-road or performing highly questionable maneuvers in your backyard because the car itself doesn't have any concept of "public roads", "private roads" or "non-roads". DoH would be adding a device that turns off the engine as soon as you're not on a public road. What exactly constitutes as a "public road" is determined by the car manufacturer. I do agree that in the long run it might be better for ensuring that "the web" is the same no matter from where you visit, but I think it's definitely more than a simple technical change. I also think all the heuristics, opt-outs and special rules for corporate network's don't cut it, because they relegate the current default case to an uncommon special case - and developers have a habit of ignoring uncommon special cases. I wouldn't be surprised if we see a lot of non-browser apps and devices in the future that use DoH by default and that an administrator would have to reconfigure by hand for each single installation - or that are simply hardwired to some set of DoH servers without any way to configure them at all.

s_tec 7y ago
Wow, I had not considered the deeper power shifts from this perspective. The root the problem, I suppose, lies with public-key cryptography. We all know encryption is a good thing (unless you want to broadcast private information to the world), but encryption is useless unless you know who you are talking to. When someone comes to you in a ski mask and says, "It's me, your best friend", you probably want to see their face before you tell them any secrets - they could be anybody. Online, though, how do we know who anybody is? The current answer, for better or worse, is TLS with pay-to-play domain registration and certificate authorities. Decentralized, peer-to-peer systems like PGP have never been easy for consumers to use. You can "off-road" encrypted DNS by running your own DoH server & installing self-signed certificates on your client devices, but that's not an easy option. "My LAN is my castle" may work for some cases, but most of us conduct business with people all over the world, thanks to the internet. This is the primary use-case for most networks & computer systems. I'm afraid individuals will continue losing the power struggle as long as decentralized identity systems remain obscure. We need something that's as easy and compelling to use as our current centralized systems. It needs to be something consumers can use it to secure their every-day communications, as easy as visiting an HTTPS web site or chatting with a friend on Facebook. I just don't know how we get from here to there.
- throw0101a 7y ago
  > ... but encryption is useless unless you know who you are talking to. False. Opportunistic encryption is useful even if you don't know the other person's identity. This is because it helps prevent wholesale surveillance and "tapping glass": * https://en.wikipedia.org/wiki/Room_641A https://en.wikipedia.org/wiki/Room_641A * https://en.wikipedia.org/wiki/PRISM_(surveillance_program) https://en.wikipedia.org/wiki/PRISM_(surveillance_program) For the majority of the website I go to on a casual basis, I don't really care who is behind running them. Certainly I want that for my banks and webmail, but not so much for some random weblog that has an article comparing Rust and C. I'm all for Let's Encrypt, and pushed for it to be introduced at work (both for internal and external sites), but we could have gotten encryption in more places, a lot sooner if connections over plaint-HTTP (tcp/80) could have been upgraded automatically to encryption: * https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header There would have been no lock icon in web browsers, but it would have scrambled a lot of bits. Yes, MITM would still have been possible, but MITM is a targeted attack that takes way more resources than simply vacuuming up everything that goes across the wire. The insistence of providing identity, IMHO, delayed the securing (or at least 'confidentializing') of communications by many years. LE/ACME is getting us there, but we could have had a lot more encrypted traffic already but for the desire for the little lock icon.

throw0101a 7y ago

> When somebody points out a weakness with the status quo and tries to offer something better, though, you react with hostility. What weakness? > As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption. Then use DNS-over-TLS (DoT). It was an RFC (7858) two years before DoH (8484, 2016 vs 2018). Why does yet another protocol have to be shoehorned into HTTP(S)?