News for hackers. Stuff that matters.
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).