1. 74
  1.  

  2. 22

    I don’t see why I should try my ISP more than Cloudflare. My ISP is using DNS domain blocking for country-wide censorship.

    My concern with Cloudflare is centralization. But fortunately, DoH has started gaining some traction and more providers start to offer it out there.

    1. 13

      If you’re American, there’s probably no reason to trust your ISP more than cloudflare. However, most people are not American. For us, it’s kind of shitty if browsers start sending every query to an American megacorp which follows American privacy laws and is in a country where we have no legal power.

      I can expect my ISP to follow Norwegian privacy laws, which I’d bet are way better than American. If my ISP does something illegal according to our privacy laws, I have way more power to stop them than if an American company does the same.

      I know this will all be user configurable, but if it gets enabled by default, and it defaults to cloudflare, most people won’t change that. Most people won’t know DoH is a thing, much less the nuance regarding why they may or may not want to change the setting.

      1. 7

        Is Cloudflare going to be the default for the rest of the world? Mozilla is only rolling it out to the US, as this article even mentions. I haven’t seen any announcement what the plan is for the rest of the world, if there is any.

        1. 1

          If Mozilla is only rolling it out to the US, and never ends up rolling it out to the rest of the world, then yeah, my points don’t matter. However, I haven’t heard any statement that they won’t ever make DoH with cloudflare the default for the rest of the world, just that they’re not doing it yet.

          1. 2

            They have talked about having different regional defaults, and including more preset options in the dropdown for configuring DoH. This hasn’t happened yet, though.

        2. 10

          I’m not an American either. In my country (Greece) authorities can order ISPs to block certain domains on a DNS level, without any due process. And ISPs comply. DoH is the most user-friendly way for many people to access these websites.

          1. 2

            If cloudflare operates in that country, they would still have to comply with local laws, no? Just like all other services have to.

            1. 1

              Nope. Cloudflare is not consider an ISP for that country, so no need to comply. Same applies to any other public DNS service (eg. Google).

            2. 1

              If the blocking is only on a dns-level, it’s not much of a blocking method. It should redirect all traffic based on certain IP-numbers as well, which kind of defeats the purpose of the whole DoH endeavor.

              1. 2

                It’s a silly blocking method indeed, but it’s effective for the majority of the users who don’t know how to switch DNS settings on their systems. IP blocking is also ineffective, because IPs often change ownership.

        3. 51

          For someone who claims to care about privacy and the GDPR, it’s pretty shitty that (a) you don’t let me say “no” to you setting cookies in my browser, (b) the cookie was set even though I never clicked the “Accept” button at the bottom.

          1. -2

            The onus is on you to configure your cookie settings correctly, my dude.

            1. 3

              Not under the GDPR it isn’t, “my dude”

          2. 31

            It is clear what Mozilla needs to do: […] Also Mozilla can take real responsibility and work together with the Internet community and create RFCs for make DHCPv4, DHCPv6 and Router Advertisements support DNS URLs instead of just IP addresses. Mozilla could also help developing support in the operating systems, if privacy was really a concern for Mozilla.

            While I share some of the concerns, the belief that this is a viable alternative is whole crux of the article.

            Similarly to IPv6, not enough people are feeling any pain – or even inconvenience. Or similarly like we had to live with a catastrophic TLS stack (remember OpenSSL 0.9.8?) until heart bleed happened, because nobody cared except for cryptographers yelling into the void.

            In my eyes Mozilla is trailblazing here in the hopes that others will follow once there’s a critical mass/adoption. And opinions about CloudFlare (at least it’s not an ad company) aside, it’s an approach that worked before so it might not be the worst idea. I’m sure we’ll get an independent DoH provider eventually if the tech sticks.

            Also as others have pointed out: browsers nowadays already are special. They use their own DNS caching, TLS libraries, and often trust databases. They are the main mean for most people to interact with the internet therefore they’ll always have that special status.

            1. 16

              I found the “Enable DNS over HTTPS” setting in Firefox Developer Edition 69.0b16 (64-bit). It’s not (yet) checked automatically, but if I do check it, I have the option select “Cloudflare (default)” or specify a custom provider.

              1. 4

                It would be nice if you could specify a few to use in round-robin fashion.

                1. 3

                  That’s called loadbalancing and you can usually solve that either via DNS or by any other HTTPS loadbalancing method.

                  1. 7

                    via DNS, you say… :-)

                2. 2

                  I implemented my own DNS-over-HTTP/2 implementation for use at home (RFC-8484) isn’t that hard to implement) when it became apparent that Mozilla was shoving this down our throats. The recent version of Firefox wasn’t using it, this possibly explains why.

                3. 43

                  This is fear and speculation not based on facts.

                  Cloudflare’s DoH is compliant with GDPR, because there’s no PII sent or stored, apart from the technically-necessary IP of the TCP connection, and Cloudflare doesn’t even retain the IP address. It’s clearly stated in the privacy policy, which is very strict, and borderline paranoid. And compliance with the policy is audited externally by KPMG.

                  The author has written the entire article, including cutesy comic, and hasn’t even checked the one fact it is about?

                  Because the resolver doesn’t store personal info, and doesn’t store any non-aggregated logs beyond 24h, it’s pretty safe from being subpoenaed to hand the (non)data over.

                  The fear of U.S. government going as far as mandating implementation of a secret backdoor is a real one, but if it comes to this, we’re all fucked, because Firefox itself is under U.S-based Mozilla org/corp., and so is Google and Apple.

                  It would be better if the alternative was system-level DoH that uses a variety of trusted providers, but currently there’s no such thing. The actual alternative is sending unencrypted DNS packets, which we know are commonly logged and manipulated. The alternative is giving your DNS traffic to your ISP, who knows your real identity. You’ve probably clicked “Agree” on your ISP’s privacy policy that includes “sharing information with selected partners and affiliates”.

                  1. 15

                    The fear of U.S. government going as far as mandating implementation of a secret backdoor is a real one, but if it comes to this, we’re all fucked, because Firefox itself is under U.S-based Mozilla org/corp., and so is Google and Apple.

                    I don’t download Firefox from Mozilla; I get it from Debian, which is not a US-based org/corp. They have been good about stripping out the privacy-hostile gunk in browsers so far, and hopefully they will continue with this when DoH hits the versions they ship.

                    1. 2

                      I get it from Debian, which is not a US-based org/corp.

                      Software in the Public Interest is a US-based 501c3. They own the Debian trademark, domain name, and other infrastructure. They are as much “Debian” as MozFo is Mozilla.

                      1. 13

                        SPI does have no power over Debian Developers to force us to insert backdoors into Debian or anything similar. Also, the packaging process makes it very difficult for a DD to do so without other people noticing.

                        1. 1

                          They’re much more akin to MoFo.

                          1. 1

                            You’re right. Edited it.

                      2. 17

                        There is also the alternative of using DNSCrypt v2, which everyone seems to be ignoring

                        1. 13

                          I wonder why the planet wants to put everything over TCP, and then, put everything over HTTP, and then, put everything over JSON, and then, put HTTP over TLS, and then, put TLS over UDP into a merged QUIC, and then, put TLS over QUIC, and then …

                          DNSCrypt sounds a much simpler approach.

                          1. 7

                            Can whoever it was who voted incorrect please tell me why? Thanks

                          2. 16

                            Not really, I do not trust cloudflare or Google so I do not want to have DoH by default. This change literally makes your DNS requests dependent on one company.

                            On a different note, I do not believe my ISP in the Netherlands is allowed to share DNS data with third parties.

                            1. 9

                              I don’t understand. How does this make your DNS requests dependent on one company? Even with the defaults, the standard TRR mode has failover to the system resolver. Conceptually, you can easily switch your DoH provider or even run and use your own (which is easy to do w/ dnsdist-1.4.0 for example). The choices are even in the Firefox preferences and don’t require tinkering w/ about:config.

                              That being said, should Mozilla/Firefox prompt the user about these choices before enabling them quietly? Absolutely. But it should do these things for many other things too, such as your default search engine. Instead of disabling DoH, we should work on a better UX with these things.

                              1. 1

                                That’s a pretty selfish stance. Your Netherlands ISP doesn’t serve the entire world. But they do serve you, so fuck the actual billions of people using DNS outside of the EU?

                                Every time this comes up I see people complaining about how US-centric these arguments for DoH are. But insecure DNS isn’t a US problem, it’s a whole world problem. EU people bitching about DoH / Cloudflare come off like billionaires wanting another tax cut to me. There are people in these comments that live with DNS domain blocking for country-wide censorship.

                                1. 2

                                  People whose government is using such an ineffective censorship measure should feel lucky and protect the status quo. If your government is willing to deploy censorship, it’s a sure sign you cannot reason with that government. Better keep them unaware of their incompetence.

                              2. 5

                                This is fear and speculation not based on facts.

                                No, the author is basing himself upon facts and the fact that he/she is a Swiss citizen, which, in fact, have way more protection against, and democratic control over their own government than many Americans can ever dream of. It’s the country of secrecy and bank vaults after all.

                                Cloudflare’s DoH is compliant with GDPR, because there’s no PII sent or stored, apart from the technically-necessary IP of the TCP connection, and Cloudflare doesn’t even retain the IP address. It’s clearly stated in the privacy policy, which is very strict, and borderline paranoid. And compliance with the policy is audited externally by KPMG.

                                The GDPR is just the “lowest common denominator”. There is quite literally nothing preventing European countries (like Swistzerland) from adding on additional requirements on top of it, as many European countries have done so already. The fact that CloudFlare is GDPR-compliant, does not mean they are in compliance with all local laws as well.

                                Because the resolver doesn’t store personal info, and doesn’t store any non-aggregated logs beyond 24h, it’s pretty safe from being subpoenaed to hand the (non)data over.

                                This is something we have to blindly trust CloudFlare on. Your argument flows along similar lines as the one the co-founder of AirVPN made a couple of weeks ago. I debunked that thoroughly here back then. Besides: Cloudflare falls under US-jurisdiction, which means that the traffic might be intercepted even before it reaches their servers.

                                The fear of U.S. government going as far as mandating implementation of a secret backdoor is a real one, but if it comes to this, we’re all fucked, because Firefox itself is under U.S-based Mozilla org/corp., and so is Google and Apple.

                                Are we now? If such backdoors exist, they will probably not end up in the open-source versions of the browser, but they will show up in the binary distributions. For example, Slackware ships the entire source code including all the tools to build firefox from scratch, on their DVD-distribution. Debian has a system in which many builds are reproducible bit-for-bit. I think this greatly improves options and trust in case such a backdoor is found and we need to remove it. Although you would not have that much luck with any Apple, Google or Microsoft products.

                                It would be better if the alternative was system-level DoH that uses a variety of trusted providers, but currently there’s no such thing. The actual alternative is sending unencrypted DNS packets, which we know are commonly logged and manipulated.

                                Ever heard of DNSSEC? This makes the DNS-packets tamper-resistant to a very high degree.

                                The alternative is giving your DNS traffic to your ISP, who knows your real identity. You’ve probably clicked “Agree” on your ISP’s privacy policy that includes “sharing information with selected partners and affiliates”.

                                Well, I’ve read, and clicked “Agree” on my ISP’s privacy policy. However it did not contain a line similar to what you’ve just mentioned. It did however contain a line along the lines: “We will not share information with selected partners and affiliates beyond the minimum of what we need to provide you with your service, or when there exists a legal requirement to do so.” A surprisingly short list of what they share with whom and for which purposes follows shortly after that statement.

                                Granted: this also means I’m paying about €5 more per month than average, just like more than a million customers that deliberately chose the same ISP.

                                Which brings me to one of your other statements:

                                The author has written the entire article, including cutesy comic, and hasn’t even checked the one fact it is about?

                                The original author appears to be right, and I am sorry to say this, but it appears to be that that author is pretty well informed…

                                I also do not like the fact how you simply skimp over the subject of DNS-caching, which means that one ISP will simply request the DNS-records of a domain only once per TTL for all of its customers and every “home gateway” requests it once for every user behind it per TTL, while DoH would request the headers from cloudflare for each and every single client individually per TTL. This makes individual clients way more identifiable than they would have been with traditional DNS, especially once combined with DNSSEC.

                                However it certainly is not:

                                fear and speculation not based on facts

                                1. 2

                                  Instead of worrying about whether Cloudflare might violate the GDPR, a Swiss citizen can simply request they show they do comply, and refer it to the national data protection agency if they don’t.

                                2. 4

                                  The fear of U.S. government going as far as mandating implementation of a secret backdoor is a real one, but if it comes to this, we’re all fucked, because Firefox itself is under U.S-based Mozilla org/corp., and so is Google and Apple.

                                  The US government can’t mandate Mozilla include a secret backdoor because Mozilla provides Open Source software, not a service. Mozilla could try, but anyone who noticed something unusual about a change to the code could undo the whole thing. It isn’t even necessary that the auditor understand precisely what’s been done: All the auditor needs to do is notice that Mozilla suddenly dropped some unusual code into the program and it’s all over for the secret backdoor.

                                  1. 3

                                    It’s not always easy to tell the difference between malicious code and honest mistakes.

                                    https://flak.tedunangst.com/post/warning-implicit-backdoor

                                    1. 1

                                      Both malice and incompetence would be interesting to anyone watching the Firefox codebase.

                                      Also, sudden, uncharacteristic incompetence would likely be taken as a sign of malice.

                                      1. 1

                                        I think tedu’s point is that it’s nuanced. It’s easy to make mistakes that can be abused. And things that weren’t bugs/exploitable can become bugs/exploitable through good intent (cleaning up compiler warnings).

                                    2. 1

                                      How do you know that the binary they ship matches the source code? I don’t think Mozilla is doing reproducible builds yet. https://bugzilla.mozilla.org/show_bug.cgi?id=885777

                                      Someone apparently did manage to get a reproducible build for Firefox on Linux, though: https://glandium.org/blog/?p=3923

                                    3. 6

                                      Well said. Centralizing all this data isn’t ideal, but it’s incremental improvement of an internet standard. And that’s the only way they improve.

                                      1. 2

                                        Cloudflare could easily start a foundation, give it one up to date copy of each type of server they use, all the source code, two well rounded engineers, a bunch of money, etc, then kick them loose. Make their mission statement “to protect the world from technological monopolies”. Let’s call it Groundflare. They could offer every service cloudflare does, but in a non-profit manner.

                                        Is that too much? Ok.. Thinking smaller: the EFF and my ISP could operate DoH services.

                                        Then, Mozilla could put a “round robin” feature in there that let’s me tell Firefox to rotate between each service..

                                        1. 2

                                          Cloudflare has nearly 200 datacenters all over the world, with BGP-level routing to the nearest one. This requires a lot of deals for peering and colocation. It’s hard to do even if you can afford it — some of the networks will not even talk to you unless you’re the size of Cloudflare.

                                          Nothing stops you from setting up your own DoH for yourself, but handling traffic for all Firefox users is not that easy, especially if you want it to be competitive with the speed of DNS of their local ISP.

                                          1. 4

                                            Of course CloudFlare has enough redundancy to ensure to “never be down ever”. But human mistakes happen, precisely at BGP level, and precisely because they manage it at global scale.

                                            DNS is a distributed database system that is the source of security (everything runs over TLS when it needs security for public service, with certs from the usual CA). Using a “single, distributed vendor” is breaking the last component of internet that was distributed.

                                            The race never ends toward centralization, and we still have a lot to go: we can still boot our OS without connecting to an OAuth.

                                    4. 7

                                      Still waiting for someone to explain what “security” this provides. They can still see the IPs you connect to. Just look for the next SYN packet after a response comes back from a known DoH endpoint…

                                      The one thing this standard does is create a backdoor to make it harder for you to filter content on your network (as required by law in some situations) and makes it harder for your security team to detect bots/malware/intrusions by triggering on lookups to known malware C&C servers. TLS 1.3 plus this means it’s extremely difficult especially for critical infrastructure (e.g., power generation companies) to filter egress traffic effectively.

                                      If you want to stay out of prison for dissenting, you need a VPN*. If you want privacy, use a VPN*. This doesn’t solve either; it only makes it possible to avoid naughty DNS servers that modify your responses. But we already had solutions for that.

                                      * and make sure the VPN is trustworthy or it’s an endpoint you control.

                                      1. 7

                                        No need to put scare-quotes on security. It hides DNS traffic. Along with eSNI it hides the domains you’re visiting. And if the domain uses a popular CDN, this makes the traffic very hard to spy on, which is a measurable improvement in privacy.

                                        you need a VPN

                                        Oh no, aren’t VPNs evil, because, as you said yourself, they make “it harder for you to filter content on your network (as required by law in some situations)”?

                                        The false-sense-of-security traffic inspection middleboxes that were always easy to bypass with a VPN or even a SOCKS proxy, were needlessly weakening TLS for decades. Fortunately, they’re dead now.

                                        1. 1

                                          VPNs are much easier to block. You can do it at the protocol level for most types (you’re whitelisting outbound ports and protocols, right?) then you have lists of the public VPN providers to block as well.

                                          If you’re only allowing outbound TCP 443 and a few others someone could do TCP OpenVPN over it, but performance is terrible and it’s unreliable so most people don’t try.

                                          Regardless there are DPI devices which can fingerprint the OpenVPN traffic and tell it apart from HTTPS traffic because behaves differently (different send/receive patterns) and then you inject RST packets to break the session.

                                        2. 4

                                          Seeing IP’s that you connect to isn’t always useful, e.g. attacker wouldn’t realistically gain anything if a website you connect to is served through cloudflare, which serves enough different websites that it provides little information for the attacker.

                                          1. 4

                                            You can easily connect to the IP and grab the list of domains on the SAN certificate that CloudFlare is using on that IP address to figure out where they’re connecting. There’s only like 25 per certificate. It’s not hard to figure out if you are targeting someone.

                                            e.g., it would not be difficult to map 104.18.43.206 to the CloudFlare endpoint of sni229201.cloudflaressl.com and once you have that IP to CloudFlare node mapping sorted out you can craft a valid request …

                                            Subject Alternative Names: sni229201.cloudflaressl.com, *.carryingcoder.com, *.carscoloringpages101.com, *.caudleandballatopc.com, *.coloringpages101.com, *.cybre.space, *.emilypenley.com, *.indya101.com, *.nelight.co, *.scriptthe.net, *.shipmanbildelar.se, *.teensporn.name, *.thereaping.us, *.totallytemberton.net, *.voewoda.ru, *.whatisorgone.com, carryingcoder.com, carscoloringpages101.com, caudleandballatopc.com, coloringpages101.com, cybre.space, emilypenley.com, indya101.com, nelight.co, scriptthe.net, shipmanbildelar.se, teensporn.name, thereaping.us, totallytemberton.net, voewoda.ru, whatisorgone.com
                                            
                                            1. 2

                                              This list is encrypted in TLS 1.3, so you can’t easily grab it anymore (Firefox and Cloudflare also support eSNI, which plugs another hole).

                                              1. 1

                                                You misunderstand. I would create a database mapping of all CloudFlare nodes in existence: sniXXXXXX.cloudflaressl.com <—> IP addresses.

                                                When I see traffic to one of these IPs, I simply make a new TLS handshake to sniXXXXXX.cloudflaressl.com, grab the certificate, read all of the domain names in the certificate. I don’t need a plaintext SNI request to see where they’re going; I can just infer it by asking the same server myself.

                                                1. 2

                                                  You’ll only learn that all Cloudflare customers share a handful of IP addresses, and there are millions of sites per IP.

                                                  The certificate bundles aren’t tied to an IP, and AFAIK even the bundles aren’t constant.

                                                  1. 1

                                                    The server publishes a public key on a well-known DNS record, which can be fetched by the client before connecting (as it already does for A, AAAA and other records). The client then replaces the SNI extension in the ClientHello with an “encrypted SNI” extension, which is none other than the original SNI extension, but encrypted using a symmetric encryption key derived using the server’s public key, as described below. The server, which owns the private key and can derive the symmetric encryption key as well, can then decrypt the extension and therefore terminate the connection (or forward it to a backend server). Since only the client, and the server it’s connecting to, can derive the encryption key, the encrypted SNI cannot be decrypted and accessed by third parties.

                                                    That’s fine, then someone will just excise the encrypted SNI part to use it in a crafted packet that’s almost like a replay attack. That will still get you the list of 25ish domains they could have accessed.

                                                    Hell, this looks like you could eventually build a rainbowtables out of your captured SNI packets once you have sorted through the available metadata to see where they user went. (Assuming CF doesn’t rotate these keys regularly) Just analyze all sites on that cert, see all the 3rd party domains you need to load, and you can figure it out.

                                                    This is a small hurdle for a state actor

                                                    edit: I’m pretty sure you can just do a replay of the SYN to CloudFlare and not worry about trying to rip out the SNI part to get the correct certificate (TCP Fast Open)

                                                    edit2:

                                                    7.5.1.  Mitigate against replay attacks
                                                    
                                                       Since the SNI encryption key is derived from a (EC)DH operation
                                                       between the client's ephemeral and server's semi-static ESNI key, the
                                                       ESNI encryption is bound to the Client Hello.  It is not possible for
                                                       an attacker to "cut and paste" the ESNI value in a different Client
                                                       Hello, with a different ephemeral key share, as the terminating
                                                       server will fail to decrypt and verify the ESNI value.
                                                    

                                                    Yeah you can’t replay the ESNI value, but if you replay the entire Client Hello I think it should work. The server won’t know the client’s “ephemeral” ESNI key was re-used.

                                                    https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1

                                                    1. 4

                                                      The client Hello ideally only contains a client’s public key material, so you can’t decrypt the ESNI even if you replay the client hello. Unless you use a symmetric DH operation (which is rare and not included in TLS1.3) or break ECDH/EdDH/ECDHE.

                                                      1. 2

                                                        You are correct. I was going to post this after some coffee this morning. The response is encrypted with the client’s ephemeral ECDHE key.

                                                        So this breaks this type of inspection.

                                                        However, if you’re connecting to an endpoint that’s not on a CDN and is unique the observer can still figure out where you’re going. Is the solution we’re going to be promoting over the next few years to increase reliance on these CDN providers? I really don’t like what CloudFlare has become for many reasons, including the well known fact that nothing is free. They might have started with intentions of making a better web but wait until their IPO. Once they go public, all bets are off. All your data will be harvested and monetized. Privacy will ostensibly be gone.

                                                        In America it’s illegal to make ethical choices if it doesn’t maximize shareholder value. (Ebay v Newmark, 2010)

                                            2. 3

                                              yes, and that protects exactly.. no one who needs it.

                                              if you live somewhere where you need the security to hide your DNS requests, cloudflare will be the first thing to get blocked. the only really secure thing to do is onion routing of the whole traffic. centralizing the internet makes it more brittle.

                                              additionally: ease of use is no argument if it means trading-off security. these tradeoffs put people in danger.

                                              1. 3

                                                As someone who barely knows his TCPs from his UDPs, I had to read up on DoH, and I must say that a technology must be doing something right if it elicits both your reaction and the following from the Wikipedia article:

                                                The Internet Watch Foundation and the Internet Service Providers Association (ISPA)—a trade association representing UK ISPs, criticised Google and Mozilla for supporting DoH, as they believe that it will undermine web blocking programs in the country, including ISP default filtering of adult content, and mandatory court-ordered filtering of copyright violations.

                                                1. 3

                                                  i think DoH is the wrong solution for this problem, stuffing name resolution into an unrelated protocol. it may be true that it has the side-effect of removing the ISP-DNS-filters, but those can already be circumvented by using another name server.

                                                  a better solution would be to have a better UI to change the nameservers, possibly in connection with DNS over TLS, which isn’t perfect, but at least it isn’t a mixture of protocols which DoH is.

                                                  it could be an argument that the ISP could block port 53, and DoH would fix that. then we have another problem, namely that the internet connection isn’t worth it’s name. the problem with these “solutions” is that they will become the norm, and then the norm will be to have a blocked port 53. it’s a bit like the broken window theory, only with piling complexity and bad solutions.

                                                  maybe that’s my problem with it: DoH feels like a weird kludge like IP-over-ICMP or IP-over-DNS to use a paid wifi without paying.

                                                  1. 2

                                                    maybe that’s my problem with it: DoH feels like a weird kludge like IP-over-ICMP or IP-over-DNS to use a paid wifi without paying.

                                                    I agree with you that it feels like a kludge, it feels icky to me too.

                                                    But it’s something that could lead to a better internet - at the moment DNS traffic is both unencrypted, but more importantly, unauthenticated. If a solution can be found that improves this, even if it’s a horrible hack, I think it’s a net win.

                                                    Internet networking, like politics, is the art of the possible. We can all dream of a perfect world not beholden to vast corporate interests at every level of the protocol stack, but in the meantime the best we can hope for is to leverage some vast corporate interests against others.

                                                    1. 2

                                                      But it’s something that could lead to a better internet - at the moment DNS traffic is both unencrypted, but more importantly, unauthenticated. If a solution can be found that improves this, even if it’s a horrible hack, I think it’s a net win.

                                                      It may be a short term win, but in the end we are stuck forever with another bad protocol because nobody took the time and effort to build a better one, or just had an agenda.

                                                      Internet networking, like politics, is the art of the possible. We can all dream of a perfect world not beholden to vast corporate interests at every level of the protocol stack, but in the meantime the best we can hope for is to leverage some vast corporate interests against others.

                                                      DoH is just another way of centralizing the net. sure you can set another resolver in the settings, but for how long? you’d have to do that on every device. or use the syncing functionality which is.. centralized. and even, who does that?

                                                      i don’t think that “big players” in politics or in tech, do things out of altruistic reasoning, but, in the best case, good old dollar. that paired with most of the things being awful hacks (again in both, politics and tech) paints a bright future.

                                                      1. 2

                                                        I mean, the reality we live in now, where a company like Cloudflare has a de-facto veto on Internet content, just grew organically. It’s an inevitable consequence of technical progress, as stuff (like hosting, and DDoS protection) gets commoditized efficiencies of scale make large companies are the only ones who have a hope of making a profit.

                                                        To their credit, Cloudflare seem aware and uncomfortable about their role in all this, but that’s scant consolation as they’re under the same profitability requirements as the rest of the free world. They can be sold, or move to “evil” to save their profits.

                                                        1. 3

                                                          Yep - even prior to DoH, Cloudflare have BGP announce privileges and can issue certificates which are trusted by browsers, which are two powers which should never have been combined in the same entity (being able to funnel a sites traffic to your servers and also generate valid certs for those requests).

                                                          1. 2

                                                            I mean, the reality we live in now, where a company like Cloudflare has a de-facto veto on Internet content, just grew organically.

                                                            … and with their resolver being the default one they even have control over the rest, amazing!

                                                            It’s an inevitable consequence of technical progress, as stuff (like hosting, and DDoS protection) gets commoditized efficiencies of scale make large companies are the only ones who have a hope of making a profit.

                                                            the need for something like DDoS protection is more a consequence of full-throttle capitalism ;)

                                                            1. 1

                                                              with their resolver being the default one

                                                              For the fraction of internet users running Firefox, sure. Google will handle the rest. No doubt MSFT will hop on board too.

                                                              the need for something like DDoS protection is more a consequence of full-throttle capitalism

                                                              Or technical debt inherited from a more trusting vision of the internet…

                                                              (edit addressed Cloudflare’s role as default DoH provider for Firefox)

                                                    2. 2

                                                      UK ISPs have to block child porn or the CEO will be held accountable and go to prison. They do DNS filtering, because IP filtering is impossible. Now they can’t even do that.

                                                      1. 5

                                                        I’m aware of the legal requirements of UK ISPs (although why they feel they need to celebrate this requirement by awarding (then withdrawing) the “Internet Villain of the Year” to Mozilla is beyond me).

                                                        I guess the “responsibility” for filtering/blocking will move up to Cloudflare.

                                                        1. 1

                                                          we’ve had a lengthy political discussion in germany about this topic (where “filtering” was a long time the preferred political solution) now the policy is to ask the respective hoster to delete these things. i have no good english source for this, so here is the translated german wikipedia article (original)

                                                          1. 3

                                                            You can push the ISP to DNS block it (though it’s harder and usually leads to years-long court cases as in Vodafone’s case).

                                                            Telekom also loves to push their own search engine with advertisements for NXDOMAIN responses.

                                                  2. 3

                                                    Still waiting for someone to explain what “security” this provides. They can still see the IPs you connect to. Just look for the next SYN packet after a response comes back from a known DoH endpoint…

                                                    It does one useful thing: It prevents them from MITMing these packets and changing them.

                                                    I’d like encrypted DNS, but I’m very strongly against Firefox selecting my DNS resolver for me for reasons that have already been stated in threads here. I also strongly prefer keeping the web stack out of my relatively simple client-side DNS resolver. Diverse ecosystems are important, and the only way to maintain them is to keep software simple enough that it is cheap to implement.

                                                    1. 1

                                                      It does one useful thing: It prevents them from MITMing these packets and changing them.

                                                      Sure, but that’s rare. It would require a targeted attack or a naughty ISP to be altering results.

                                                      What it most certainly does is prevent me from forcing clients to use my on-premises DNS resolver. Now you have zero controls over the client devices on your network when it comes to DNS and additionally we’re about to lose HTTPS inspection in the near future. This is the wrong approach to solve the problem. Admins need controls and visibility to secure their networks.

                                                      Mark my words, as soon as this is supported by a few different language libraries you’ll see malware and all sorts of evil things using it to hide exfiltration and C&C because it will be hidden in the noise of normal user traffic.

                                                      It will be almost impossible now to stop users or bad guys from accessing Dropbox, for example. “Secure the endpoints” is not the answer. You can secure them, deny BYOD, etc, but you have to assume they’re compromised and/or rooted. Only the network is your source of truth about what’s really happening and now we’re losing that.

                                                      1. 4

                                                        I guess I don’t have much sympathy for the argument that network administrators will lose insight into the traffic on their networks. That seems like a bonus to me, despite the frustration for blue teams.

                                                        1. 3

                                                          Same. I understand that in some places there are legal auditing requirements, but practically everywhere else it’s just reflexive hostility towards workers that makes us use networks that are pervasively censored and surveilled.

                                                        2. 4

                                                          Sure, but that’s rare. It would require a targeted attack or a naughty ISP to be altering results.

                                                          Except that it’s not rare. You will find this in many hotel wifis. This hits you particularly hard if you have a DNSSEC validating resolver, which doesn’t take kindly to these manipulations. Having a trusted recursor is generally important if your want to be sure that you talk to a resolver you can actually trust, which is in turn important if you want to delegate validation.

                                                          What it most certainly does is prevent me from forcing clients to use my on-premises DNS resolver.

                                                          Just as HTTPS prevents you from forcing your clients to talk to an on-remise cache or whatever. The solution is the same in both cases. You need to intercept TLS, if this is a hard requirement for you. DoH and DoT isn’t making anything more complicated, its just bringing DNS on par with the protection level we have had for other protocols for a while.

                                                          1. 3

                                                            You hit the nail on the head here. Far from being rare, in the US it’s ubiquitous, whether it’s your hotel, your employer, or your residential ISP.

                                                          2. 3

                                                            Only the network is your source of truth about what’s really happening and now we’re losing that.

                                                            Good. Corporate networks must die. “Secure the endpoints” is THE ONLY answer.

                                                            https://beyondcorp.com

                                                            If Google can pull it off at Google scale, so can you. Small teams with lots of remote people have always been Just Using The Internet with authentication. It’s the “Enterprise”™ sector that’s been suckered into buying “Security Products”™ (more like “Spying Products”) to keep trying to use this outdated model.

                                                            1. -1

                                                              You clearly know nothing about running critical infrastructure networks, so please refrain from making these types of comments.

                                                            2. 2

                                                              What it most certainly does is prevent me from forcing clients to use my on-premises DNS resolver.

                                                              Could you please elaborate? Is this about a “non-canonical” local resolver or do you think it also has repercussions for locally hosted zones? For example *.internal.example.org locally versus *.example.org on the official internet. Or did I misunderstand you and you just meant a local forwarding resolver?

                                                              I honestly didn’t read up enough on DoH yet, just wondering.

                                                              1. 1

                                                                Mark my words, as soon as this is supported by a few different language libraries you’ll see malware and all sorts of evil things using it to hide exfiltration and C&C because it will be hidden in the noise of normal user traffic.

                                                                Setup your own DoH server and you can once again inspect it. Ideally you use a capable and modern TLS intercepting box to inspect all traffic going in and out (as well as caching it).

                                                                1. 1

                                                                  Mark my words, as soon as this is supported by a few different language libraries you’ll see malware and all sorts of evil things using it to hide exfiltration and C&C because it will be hidden in the noise of normal user traffic.

                                                                  How? The IP or the URL of the DoH server you are talking to will stand out like a signal flare… I think that dumping the file to a cloud-service is way more efficient, easier and effective.

                                                                  1. 1

                                                                    The US Gov often gives early reports to security teams of Critical Infrastructure networks details on all sorts of potential attacks, including early heads up on malware that may or may not be targeted. This includes a list of C&C domains that may be accessed. If the software can hide its DNS requests by making it look like normal HTTPS traffic to CloudFlare, that makes it even harder to identify the malware’s existence on your network.

                                                                    If you want the Russians or Chinese to hack our grid, this is a great tool for them along with TLS 1.3. The power generation utility that I worked at did HTTPS interception and logging of ALL HTTPS and DNS requests from every device everywhere for analysis (and there was a program coming online to stream it to the government for early detection) and now this is becoming impossible.

                                                                    1. 1

                                                                      This pertains only to firefox… So why would an installation of firefox be on one of those networks?

                                                                      Furthermore: You know the ip of cloudflare’s DoH server. You could just block that and be done with it right? If the malware uses some other server, that will show up as well.

                                                                      1. 2

                                                                        Firefox won’t be on that network, but HTTPS certainly will be. Likely not on (hopefully still airgapped) SCADA, but on other sensitive networks that give some level of access into SCADA through various means.

                                                                        The point is that as DoH thrives and becomes commonplace and someone like CloudFlare runs this service, it’s easy to hide DNS requests mixed in with normal looking HTTPS traffic. The client can be a python script with DoH capability.

                                                                        As for CloudFlare’s DoH service – it appears to be running on separate IPs at the moment, but there’s no reason why they couldn’t put this on their normal endpoints. DoH is HTTPS, so why not share it with their normal CDN endpoints? This would not be difficult to do in Nginx. In fact this would be far simpler than running HTTPS and SSH on the same port, which is also possible.

                                                                        Basically any normal-looking HTTPS endpoint could become a DoH provider. Hack some inconspicuous server, reconfigure their webserver to accept DoH too, and now you’ve got the backdoor you need for your malware.

                                                                        CloudFlare and Firefox are not my concern; DoH as a whole is.

                                                                        1. 1

                                                                          As for CloudFlare’s DoH service – it appears to be running on separate IPs at the moment, but there’s no reason why they couldn’t put this on their normal endpoints. DoH is HTTPS, so why not share it with their normal CDN endpoints? This would not be difficult to do in Nginx. In fact this would be far simpler than running HTTPS and SSH on the same port, which is also possible.

                                                                          Fair point…

                                                                          But now I’m wondering why you would have access to cloudflare on such a network… Or why there won’t be a root-certificate on all the machines (and firefoxes) in the network so that the organization can MITM’s all outgoing traffic?

                                                                          1. 1

                                                                            There are going to be some networks running servers that need outbound HTTPS for various reasons, but a lot of that can be locked down. But what about the network that the sysadmins are on? They need full outbound HTTPS, and a collaborating piece of malware on one of their machines gives them access to the internet and to other internal sensitive networks. These types of attacks are always complex and targeted. Think of the incredible work we did with Stuxnet.

                                                                            As for MITM the traffic… look at this thread where it’s being discussed further https://lobste.rs/s/pechdy/turn_off_doh_firefox_now#c_inbnse

                                                                            1. 1

                                                                              There are going to be some networks running servers that need outbound HTTPS for various reasons, but a lot of that can be locked down.

                                                                              So why cloudflare? I doubt you’d need any high-volume sites that use cloudflare for those setups.

                                                                              But what about the network that the sysadmins are on? They need full outbound HTTPS, and a collaborating piece of malware on one of their machines gives them access to the internet and to other internal sensitive networks. These types of attacks are always complex and targeted. Think of the incredible work we did with Stuxnet.

                                                                              If the networks really are that sensitive, just separate them physically, give the sysadmins two machines and never transport data in digital form from the one to the other….

                                                                              If you are not willing to take these kinds of steps, your internal networks simply aren’t that critical.

                                                                              1. 2

                                                                                That is not how the networks at our power utilities work. And it’s not how the employees operate either.

                                                                                1. Many power companies refuse to implement new technologies or network topologies unless another utility does it first. Which sadly means that in certain regions like MISO you can expect most of the utilities to be using the same firewalls, etc etc. Very dumb. Can’t wait for Russia to abuse this and take down half the country.

                                                                                2. The people that work there aren’t the brightest. “Why are user accounts being managed with a perl script that overwrites /etc/passwd, /etc/shadow, and /etc/groups?” Well because that’s the way they’ve always done it, so if your team needs to install a webserver you also need to tell them to add the www user to their database so the user account doesn’t get removed. “Why are the admins ssh-ing as root everywhere with a DSA key that has no passphrase protection?” because the admins (of 20 years experience) refuse to learn ssh-agent and use basic security practices. I had meetings with developers who needed their application to be accessible across security domains and the developer couldn’t tell me what TCP port their application used. “What’s a port?”. These are people making 6 figures and doing about 30 minutes of work a day. It’s crazy.

                                                                                3. These are highly regulated companies with slim margins. You want these kinds of drastic changes to their infrastructure? You better start convincing people to nationalize the grid because they don’t have the money to do it. Remember, it takes about 3 years to get a utility rate change approved. It’s a long process of auditing and paperwork and more auditing and paperwork to prove to the government that they really do need to increase utility rates to be able to afford X Y and Z in the future. They’re slow moving. Very slow.

                                                                                4. Do you think customers will want their power bills to go up just so they can hire competent IT staff? Not a chance. (What we really need to do is stop subsidizing bulk power customers and making normal residential customers pay more than their fair share, but that’s a different discussion)

                                                                                tl;dr we can all wish hope and pray that companies around the world will do the right thing, but it’s not going to happen anytime soon, especially in Critical Infrastructure environments because they’re so entrenched in their old ways and don’t have the budgets to do it the right way regardless.

                                                                                1. 1
                                                                                  1. In utility companies, the production networks running the power plants should simply not come into contact with the internet. There should always be a human inbetween the network and the internet. If this is not the case, they deserve what’s coming.

                                                                                  2. Believe it or not. I can actually understand why they dump into /etc/groups, /etc/passwd and /etc/shadow. There is no chance of any machine having an outdated users by accident or by partial configuration this way, and if your network has only a few hundreds of users, which are all more or less trained to deal with complex technological systems on a basic level. Why not? It’s not like they are running a regular common office workplace.

                                                                                  However, what you are telling me about SSH and TCP is quite shocking. That is just plain incompetence.

                                                                                  1. I’m not living in the US. In fact; the last time I’ve been there I was at an age from which I can barely remember anything other than that the twin towers still stood. I am often told that it’s a different country now, so I can’t say anything useful about this.

                                                                                  2. Depends…. If the outages are below about 2 short power outages per year on average, then no I wouldn’t.

                                                                                  If it starts to escalate to one outage per month and 25% of them can be blamed on incompetent IT-staff? You’ve reached the point where I am going to install my own diesel generators as those will quickly become profitable.

                                                                      2. 1

                                                                        I don’t quite understand. Regardless of the TLS version, if you want to inspect https you need to intercept and decrypt outgoing https traffic via a middlebox. This applies to regular https just as it applies to DoH. If you are required to secure your network inspecting encrypted traffic, you will continue to do so just like you’ve always done. In this sense, DoH is even less intrusive than, say, DoT because your standard https intercept proxy can be adapted to deal with it.

                                                                        1. 1

                                                                          Wasn’t the goal of TLS 1.3 to make interception impossible? I am certain that was one of the major goals, but I didn’t follow through the RFC’s development.

                                                                          How would interception work? With ESNI in TLS 1.3, the client does a DNS lookup to retrieve the key to encrypt the ESNI request with. The middlebox couldn’t decrypt the ESNI and generate a certificate by the local trusted CA because it doesn’t know the hostname the client wants to access. So now… a middlebox will also have to be a DNS server so it can capture the lookup for the ESNI key, generate a fake key on demand, and have it ready when the TLS connection comes through and is intercepted?

                                                                          This is getting quite complex, and there may be additional middlebox defeat features I’m not aware of

                                                                          1. 1

                                                                            No, the basic handshake can still be intercepted similarly to TLS 1.2, so that’s not a problem with 1.3.

                                                                            ESNI might be a slightly different issue. But you could just take a hardline stance and drop TLS handshakes which use ESNI and filter the ESNI-records (with a REFUSED error?) in your resolver. If you need to enforce TLS intercept, you will need to enforce interceptability of that traffic and that might mean refusing TLS handshakes which use ESNI. But I heaven’t read the RFC drafts yet, so there might be easier/better ways to achieve this. In any case, none of this should be a deal breaker. TLS intercept proxies have always been disruptive (e.g. client certificates cannot be forwarded past an intercept proxy) and this will apply to ESNI just as it has done to past aspects of TLS.

                                                                            What I feel should be clear is that none if this will suddenly turn existing practices impossible. Restrictive environments will continue to be able to be restrictive, just as they have in the past. The major difference will hopefully be that we will be safer by default even in open networks, such as public wifis, where a large number of users are currently exposed to unnecessary risks.

                                                                            1. 1

                                                                              ESNI might be a slightly different issue. But you could just take a hardline stance and drop TLS handshakes which use ESNI and filter the ESNI-records (with a REFUSED error?) in your resolver. If you need to enforce TLS intercept, you will need to enforce interceptability of that traffic and that might mean refusing TLS handshakes which use ESNI.

                                                                              I don’t think this is possible. TLS 1.3 means ESNI is a given. If half the internet uses TLS 1.3-only, you have no choice but to support it. AIUI they’ve gone to great lengths to prevent downgrade attacks which will stop the interception.

                                                                              I have a contact at BlueCoat and am reaching out to see what the current state is because their speciality is exactly this.

                                                                              1. 1

                                                                                TLS 1.3 means ESNI is a given.

                                                                                Right now, ESNI is not mandatory for TLS 1.3. TLS 1.3 is a complete and published RFC standard. ESNI is only a draft and is certainly not mandated by TLS 1.3. You don’t need to run downgrade attacks to “intercept” TLS 1.3. Intercept proxies simply complete the TLS handshake by returning a certificate for a given domain issued by a custom CA that’s (hopefully) in the client’s trust store. This works just the same for 1.3 as it does for any earlier method.

                                                                                1. 1

                                                                                  Do we know the failure mode is if ESNI is rejected? Everyone wants ESNI for their privacy and browsers will certainly implement it, so it will be more common than not I suspect.

                                                                                  edit: and thanks, I was still operating under the impression that ESNI was part of the final TLS 1.3 draft. I haven’t taken the time to read through it all and there’s a lot of misinformation out there. I’ve been too busy to dig in deeper, and security is not my day job right now.

                                                              2. 6

                                                                How will this not break the planet? On a corporate network, you need to handle corporate/internal DNS. This will either require companies who support FF to create group policies or custom packages which disable this by default, or individual devs who installed it manually with local admin rights to wonder, “Why the fuck can’t I get to anything internal via Firefox.”

                                                                And I agree with the post. I don’t trust CloudFlare. I’ve written about my distrust of them before:

                                                                https://fightthefuture.org/article/the-new-era-of-corporate-censorship/

                                                                And they’ve continued to do the same crap since that post as well. No thanks Firefox. You can make it a popup/choice, but setting it by default is shitty.

                                                                1. 4

                                                                  Mozilla has explained how they made it work with custom DNS of intranets and parental controls:

                                                                  https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/

                                                                  1. 1

                                                                    Well, the czars of the PC fleet around here don’t push Firefox configs. They push Outlook configs, etc, so, it wouldn’t be unheard of.

                                                                    I’ll have to use the ‘excluded domains’ feature. Go into about:config and search for network.trr.

                                                                  2. 5

                                                                    Yes, I can confirm that activating DoH breaks intranet sites. The embarrassing part is all those tickets I filed at my helpdesk regarding the intranet site being down, in Firefox only…

                                                                  3. 18

                                                                    Applications don’t manage the network

                                                                    This entire paragraph reeks of “King of the Castle” attitude. 5 years ago I interacted with a sysadmin who had the same arguments for why every network device should go through his local HTTP proxy.

                                                                    Just imagine the pure mess if you get different DNS results in different applications.

                                                                    Well, what does the author imagine will happen? I don’t know. I don’t think it matters if two apps resolve to different IPs. What would happen if two devices resolved some hostnames to different IPs? Probably the same thing: Nobody cares.

                                                                    btw Firefox caches DNS results independently of the OS, and I believe so does Chrome. These out of sync issues already happen and they are not a big deal.

                                                                    The chaos will be a perfect Trump made Internet.

                                                                    Oh yeah, that’s how you connect Mozilla to Trump. Nicely done. You just had to taint your best argument (US govt can’t be trusted) with that line.

                                                                    I expected nothing based on the title and was still disappointed.

                                                                    1. 9

                                                                      I don’t think it matters if two apps resolve to different IPs. What would happen if two devices resolved some hostnames to different IPs? Probably the same thing: Nobody cares.

                                                                      As someone who semi-regularly has to debug connectivity issues people have with various services, it’s rather annoying not to be able to get the same DNS results when manually resolving addresses using the OS settings, especially if one doesn’t know about the fact that Firefox has started doing this.

                                                                      1. 4

                                                                        Yes, it has annoyed me too. DoH is not introducing this problem though.

                                                                        1. 7

                                                                          It does introduce the problem though. Problems related to application level DNS caching are easily bypassed by just having them restart the browser. But if your browser claims to not be able to resolve a name, or resolves it to something different due to split-horizon DNS, and everything else on the machine is able to resolve the name properly, how would you debug this?

                                                                          (So according to https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/ it should fall back to the OS resolver on failures, so at least ones that don’t exist externally should work, though that doesn’t really help when the public address resolve differently.)

                                                                          1. 7

                                                                            Pertinent example:

                                                                            (11:42:26) om:~% dig +short @8.8.8.8 archive.is
                                                                            62.192.168.106
                                                                            (11:42:35) om:~% dig +short @9.9.9.9 archive.is
                                                                            51.15.97.128
                                                                            (11:42:43) om:~% dig +short @1.1.1.1 archive.is
                                                                            127.0.0.3
                                                                            

                                                                            uh oh!

                                                                            1. 3

                                                                              Apparently archive.is is refusing to respond to 1.1.1.1: https://twitter.com/archiveis/status/1018691421182791680

                                                                      2. 3

                                                                        Oh yeah, that’s how you connect Mozilla to Trump. Nicely done. You just had to taint your best argument (US govt can’t be trusted) with that line.

                                                                        Exactly! This article felt nothing more than a scare tactic due to the author having un-moving opinions on the matter, resulting in him using points that aren’t even accurate. Author’s need to learn to have more perspective, share their own perspective, and back their sources

                                                                      3. 9

                                                                        A little bit too much FUD for my taste. Local administrators can use https://use-application-dns.net/ or group policies etc.

                                                                        The threat DoH protects against is data retention, NSA Prism/XKeysxore etc. The IP is still in the clear but the DNS name is easier to encrypt and provides meaningful progress - especially for stuff that doesn’t have its own server (CDNs, Azure, AWS, GCP etc. )

                                                                        (I work at Mozilla, but not on DoH. This is my personal opinion. I’ve been skeptic too, but there’s an interesting discussion to be had - if you look beyond the FUD)

                                                                        1. 4

                                                                          Hm I’ve been a Firefox user for 15 years and this is the first I’ve heard of it. Looking at this blog post, it doesn’t mention “Cloudflare”:

                                                                          https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/

                                                                          If it’s true, that concerns me.

                                                                          I can see the argument that Cloudflare provides a useful service, but I don’t want Cloudflare handling my traffic because they’re basically a MITM-as-a-service, which taking on a great responsibility.

                                                                          They failed in that responsibility by leaking private data all over the Internet:

                                                                          https://en.wikipedia.org/wiki/Cloudbleed

                                                                          As far as I remember at the time, that bug could have easily prevented by running a Valgrind or ASAN build on 1000 or so test HTML pages.

                                                                          That is, it could have been trivially found if they did basic industry-standard testing. To me that indicates that they’re sloppy and cavalier about their engineering practices. Also the reaction by the company’s leaders appeared to be to minimize the severity of this error.

                                                                          1. 4

                                                                            I think the article pays attention to the wrong threat model, and places too much trust in ISPs.

                                                                            If my threat model is ‘$LETTER_AGENCY may want to know where I’ve been browsing’ then I lose whether my DNS requests end up with my ISP or with Cloudflare. In fact, my ISP already blackhole certain domains at the request of the government, so I have no reason to believe they wouldn’t hand over a log of my queries if the government requested it.

                                                                            Where DNS-over-HTTPS seems better placed is in protecting against active or passive interception of my requests - another thing some ISPs are known to do even if you choose not to use their resolvers.

                                                                            If you want to hide from Cloudflare, use different DNS servers. If you want to hide from governments, use Tor.

                                                                            If you’re in neither of those camps, DoH gives you a bit of extra protection for little cost. Hopefully we can break the Cloudflare dependency in future as it becomes more common, but I don’t agree that it is worse than the existing common use case.

                                                                            1. 4

                                                                              I’m surprised nobody mentioned using DNS-over-HTTPS and DNS-over-TLS over Tor to protect the identity of the client.

                                                                              1. 3

                                                                                The chaos will be a perfect Trump made Internet.

                                                                                I’m confused. Can someone explain how this is related to Donald Trump?

                                                                                1. 2

                                                                                  His campaign was a featured client of the service for several years on their front page.

                                                                                2. 3

                                                                                  Can someone do this for HTTPS and Let’s Encrypt, please?

                                                                                  1. 4

                                                                                    Do what? Write a terrible blog post asking everyone to turn off HTTPS?

                                                                                    1. 2

                                                                                      write a good blog post, asking for not centralizing the certificate authority for 30% of the web.

                                                                                    2. 1

                                                                                      another welp: my submission of the CAcert mail here got insta flagged as spam. CAcert isn’t perfect but it’s a really good idea imho.

                                                                                      1. 4

                                                                                        I flagged it as spam, as it was literally a solicitation for payment from an organisation.

                                                                                        1. 1

                                                                                          They shot themselves in the foot when they effectively asked for their cert to be removed from OpenBSD due to their choice of licence.

                                                                                          If they’re so negligent in licence selection, who knows what other shortcuts they take?


                                                                                          As for https, it should be optional, shouldn’t require a central certificate authority for random websites and blogs, and folks shouldn’t be FUD’ed into believing that their website needs encryption no-matter-what.

                                                                                      2. 4

                                                                                        Perhaps I’m missing something obvious, but… why can’t we have DoH without Cloudflare? What’s to stop me from running my own DoH server?

                                                                                        1. 5

                                                                                          Absolutely nothing. Cloudflare is a red herring.

                                                                                          1. 1

                                                                                            It’s true that the DoH configuration interface in the Nightly and Beta releases of Firefox already presents the option to use another provider.

                                                                                            But it’s … nearly disingenuous to consider this issue in the abstract…

                                                                                            May I rephrase the question?

                                                                                            Why won’t we have DoH without Cloudflare?

                                                                                            • Because only one in 10 thousand Firefox users ever change a single configuration setting, much less such an esoteric one.
                                                                                            • Because it’s not in Cloudflare’s interest, and they are powerful.
                                                                                            • Because it’s not in the interest of that subset of Mozillians who intend to run it more like a corporation.
                                                                                            • I am not aware of Firefox-compatible DoH providers. (Not saying there aren’t any, but.. see first bullet!)

                                                                                            Now for this one:

                                                                                            What’s to stop me from running my own DoH server?

                                                                                            The D in DNS stands for Distributed. You may operate a DNS server. By design, your DNS server will respond to queries when it knows the answer, it will speak to peers DNS servers to learn new answers, and it will speak to superior DNS servers when peers don’t know the answer. (Or something like that! I’m no DNS expert.)

                                                                                            There are many gratis, libre, proprietary, and commercial DNS server software options available for every OS and hardware combination that could conceivably become connected to a network.

                                                                                            But Firefox DoH is operated by Cloudflare. Full stop. It was designed to be operated by a single large entity from day one.

                                                                                            The authors’ presentation of their arguments may be flawed, but I believe that their position is correct in principle: A Firefox default-on DoH via Cloudflare will be bad for the Internet.

                                                                                            1. 5

                                                                                              The D in DNS stands for Distributed.

                                                                                              No, it stands for Domain. Domain Name Service.

                                                                                              I agree with you, but please don’t promote my side of the argument using bad information.

                                                                                              1. 2

                                                                                                Hm, that’s weird. Uh… Hm. ?:)

                                                                                              2. 3

                                                                                                I am not aware of Firefox-compatible DoH providers. (Not saying there aren’t any, but.. see first bullet!)

                                                                                                There are several: https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers

                                                                                                The D in DNS stands for Distributed. You may operate a DNS server. By design, your DNS server will respond to queries when it knows the answer, it will speak to peers DNS servers to learn new answers, and it will speak to superior DNS servers when peers don’t know the answer. (Or something like that! I’m no DNS expert.)

                                                                                                You’re understanding of DNS seems flawed here (aside from it standing for Domain Name System instead of Distributed… Name System?). I’d do more reading. DoH itself isn’t evil, and I think that’s one of the unfortunate side-effects of this whole controversy – the technology being blamed for the defaults Firefox is setting.

                                                                                                You can have a resolver in your network that speaks plain DNS do DoH to the outside world if you wanted. Due to the distributed nature of DNS, DoH servers themselves can be recursive resolvers, and ask other DNS servers for answers that it doesn’t know about.

                                                                                                The distributed nature of DNS doesn’t end with DoH. The problem (as I see it, at least) is that it centralizes client DNS comms to Cloudflare. If Firefox shipped a list of DoH servers that weren’t connected to Cloudflare, and randomly distributed customers across them, then I think this would be a very different conversation.

                                                                                                But Firefox DoH is operated by Cloudflare. Full stop. It was designed to be operated by a single large entity from day one.

                                                                                                I even agree with not wanting the default to be cloudflare, but this whole answer seems pretty ill-informed.

                                                                                                1. 3

                                                                                                  But Firefox DoH is operated by Cloudflare. Full stop. It was designed to be operated by a single large entity from day one.

                                                                                                  That’s not true. You can configure Firefox to use any DoH server out there. It “just” uses Cloudflare’s DoH servers by default. You can change this in the settings and you can modify the behaviour even more by going the about:config route.

                                                                                                  And you can run your own DoH server. I’m doing this right now. You still have the freedom to use your own services for this, just like you did with plain DNS. For some odd reason the whole DoH discussion has become tied up with the myth that it is somehow forcibly connected to Cloudflare. It isn’t. It’s just a bad default. We should discuss the bad default and DoH seperately, but this has become a tangled up and overly emotional mess for most people.

                                                                                                  1. 2

                                                                                                    I am not aware of Firefox-compatible DoH providers.

                                                                                                    I believe Google is also running a DoH service, presumably for the future benefit of Chrome.

                                                                                                    Not gonna configure my Firefox to point there, though.

                                                                                              3. 4

                                                                                                rant: welp, DoH is what we get for rebuilding everything as webshit instead of fixing things at the source and on the real layers. hell, we still have no full ipv6 rollout and need nat and stun and turn and $kludge to keep things working.

                                                                                                1. 1

                                                                                                  How is IP-level stuff related to making DNS encrypted?! These are extremely orthogonal things!

                                                                                                  stun and turn and $kludge

                                                                                                  You only need that for P2P connectivity. The majority of users just want to browse the web, which does not have that problem.

                                                                                                  1. 4

                                                                                                    How is IP-level stuff related to making DNS encrypted?! These are extremely orthogonal things!

                                                                                                    nat is as good a solution instead of just using ipv6 as doh is for securing lookups, imho. its not about encrypting dns, it’s about how it’s done.

                                                                                                    You only need that for P2P connectivity. The majority of users just want to browse the web, which does not have that problem.

                                                                                                    let me rephrase: the majority of users just browses the web, because it’s the only thing which kind-of works reliably without fiddling with nat settings.

                                                                                                2. 2

                                                                                                  Hm, Google operates a DoH service that seems to compete with Cloudflare’s. https://developers.google.com/speed/public-dns/docs/doh/

                                                                                                  Can Firefox talk to it? I tried just now but I determined that Firefox silently falls back to regular DNS if your DoH configuration fails. (Bit of a design flaw if one of the goals really is personal privacy!)

                                                                                                  1. 1

                                                                                                    Can Firefox talk to it? I tried just now but I determined that Firefox silently falls back to regular DNS if your DoH configuration fails. (Bit of a design flaw if one of the goals really is personal privacy!)

                                                                                                    That’s the best of both worlds — by default, all your communication will be subject to NSA jurisdication, and if it doesn’t fit anyone’s fancy for any reason, they can still hijack the traffic for themselves!