News for hackers. Stuff that matters.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by foobarbazetc on Wednesday April 10, 2019 @12:27PM (#19626266)
Think of this more like which CA roots browsers include by default instead of a nefarious plan to stop you from doing whatever you want.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by EvanAnderson on Wednesday April 10, 2019 @01:18PM (#19626794)
It's not a nefarious plan to stop me from doing what I want in a FOSS browser on a PC where I can compile and run what I want. It will be used that way, however, on locked-down devices users pay for but don't actually own.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by shawnz on Wednesday April 10, 2019 @01:44PM (#19627050)
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.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by EvanAnderson on Wednesday April 10, 2019 @01:57PM (#19627177)
Macro-level view: The Mozilla Foundation may think that DNS-over-HTTPS is about "safety", but they're unwittingly furthering the agenda of those who would profit from the Internet not being decentralized. A decentralized Internet filled with devices that end users can control, should they choose, is a good thing for society, I'd argue. DNS-over-HTTPS is another piece of technology that can be used to eliminate that. It is not necessary to hand over freedom in exchange for "safety" or "security".

Micro-level view: I'm a sysadmin for my Customers, my family, and some of my friends. Inevitably I will have to deal with these awful devices. So will countless other sysadmins. I'm dreading having to deal with devices that invade my users' privacy, thwart my attempts at detecting bad actors on the network, and that just generally act like the person who paid for them doesn't actually own them.

Re:DNS-over-HTTPS Policy Requirements for Resolvers by techntoke on Wednesday April 10, 2019 @02:16PM (#19627352)
This is what Mozilla has been doing for a while. They enable advertisers and bad actors to profile you without any sane safeguards to prevent websites from running JavaScript code that is used in a nefarious way. If they were actually focused on protecting users, they would be working with IPFS and building other tools to help hide user identities through a permission-based system. Chrome is just as guilty, but it's not like Mozilla is trying to define new web standards to prevent this type of activity. They may as well be working together.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by apostacy on Wednesday April 10, 2019 @08:38PM (#19630061)
Don't know why you are getting downvoted when you are completely correct.

There's so much that Mozilla could do structurally, but they are terrified of rocking the boat or disrupting their corporate underwriters.

Just like earlier today, with their anti malicious javascript features[1]; they could look into empowering the users and changing the structure of how js is run in the browser. But that might threaten advertisers, so instead they opted for a clumsly blacklisting solution instead.

If you want an accurate heuristic for predicting Mozilla's behavior, just ask "What would Google want?". It may not be Google in particular that these decisions benefit, but they absolutely benefit those entities that are locking down and siloing the internet.

[1]: https://news.ycombinator.com/item?id=19614808

Re:DNS-over-HTTPS Policy Requirements for Resolvers by shawnz on Wednesday April 10, 2019 @02:16PM (#19627347)
Regarding your second point, this change will improve privacy for your clients and make it harder for bad actors to take advantage of your network. So what's not to like? Just because your old tooling won't work anymore doesn't mean that this change is a bad thing for clients.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by vetinari on Wednesday April 10, 2019 @03:00PM (#19627727)
If it improves privacy for the clients, it also improves privacy for the malware, and you won't be able to monitor or be alerted of it.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by stirfrykitty on Wednesday April 10, 2019 @04:15PM (#19628365)
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?...

Re:DNS-over-HTTPS Policy Requirements for Resolvers by syshum on Wednesday April 10, 2019 @04:49PM (#19628640)
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

Re:DNS-over-HTTPS Policy Requirements for Resolvers by shawnz on Wednesday April 10, 2019 @05:13PM (#19628830)
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 by snazz on Wednesday April 10, 2019 @08:16PM (#19629937)
You get an HTTPS error if someone performs a DNS MITM and you’re not set up specifically to trust their certificate. It’s equivalent to performing an HTTPS MITM without the root cert installed.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by vetinari on Thursday April 11, 2019 @05:26AM (#19632377)
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 by Murrawhip on Wednesday April 10, 2019 @04:33PM (#19628512)
What? The end user does notice if you haven't added the CA to the end user's PC.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by JohnFen on Wednesday April 10, 2019 @04:22PM (#19628420)
> make it harder for bad actors to take advantage of your network.

How so? It looks to me like it makes it easier for bad actors to take advantage of my network, by making it harder to detect and block DNS lookups.

Re:DNS-over-HTTPS Policy Requirements for Resolvers by glennpratt on Wednesday April 10, 2019 @07:02PM (#19629545)
You are focused on unsophisticated bad actors if DNS is all it takes to block.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by JohnFen on Wednesday April 10, 2019 @07:09PM (#19629586)
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.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by glennpratt on Wednesday April 10, 2019 @07:17PM (#19629629)
You want a warm blanket that you blocked some well known ad click tracker while having no real visibility overall. Security theater.
Re:DNS-over-HTTPS Policy Requirements for Resolvers by JohnFen on Thursday April 11, 2019 @09:39AM (#19634349)
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 by shawnz on Thursday April 11, 2019 @10:10AM (#19634683)
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?
Re:DNS-over-HTTPS Policy Requirements for Resolvers by JohnFen on Thursday April 11, 2019 @11:13AM (#19635316)
Because I believe in multilayered security. No one approach to security is sufficient, but combining as many approaches as possible can allow each approach to help cover the weaknesses of the other approaches.

Also, I disagree that denying the lookup of certain domain names is abusing DNS. If I were running a DNS server that was being used by the public, or that was being used by downstream DNS servers, that would be different.

Also, I'm not aware of a method that can accomplish the sort of coverage that blocking DNS lookups can. If you have an alternative, I'd be genuinely interested in hearing about it.

Re:DNS-over-HTTPS Policy Requirements for Resolvers by shawnz on Thursday April 11, 2019 @06:20PM (#19639860)
> I believe in multilayered security. No one approach to security is sufficient, but combining as many approaches as possible can allow each approach to help cover the weaknesses of the other approaches.

Agreed with you there, I'm not saying that multilayered security is a bad thing.

What I'm saying is that right now, in terms of easy and accessible DNS privacy, we have 0 layers. Don't you think it might be worth sacrificing this one partial, incomplete access control solution in favour of solving that?

Re:DNS-over-HTTPS Policy Requirements for Resolvers by glennpratt on Thursday April 11, 2019 @02:20PM (#19637556)
> If I were running a DNS server that was being used by the public, or that was being used by downstream DNS servers, that would be different.

Without cooperation of the device, that is indistinguishable from that of a bad actor.

You can get what you want by owning the device and requiring it to cooperate (ie with controlled software or a certificate to allow monitoring / blocking).

Re:DNS-over-HTTPS Policy Requirements for Resolvers by apostacy on Wednesday April 10, 2019 @08:31PM (#19630021)
Then Mozilla should make a crippled "safe" version of their browser that has a hard coded list of trusted servers then.

Because by making this the default, they are helping centralize the internet and greatly benefiting the entrenched powers while putting barriers to entry for the rest of us.

Re:DNS-over-HTTPS Policy Requirements for Resolvers by swiley on Wednesday April 10, 2019 @04:25PM (#19628443)
> 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.

Re:DNS-over-HTTPS Policy Requirements for Resolvers by shawnz on Wednesday April 10, 2019 @05:29PM (#19628979)
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 by mike-cardwell on Thursday April 11, 2019 @04:36AM (#19632133)
It's not really equivalent. Our DNS servers know every single website we visit, and when we visit them.

There's no way we should take that information and centralise it into the hands of a few big providers. No matter how many pinky promises they make to not look at it.