Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNS-over-HTTPS Policy Requirements for Resolvers

blog.mozilla.org

Post reply on HN
Print view View original

271–280 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#271

Post by vetinari »

selenamarie wrote: post #235
vetinari wrote: post #160

Earlier quoted context omitted.

> usually around Active Directory implementations where brain-damaged people have named the AD domain the same as a public Internet domain name I don't like this one either, but often it is inherited from the past from other people and it is not going to change. On the other hand, split-horizon DNS is going to stay with us, even if the AD domain is a subdomain of the public one. Records in the internal zone are not g…

A subdomain that doesn't resolve is handled properly -- meaning DoH is then disabled.

Didn't know that, great, thanks.

On the other of the common problems: I assume there is no way to blackhole existing, public records, other than extension ala uBlock/Adblock?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#272

Post by vetinari »

Spivak wrote: post #239
vetinari wrote: post #214

Earlier quoted context omitted.

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.

The point is that your router is a client of your ISPs network and you're overriding the servers provided by DHCP to your router. In a crazy world where internally Firefox ran a small IP network for each tab and routed traffic between them for IPC would it suddenly be okay for Firefox to override DNS? Why or why not?

The difference is not in what is being done, but in who is in charge.

If you modify your router settings, it's you. You decided that you are not going to honor ISP suggested defaults, and it is up to you to assess costs/benefits and pick the right choice.

If Firefox overrides your settings, it means someone else does the decision about your tools. If that someone else makes it difficult to automate changing the default (e.g. ignoring DHCP; if you want, you can ignore DHCP at the system level, but this is not a decision an app should take), it means, that this someone else doesn't have good intentions towards you. Someone else decided what's "best" for you.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#273

Post by vetinari »

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

Yes, it works, by software or devices that cooperate.

With desktop OSes, it is no problem.

With mobiles, traditionally, if you enrolled a custom CA root onto Android device, the user would be nagged ("You network may be monitored").

Malware can go further, and just use it's own root, without any ability to enroll your custom one. I see this as a default with any IoT or embedded devices, so that will make much more difficult to say "no custom CA, no internet access".

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#274

Post by yardstick »

zaarn wrote: post #264
nykolasz wrote: post #27

I replied sub-thread, but adding here to give some more visibility to some of the issues DoH is causing and will cause: I work at a k12 school and I am involved on many k12 IT communities. Some schools already removed Firefox from the students computers because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS. There is a fine line betwee…

It's entirely within the intentions of browser vendors to make blocking of content without consent of a user hard or even impossible. If the school cannot be bothered to block content properly (ie, only via DNS block) then that is their own fault. The tools exist to block on an IP level. For all computers the school owns, they SHOULD definitely do HTTPS MitM.

IP level is too coarse grained to block sites hosted on Cloudflare etc which host sites you also wish to allow access to.

SNI filtering is a reasonable middle ground - it has its flaws but nowhere near invasive as full MITM filtering yet achieves most of the filtering objectives of the organisation. Ie it is “good enough”. Sadly ESNI may be the end of usefulness of this approach.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#275

Post by JohnFen »

comex wrote: post #255
JohnFen wrote: post #206

Earlier quoted context omitted.

> Personally I'm not an "owner" of the networks I'm connecting to. But I am the owner of my own network, and DoH reduces my ability to protect it. That is the main (but not only) reason why I strongly object to DoH. > I think this train has passed. I suspect the battle has just begun. For example, my response to DoH has been to implement a MITM packet inspection system on my network to regain control over this. This…

What exactly are the threats that you expect blocking DoH to protect you from? If you are MitMing all encrypted traffic anyway, why not block whatever you want to block when someone actually tries to connect to it, rather than trying to prevent them from learning where it is?

> What exactly are the threats that you expect blocking DoH to protect you from?

I want to maintain the ability to block the resolution of certain domain names.

The threat model is malicious software or websites that want to phone home. This includes reaching out to command-and-control servers, ad tracking servers, data exfiltration points, etc.

> If you are MitMing all encrypted traffic anyway, why not block whatever you want to block when someone actually tries to connect to it

Because most of the malicious actors don't use raw IP addresses as they can change frequently and without notice. They resolve a domain name instead. Blocking the domain name lookup is therefor more effective and less likely to result in blocking the wrong things than working with raw IP addresses.

This is not a replacement for other security measures (including IP-based blocks), but is is, in my opinion, a critical measure in and of itself.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#276

Post by JohnFen »

glennpratt wrote: post #234
JohnFen wrote: post #231

Earlier quoted context omitted.

I don't understand your point. I'm certainly not solely focused on the unsophisticated ones, but those sorts are important too. And they're much more common as they include ad and other trackers.

You want a warm blanket that you blocked some well known ad click tracker while having no real visibility overall. Security theater.

You would be correct if that were my attitude, but it's not. This is not a panacea, it's one component in a larger security posture.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#277

Post by Spivak »

vetinari wrote: post #272
Spivak wrote: post #239

Earlier quoted context omitted.

The point is that your router is a client of your ISPs network and you're overriding the servers provided by DHCP to your router. In a crazy world where internally Firefox ran a small IP network for each tab and routed traffic between them for IPC would it suddenly be okay for Firefox to override DNS? Why or why not?

The difference is not in what is being done, but in who is in charge. If you modify your router settings, it's you. You decided that you are not going to honor ISP suggested defaults, and it is up to you to assess costs/benefits and pick the right choice. If Firefox overrides your settings, it means someone else does the decision about your tools. If that someone else makes it difficult to automate changing the defau…

But right now within epsilon every computer will just blindly take what is given to it by DHCP making the local network operator, who is for almost everyone an untrusted party, the person who decides what's best for you.

I agree that DNS should be a system level concern rather than an app-level concern but in the real world browsers want to protect their users' privacy and the OS they run on doesn't do that. If every app went out and started using app-level DNS then it might get annoying but browsers are particularly privacy and security sensitive.

With this change almost everyone (i.e. people who don't mess with their OS setting and don't know or care what DNS is) are markedly better off.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#278

Post by Spivak »

the8472 wrote: post #200
Spivak wrote: post #194

Earlier quoted context omitted.

> install a DNS stub resolver that tunnels to some external resolver that you trust. Because the we're dealing with computers as they actually exist and are configured. And within epsilon every personal computer on the planet is configured to trust DHCP and set their DNS servers to whatever is offered. So we're in a situation where these particular applications also don't really trust the OS to a certain extent.

You have that backwards. It's applications that are less than trustworthy. That's why we try to sandbox them. As for the DHCP part, if you're on a public network you should only trust it as far as you need it to bootstrap your tunnel over which you can then finally contact a trusted resolver. OS resolver -> a single thing you need to secure every app uses its own resolver -> complete mess which makes it harder to ens…

Browsers don't trust the OS to provide secure private name resolution. And they really shouldn't when every OS just blindly takes whatever is offered via DHCP.

I absolutely agree that DNS should be a system-level concern rather than app-level. But today, right now, for computers as they are and will continue to be for the foreseeable future this is a huge improvement. Browsers being the app that handles basically all of our sensitive information I think have earned the exception.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#279

Post by Spivak »

AlexandrB wrote: post #184
Avamander wrote: post #109

Earlier quoted context omitted.

Don't worry. Soon Chrome will also implement DoH and ESNI, then you actually have to either forbid BYOD or actually start teaching students manners, how browsing porn is not okay in school context. I'm really quite annoyed by the connotation that kids should rather be helicopter-parented (by tech or by people) than actually taught what's okay and what's not. The very least the new tech provides is that any silent hel…

> Soon Chrome will also implement DoH and ESNI, then you actually have to either forbid BYOD or actually start teaching students manners... If you think that this is how it will go, you're very naive. If schools and parents can't block porn anymore, prepare for more legislation that blocks porn by default at the ISP unless you pay some kind of fee - like what the UK has proposed. Also look for a return of "content st…

> prepare for more legislation that blocks porn by default at the ISP

See you're missing something. If you as the local network operator can't block porn than neither can any intermediate ISP. It's not like they have any more power than you do.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#280

Post by shawnz »

JohnFen wrote: post #276
glennpratt wrote: post #234

Earlier quoted context omitted.

You want a warm blanket that you blocked some well known ad click tracker while having no real visibility overall. Security theater.

You would be correct if that were my attitude, but it's not. This is not a panacea, it's one component in a larger security posture.

If DNS-based access control is not sufficient on it's own, then is it really worth it to block DoH (which could have other significant security and privacy benefits) just to retain the possibility of using it? Why not focus on improving those other, already necessary access control technologies and forget about abusing DNS for this purpose, so we get the best of both worlds?
Post reply on HN