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

41–50 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#41

Post by judge2020 »

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…

I don't think there is a good solution. Yes, you own the network and think you should be technologically able to block access to certain websites (which the school has the right to do), but ISPs also "own" the network and would also be able to block access to certain websites if it were possible with DoH+eSNI.

I guess a solution is MDM, but that's still getting students to install something on their device.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#42

Post by raxxorrax »

pas wrote: post #15
cremp wrote: post #12

Earlier quoted context omitted.

Because they should! Think a corporate network. If I as a sysadmin set our DHCP options to give out our own resolvers, I expect that every machine on the domain to use ours. DoH breaks that completely; and hence the network operator should have the final say. As a sysadmin myself, if browsers are overriding the basic model of top down, and it hurts me, because when something is wrong, I cant just look on my machine,…

A corp network should set up their own DoH resolver anyway. And/or simply install a cert on their workstations and MITM every TLS connection. Even better corps should only allow TLS that they can successfully MITM. It's basic security. If the endpoint/host can do whatever due to lack of firewall/enforcement, then it doesn't really matter what the network operator wants.

I am no sysadmin but working closely with some. I have never seen any case where HTTPS-MITM helps. Yes, theoretically it does allow us to scan for malicious content in a secured connection. Brilliant, but that are not the attack vectors they are concerned about.

So what is left is that breaking up TLS just infringes on privacy and allows for tighter control. The security aspect is laughable.

Users are angry that their internet got slower, an it creates an enormous administrative cost, because you need countless exceptions to the rules.

Most developers break out of it in a few days...

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#43

Post by rndgermandude »

nykolasz wrote: post #35
threatofrain wrote: post #28

Earlier quoted context omitted.

Ultimately we cannot secure content without being able to look at it (encryption is the problem). We need to be able to look at what the kids are looking at if we want to control what information gets to them. DNS is a band-aid solution with side effects.

Band-aid solution that worked pretty well. Very cheap to implement, widely supported and used by many schools. Our student's data was still private (no emails or passwords being decrypted) and we did the filtering only based on the domain name. It also didn't require an expensive appliance that would be need if did the filtering based on SNI.

A student who really wants to see "the bad" on the internet isn't scared off by blocking some DNS/VPN/proxy traffic. This is wishful thinking.

The easiest work-around for students who want to show their mates some "cool porn" is to just save it at home. Or connect to the free wifi of in reach.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#44

Post by danarmak »

nykolasz wrote: post #39
danarmak wrote: post #31

Earlier quoted context omitted.

> Unfortunately, on our school network, we also allow BYOD (students with their own laptops and ipads), so we will have to have some strict rules to block DoH, the same way we block proxies and vpns. How can you block DoH without doing MITM on all outgoing HTTPS? For that matter, how can you block HTTPS based VPNs like OpenVPN? ETA: I understand you can block IP addresses of DNS resolvers that support DoH. I assumed…

IP-based and domain-based. We have a long list of domains/IPs used by VPN providers. Won't prevent someone from setting up its own SSH-based proxy on port 443, but covers things that are accessible and easy to use by young students (talking about elementary school on our case). Again, we are talking about a school network with young kids (under 12/13).

If DoH is backed by e.g. Google, won't they just end up exposing DoH on the same IP addresses serving www.google.com? Similarly, what if e.g. CloudFlare expose their DoH on all their addresses? This seems like the obvious next step for them.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#45

Post by AnaniasAnanas »

pas wrote: post #18
AnaniasAnanas wrote: post #8

Still no explanation on why dns-over-https rather than the already widespread dnscrypt or the lesser known dnscurve, dns-over-quic, and dns-over-tor.

DNScrypt is easy to block, therefore it can't further the privacy-for-all cause.

This is certainly a valid argument, though two of the other solutions (plus dns over tls) avoid this issue as well.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#46

Post by subwindow »

This has negative implications for security. For instance, one reason why DNS resolvers might block or modify requests is to blacklist domains used for malware operation (botnet C&C domains). Other things like DNS sinkholing and poisoning are also frequently used as tools to disrupt malware communication.

In addition, collection and analysis of below-the-recursive DNS traffic is one of the primary ways in which security researchers discover the infrastructure of botnet networks.

Overall DoH is probably a net positive, but I don't see downsides like this being discussed.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#47

Post by captncraig »

dooglius wrote: post #37
nykolasz wrote: post #36

Earlier quoted context omitted.

Quite the opposite. We don't want MITM and this may force that direction.

Poor choice of term maybe... you want to get information about communication between endpoints without their consent.

Well its a school. They (or their legal guardians) consent as a condition of using the network.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#48

Post by stupidthrottle »

flarex wrote: post #4
EvanAnderson wrote: post #2

I hadn't been paying much attention to DNS-over-HTTPS, but I recently listened to a talk that Dr. Paul Vixie (of BIND fame) gave that where DNS-over-HTTPS was discussed: https://youtu.be/OxFFTxJv1L4?t=2799 After hearing Dr. Vixie discuss DNS-over-HTTPS from a network operator perspective I'm a lot more wary of the protocol.

His main argument seems to be that the network operator should have control over DNS requests for safety reasons. Control and monitoring. This is the antithesis of privacy and encryption. I wouldn't be surprised if he was pro http over https either.

> His main argument seems to be that the network operator should have control over DNS requests

And why is that an unreasonable position for a network operator to hold?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#49

Post by stirfrykitty »

threatofrain wrote: post #28
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…

Ultimately we cannot secure content without being able to look at it (encryption is the problem). We need to be able to look at what the kids are looking at if we want to control what information gets to them. DNS is a band-aid solution with side effects.

Palo Alto firewalls do decryption on the fly should you want to look at this. It can all be logged with short or long logging.

Worked in your arena for 5 years. Kids are creative and crafty. We had kids getting around the MDM/DNS blocks by changing the DNS/Proxy settings in their iPads. This is not easily overcome with existing MDM solutions AND letting the iPad be usable. BYoD is a whole different animal since you cannot legally "touch" their devices, you have to implement the federally-mandated blocks at the infrastructure level. Kids can use VPNs all day and there is nothing that can be done in reality.

At a previous job, believe it or not, I worked with a client with almost a zero budget who was having massive issues with malware/ads in their public space that offered free computer use. Being the budget was minimal (less and $100 to fix), I deployed two Pi-holes and taught the "admin" how to manage it. Cheap, effective, works. I set the whole thing up to fail back to the network's DNS should the Pi-holes fail. Still running almost two years later.

The Pi-hole can block about any content you would like it to block with almost zero-configuration. Easy to block a single domain or with a new rule set subscription.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#50

Post by judge2020 »

nykolasz wrote: post #39
danarmak wrote: post #31

Earlier quoted context omitted.

> Unfortunately, on our school network, we also allow BYOD (students with their own laptops and ipads), so we will have to have some strict rules to block DoH, the same way we block proxies and vpns. How can you block DoH without doing MITM on all outgoing HTTPS? For that matter, how can you block HTTPS based VPNs like OpenVPN? ETA: I understand you can block IP addresses of DNS resolvers that support DoH. I assumed…

IP-based and domain-based. We have a long list of domains/IPs used by VPN providers. Won't prevent someone from setting up its own SSH-based proxy on port 443, but covers things that are accessible and easy to use by young students (talking about elementary school on our case). Again, we are talking about a school network with young kids (under 12/13).

This would probably require new equipment (or just an update) but at that point, you could use an SNI whitelist, then drop port 443 traffic that isn't TLS. You could even drop the request when SNI is not present, in the case of encrypted SNI (if the network box has this feature).
Post reply on HN