DNS-over-HTTPS Policy Requirements for Resolvers • Hacker News Board

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#211

Post by simondedalus » Wed, Apr 10, 2019, 8:58 PM UTC

close04 wrote: post #181

simondedalus wrote: post #172

Earlier quoted context omitted.

firefox messes up their DNS filtering, chrome doesn't. so they remove firefox and enforce chrome. if you see that as a slippery slope, you're imagining it. they probably 1) have a decent app like ninite to remove and install apps, 2) don't have anything but their production environment, 3) don't have a homogenous environment in terms of patching (maybe they do), 4) don't have people to go around and make sure the con…

> firefox messes up their DNS filtering, chrome doesn't I take it you assume students are not creative enough to get the exact same result with Chrome? Because it is perfectly possible to do it. Unless of course you take steps to prevent that in Chrome. One way or another you either put in the work or the users will end up doing whatever they please. After configuring the OS doing the same for the browser is a relati…

of course it's possible to do so. but DNS filtering works for most users, and is much easier to centrally manage on a budget (in terms of time / people / money) than browser settings.

i'm belaboring this point now, but people who actually do this stuff know that you can't just throw up a GPO to fiddle with chrome settings and expect everything to work. this culture of "power users" thinking they know the best course of action for every situation in IT (and it's always "that thing i Put In The Work to do when i was tailoring my own system") is really silly.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#212

Post by simondedalus » Wed, Apr 10, 2019, 9:01 PM UTC

close04 wrote: post #180

simondedalus wrote: post #91

Earlier quoted context omitted.

no, using the nuclear option of removing the browser outright when others work is the smart, efficient option that someone who actually works in IT with limited resources would (and should) use. this stuff about finding all the right config files during "basic hardening" and having it just work is the stuff of armchair commenters and people who do IT/security on a well funded, sufficiently redundant team. assuming th…

So tell me then, what exactly are you achieving with removing Firefox when the same bypass can easily be achieved with Chrome? Remove Chrome also? Call the well funded security team to configure whatever browser you’ll eventually have to use? The problem with half assed work is that you still put in some effort but reap none of the rewards. You work to uninstall Firefox from dozens of computers but get exactly 0 resu…

the DNS filtering works on chrome. yes, people can bypass it, but it doesn't even work on firefox, so they remove firefox. this isn't rocket science, and you're being foolishly contrarian instead of trying to understand what the original commenter's actual situation is. this leads me to believe that you are hypothesizing about work you don't do, but feel perfectly qualified to talk about "half assing" things.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#213

Post by shawnz » Wed, Apr 10, 2019, 9:13 PM UTC

syshum wrote: post #210

stirfrykitty wrote: post #199

Earlier quoted context omitted.

Most modern firewalls can decrypt/re-encrypt all traffic on the fly. The end user doesn't even notice. I've done this at my last two jobs. More here: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?...

That works by Man in the middle attacks of SSL and Only works on Enterprise Networks for devices owned by the enterprise because the Enterprise Installs their own Root Certs on all devices that "tricks" the browsers into believing they are "google.com" not the real google.com

Right, which is exactly how it should be. If you want to perform a purposeful man in the middle attack on your clients, then you SHOULD be required to install your root cert on their workstations. With unencrypted DNS, it just means that you can perform the same attack with NO specific approval by the client workstation. How is that better?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#214

Post by vetinari » Wed, Apr 10, 2019, 9:23 PM UTC

Spivak wrote: post #198

vetinari wrote: post #157

Earlier quoted context omitted.

On your router, you can configure whatever you want to use for the DNS. You were able to do that for years. But I want all the devices and apps to use whatever the local network tells them. I don't want to reconfigure the browser every time I connect at home/work/customer place/etc. P.S. My ISP's DNS doesn't lie. Maybe you should vote with your money and choose better.

"Network operators should be able to set DNS servers for client devices." "You can configure your router, a client device, to use whatever DNS server you want in defiance of your ISP, a network operator." Which one do you want?

If you configure your router, you are the network operator (of the network that the router handles).

Mozilla or other app vendors are not.

No dichotomy there.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#215

Post by [deleted] » Wed, Apr 10, 2019, 9:27 PM UTC

zrm wrote: post #100

shittyadmin wrote: post #89

Earlier quoted context omitted.

So your options are then: - Cry about it and hope they change the policy (they won't) - Accept using your cell data at school instead of their wifi (works, but is expensive) - Bypass it using a VM (requires moderate technical knowledge, networking skills and possibly the ability to bypass vm detection) - Reverse engineer it and crack it to behave the way you want (requires some pretty advanced technical skills) As su…

Or you can have the local interface and the cellular interface up at the same time, have the default route through the local interface but have a route to your preferred DNS server through cellular. Then the only traffic you have to pay for over cellular is DNS, which is very small.

[deleted]

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#216

Post by shawnz » Wed, Apr 10, 2019, 9:29 PM UTC

swiley wrote: post #203

shawnz wrote: post #151

Earlier quoted context omitted.

Then don't buy such a device which clearly doesn't meet your needs. Why should every personal computing device on the planet be tailored to your requirements, at the cost of safety for the majority of other users? Most people don't use PiHole, they use Adblock or uBlock which are not affected by this. It's not as though they are taking away your ability to use adblocking technology.

> Then don't buy such a device which clearly doesn't meet your needs. That would be nice in an ideal world, unfortunately most of us live in reality.

I don't know about you, but in the reality in which I live, privacy of the domain names I visit is a much bigger concern than being able to do access control with a technology that's not even made for access control.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#217

Post by close04 » Wed, Apr 10, 2019, 9:35 PM UTC

simondedalus wrote: post #211

close04 wrote: post #181

Earlier quoted context omitted.

> firefox messes up their DNS filtering, chrome doesn't I take it you assume students are not creative enough to get the exact same result with Chrome? Because it is perfectly possible to do it. Unless of course you take steps to prevent that in Chrome. One way or another you either put in the work or the users will end up doing whatever they please. After configuring the OS doing the same for the browser is a relati…

of course it's possible to do so. but DNS filtering works for most users, and is much easier to centrally manage on a budget (in terms of time / people / money) than browser settings. i'm belaboring this point now, but people who actually do this stuff know that you can't just throw up a GPO to fiddle with chrome settings and expect everything to work. this culture of "power users" thinking they know the best course…

> know that you can't just throw up a GPO to fiddle with chrome settings

I thought we were talking about how hard it is to fix Firefox. This can be done on a budget - part of an afternoon - since it can be very easily managed with a plain old config file copied to all machines (at least until a couple of versions ago). With this gone you're left with Chrome. How would you make sure no user can use any one of the multiple options to abuse a non-managed Chrome and bypass this? Remember that your target isn't to have a browser that doesn't mess up filtering, it's to prevent students from using any (creative) means to access restricted material. And with Chrome there's one sure way to prevent those creative means. So don't answer, it will be GPOs.

And since your fix for DOH and DNS filtering is to uninstall the browser (!) when Chrome eventually implements it will make for an interesting conversation ;).

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#218

Post by close04 » Wed, Apr 10, 2019, 9:45 PM UTC

simondedalus wrote: post #212

close04 wrote: post #180

Earlier quoted context omitted.

So tell me then, what exactly are you achieving with removing Firefox when the same bypass can easily be achieved with Chrome? Remove Chrome also? Call the well funded security team to configure whatever browser you’ll eventually have to use? The problem with half assed work is that you still put in some effort but reap none of the rewards. You work to uninstall Firefox from dozens of computers but get exactly 0 resu…

the DNS filtering works on chrome. yes, people can bypass it, but it doesn't even work on firefox, so they remove firefox. this isn't rocket science, and you're being foolishly contrarian instead of trying to understand what the original commenter's actual situation is. this leads me to believe that you are hypothesizing about work you don't do, but feel perfectly qualified to talk about "half assing" things.

> you're being foolishly contrarian instead of trying to understand what the original commenter's actual situation is

Perhaps because he's describing 2 different situations. One where "some schools" are removing Firefox, and one where it's not an option for him because of BYOD. Uninstalling Firefox is exactly the solution he can't apply. So I still maintain that the other schools that fully control the clients could have applied a proper fix faster and cheaper than any uninstall. It's one line in a config file [0], already linked above.

All your replies are gratuitously aggressive and insulting. That's not a good way to contradict my solution that works, is simpler and more future proof than uninstalling browsers with DOH.

Eventually all browsers will have DOH, you can't uninstall them all. And leaving a browser unmanaged and at the mercy of a student is not an option since requiring 2 extra clicks to bypass the filtering isn't a solution. You need some form of management either way.

I already gave you a solution that's better than removing the browser and "cheaper" than having to manage Chrome with GPOs (not a high bar). Insults won't change that.

[0] https://dxr.mozilla.org/mozilla-release/source/modules/libpr...

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#219

Post by bzbarsky » Wed, Apr 10, 2019, 9:59 PM UTC

protomyth wrote: post #173

xorcist wrote: post #171

Earlier quoted context omitted.

To be fair, can anyone really expect otherwise? If you insist on using a third party resolver for name resolution they will have knowledge of your queries no matter what the protocol. Doing it over tcp and http is not any better, or worse, than doing it over udp. This is something you have to opt in to.

> This is something you have to opt in to. Does it come turned off by default?

DNS-over-HTTPS in Firefox? Yes, it does, at the moment. See https://searchfox.org/mozilla-central/rev/dd7e27f4a805e4115d... -- 0 means it's off.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#220

Post by topranks » Wed, Apr 10, 2019, 10:08 PM UTC

foobarbazetc wrote: post #110

pretty_bubbles wrote: post #107

Earlier quoted context omitted.

Having a pihole still doesn't prevent applications from using another resolver - for example dig example.com @8.8.8.8 You'd also need to block all other DNS traffic. And even after that, it's tricky, as applications that are not a browser might be doing this with a hardcoded DoH provider.

There’s a way to redirect any port 53 traffic back to your pihole if you have enough control over the gateway, but I don’t know if it’s worth doing. Breaks a bunch of things you’d normally do to debug whatever.

Been doing this a few years, after seeing lots of apps and devices using 8.8.8.8 despite being given my resolver back via DHCP (so obviously hard-coded into them and they’re ignoring os dns.)

No practical drawbacks so far, although I have found many “open resolvers” online from my home, only to realize it’s the redirection messing things up.