NSA Warns Against Using DoH Inside Enterprise Networks (zdnet.com) 61
The US National Security Agency has published this week a guide on the benefits and risks of encrypted DNS protocols, such as DNS-over-HTTPS (DoH), which have become widely used over the past two years. From a report: The US cybersecurity agency warns that while technologies like DoH can encrypt and hide user DNS queries from network observers, they also have downsides when used inside corporate networks. "DoH is not a panacea," the NSA said in a security advisory [PDF] published today, claiming that the use of the protocol gives companies a false sense of security, echoing many of the arguments presented in a ZDNet feature on DoH in October 2019. The NSA said that DoH does not fully prevent threat actors from seeing a user's traffic and that when deployed inside networks, it can be used to bypass many security tools that rely on sniffing classic (plaintext) DNS traffic to detect threats. Furthermore, the NSA argues that many of today's DoH-capable DNS resolver servers are also externally hosted, outside of the company's control and ability to audit.
If the NSA tells me not to use DoH (Score:4, Insightful)
Re: (Score:3)
So you'll just hand everything to Google and Google will hand it all to the NSA, thereby legalizing their illegal spying.
Re: (Score:2)
It's 2021. The concept of a "trusted" network - even/especially an internal network - should be long-dead.
There are nothing but red zones, anywhere.
Re: (Score:2)
As long as you have a good source of randomness, a one-time pad is uncrackable (not actually proven, but no expert seriously believes it could be) and it's easy to home brew. Ultimately, the advice of the NSA on computer safety does have to be taken with a very big grain of salt. While part of their core mission is protecting the electronic security of Americans, their adherence to that particular part of their mission is dubious at best.
Re: (Score:2)
Re: (Score:2)
That pretty much seems to be the way of it.
Re:If the NSA tells me not to use DoH (Score:5, Insightful)
On a home based system, sure. But on a corporate network where traffic sniffers are in place to prevent malware from entering the network, or at least try to mitigate some kinds of attacks, having an encrypted tunnel from a workstation to points unknown could be a gaping hole that no packet inspection could penetrate. At that point, you'd have to your packet analyzers and edge routers basically kill such connections. What other choice does a manager of corporate network have? The whole point is to plug gaping holes, not permit them for some employee's notion of "freedom".
I have no issue with an employee using DoH on their own computer on their own network. But yeah, on my business infrastructure, fuck that.
Re: (Score:3)
You set up such a server and make it mandatory for employees to use. That's a net gain over packet analyzers.
Re: (Score:3)
having an encrypted tunnel from a workstation to points unknown could be a gaping hole that no packet inspection could penetrate. At that point, you'd have to your packet analyzers and edge routers basically kill such connections. What other choice does a manager of corporate network have?
Wouldn't that cripple your ability to access to customers' systems via SSH? Or shell into your AWS servers? And once you can shell somewhere, it takes only like 2 seconds to setup a SOCKS proxy over that connection.
Re: If the NSA tells me not to use DoH (Score:1)
Billy Bob in Accounting doesnâ(TM)t need to SSH into AWS to count beans. SSH should be blocked outbound so he canâ(TM)t circumvent the firewall policy with a SOCKS proxy. Also, modern NGFWâ(TM)s would identify and block SSH on non-standard ports as well.
Re: If the NSA tells me not to use DoH (Score:5, Insightful)
It is irrelevant. Malicious software will soon switch to DoH if it hasn't already, and it won't matter whether you are using it in your browser or in your whole system. The malware will do it regardless.
Re: (Score:2)
Re: (Score:1)
Re: (Score:3)
I don't give TWO SHITS about what some anonymous company does that I have no affiliation with. I care about **MY** security, first.
Re: (Score:3)
Re: (Score:2)
You personally most absolutely *should* have the final say on the level of security deployed on your own networks and computers.
DoH may or may not take some of that choice away.
You mean, the world is not black and white, and one actually needs to think about what is appropriate?! *head explodes* /s
Re: (Score:2)
I don't understand this defense of corporations, or the idea that somehow a "home user" deserves less security than some company.
Eh?
Well, you're clearly angry about something or other.
You are free to run all the network security tools you want at home or contract a network security professional. Unless you have the chops for the former or the money for the latter (and the chances are you in the general sense) don't then you're imply not going to be doing the same kinds of things on your network as large com
Re: (Score:2)
The problem isn't DoH, it is that the implementations of DoH ignore the DNS settings provided by the network administrator. If they used the corporate DoH server then it would be fine.
Re: (Score:2)
If your security strategy is foiled simply by running DNS over DoH instead of the corporate DNS server you really need to fire the entire IT department.
Re: (Score:3)
You don't just do the opposite of whatever the NSA says, that would actually leave you much worse off than if you did exactly what they recommend. What you need to do is:
1. Check for any discrepancy between their recommendations for civilians and the military. Wherever they differ, use the military standards, because the NSA is able to compromise the civilian ones and is betting that their adversaries are too dumb to be able to do the same.
2. Carefully scrutinize any civilian recommendations where you canno
Re: (Score:2)
Re: (Score:1)
Re:If the NSA tells me not to use DoH (Score:5, Insightful)
Then you don't understand what is going on. All of these new technologies are brought in under the guise of protecting the user, when in reality they are weaponized against the user. DoH should not even exist... at least not in the way it is implemented. Applications should not be doing their own DNS resolution. You have control over where your OS does it name resolution. You do not always have that control over apps. Block ads at DNS? Not if your app has anything to do with it. Certificate pinning is another example of nice technology that is weaponized. There should be no instance EVER where communication coming off of a device someone owns should be hidden from that owner. You can do away with certificate pinning and it is still private from end to end, but when the user has control over certificates he view his own encrypted traffic. Application developers should not have the right to hide communication from the owners of devices.
Re: (Score:2)
Blocking third party DNS is impossible. Because I could just setup a webservice at https://bobsapp.com/ [bobsapp.com]\?domainname=" and return a payload with an ip address. Bingo bongo DNS defeated and I didn't use "DNS" except to resolve BobsApp.com which shouldn't be suspicious if I'm actually using Bob's App on my device... of course it would phone home. Google could setup "https://Google.com/?Domainame=" and what are you going to do block google.com?
Re: (Score:2)
DoH should not even exist... at least not in the way it is implemented. Applications should not be doing their own DNS resolution.
Sorry but the first point is silly and the second utterly irrelevant.
DoH exists in its current form precisely because DNS classically is easily manipulated and used against the user.
The applications are a complete red herring. The only reason a handful of apps have implemented DoH is because it doesn't exist on the OS level and to prove the concept. Linux already offers DoH on the OS, and Windows has already demonstrated it in an insider build. If you're worried about apps bypassing the OS, they have *alway
Re: (Score:2)
The NAS also recommends ssh so will you be switching to telnet then?
No Kidding (Score:3)
OpenBSD said a while ago it was not a good thing and disables by default. I make sure it is disabled on all my systems and have for a while. What I did:
about:config
network.trr.mode
Last I check, OpenBSD sets it to '0' automatically and on Linux I set it to 5 manually
Re: (Score:3)
More info about the values and what they really do, as per https://wiki.mozilla.org/Trust... [mozilla.org] :
0 is off by default
2 is use DoH first
3 use DoH only
5 is off by user choice
Other values are either obsolete or reserved.
Also notice that you can change the servers used by the DoH if you want, via the network.trr.uri setting:
https://github.com/curl/curl/w... [github.com]
You can even use your own DoH service if you want, but unless it is remote and shared, you will have little benefits
Re: (Score:2)
OpenBSD said a while ago it was not a good thing
For whom? I get OpenBSD isn't really targeted at mum and dad at home being snooped on by their ISP and having their data sold off to anyone with a credit card.
If you have your own DNS resolver... (Score:2)
If you are hosting your own DNS resolver, it makes sense to disable DNS-over-HTTPS.
So, you built your own FreeBSD router, installed BIND, set up DHCP to use your local resolver, and disabled port 53 to internal access. Hoping to track what is being accessed inside your network, you would instead get those HTTPS based resolver statistics.
Even if you want to use simple public filters like OpenDNS, you would still need to avoid DNS-over-HTTPS.
And, this being an application setting, and specifically designed to
the boy who cried wolf (Score:2)
those familiar with the parable will understand that the boy earned a reputation of being deceitful but finds out later when he is actually telling the truth, nobody believes him
somehow this basic truth escapes all those super-smart NSA folks who -- like most people -- assume that excelling in one subject makes one competent in another
unsolicited advice: get out of your bubble, realize you're no better than anyone else, and most importantly, earn a reputation of being truthful even if it's to your own detri
DoH is a protocol (Score:2)
DoH is a protocol, not an endpoint. It's a bit of a useless recommendation as written. Implement DoH internally if you want something you can trust - it's not like people weren't using external DNS over port 53 before DoH.
Re: (Score:2)
It's a bit of a useless recommendation as written.
Written by the NSA. It'll probably end up as a STIG [wikipedia.org] and have to be checked/implemented on government, military and possibly contractor networks...
Re: (Score:2)
That's pretty much what the advisory says, Adopting Encrypted DNS in Enterprise Environments [defense.gov].
Enterprises need to either implement their own internal DoH resolvers or disable DoH and (continue to) use their own internal DNS resolvers. Essentially, do it yourself if you need to trust, monitor, control, etc.
A lot of companies run their own DNS servers (Score:2)
and it would seem to be easy enough with local proxy servers to disable DoH via something like proxy.pac commands...
In an environment where access to external services like UDP and ICMP are disabled, it doesn't make any sense to allow things like DoH
when your local services already cache DNS and HTTP pages.
On the contrary, (Score:2)
"Doh!" is applicable everywhere.
Never thought I'd say this, but (Score:2, Interesting)
Thank You NSA!
I feel like I'm alone in the wilderness, fighting against a Privacy Cabal that's trying to subvert Internet Standards to the sole benefit of a few mega-corporations.
First there was DNS over HTTPS: give all your DNS to Google and CloudFlare!
Then there was TLS 1.3: Let's hide everything about your connection, so your company *has to inspect all your traffic*. Then all your traffic can be both insecure *and* broken, because of 1) a single point of security failure, and 2) hundreds of apps that do
Re: (Score:3)
First there was DNS over HTTPS: give all your DNS to Google and CloudFlare!
No, first there was DNS: give all your DNS to Theresa May (if you live in the UK). You're claiming that somehow all my DNS going through a remote organisation (cloudflare) that ha no idea who I am and who doesn't appear to be in the business of user data is somehow worst than government mandated snooping and recording of all my DNS traffic.
Also FFS it's a choice. No one is forcing DoH on me. I use it because it seems like a reasonabl
Re: (Score:2)
First there was DNS over HTTPS: give all your DNS to Google and CloudFlare!
Not a requirement of DoH.
so your company *has to inspect all your traffic*.
No, your company does not have to inspect any of your traffic. If they don't like what they can see in TLS 1.3, chances are TLS 1.2 isn't much better.
Every time somebody goes "but privacy!!!" we lose on actual security and functionality.
No, TLS 1.3 and DoH are genuinely security improvements for the overwhelming majority.
TLS IS NOT SECURE FROM NATION-STATES AND HACKERS ANYWAY!
Actually, it seems fairly secure to me.
A regular-old hacker can hack TLS a handful of ways, it's really not that hard
Can't respond as no evidence is presented...
And all a nation-state has to do is force a CA to give them their keys and issue a gag order on national security concerns (or steal the key, etc).
This is what CAA over DNS is designed to deal with - of course, you need secure DNS for this to work. Not to mention the Certificate Transparency framework which is s
What does Homer Simpson say? (Score:2)
DoH!
DoH (Score:2)
The don't call it "Doh!" for nothing.
This translates as (Score:2)
Re: (Score:2)
entirely possible to setup DNS inside a network in such a way that the NSA cannot easily spy on your DNS traffic. The steps to do secure your DNS traffic are:
1) Create a an internal recursive server locally
2) block all DNS traffic on your firewall (UDP/TCP port 53 and 853)
3) block known common DoH servers (quad1, quad8, quad9, etc.)
4) "capture" those well known DNS IPs & route them to your internal server
5) block other known public DoH server IPs on firewall
6) if "next gen" firewall that does DoH detec
Re: (Score:2)
Now you have a local resolver that gets your DNS queries answered ultimately via an encrypted public server, giving you a "privacy mixer" effect because the queries cannot easily be tied back to you. First query per rDNS ecord is slower, but cached afterwards & and faster because it is local to your network
It is some work to setup, but it isn't rocket science by any means.
Re: (Score:1)
Some good discussions online (Score:2)
Some good discussion of this topic online...
OpenBSD disables DoH in Firefox by default [daemonforums.org]
and an interesting talk from the Netherlands Network Operators Group [youtube.com].
the point of DoH (Score:2)
Re: (Score:2)
I'm sort of missing the point of DoH, if my PC get the IP address of a server in a secret way, but t next thing that it does is send a page request to the IP address, then any observer (my ISP for example) can see that. If I'm using a VPN, shouldn't all traffic including my DNS requests already be hidden inside the VPN tunnel..?
Reversing that IP isn't trivial, viable for large self hosted websites but often it just tells you that it is AWS hosted, or distributed through cloudfare.
Of course this https stuff is easily avoided if you can just monitor DNS queries.
So for privacy reasons we move away from straight DNS.
Privacy is awkward for security people who were snooping DNS queries, so they don't like it.
There were similar arguments when HTTPS was first introduced, companies would force users to install their own certificate and the
Re: the point of DoH (Score:2)
Consumers First...Enterprise Second (Score:1)
DoH is a MITM backdoor! (Score:2)
That is its only point.
To funnel all your DNS traffic through Google or Mozilla. Instead of yournown damn DNS server.
Yes, private people can run DNS servers too.
Actually it is really weird that Linux and Windows don't come with that built-in already, in today's times.
(Setting up a tiny VM with bind, from a ready-made image, takes five to 30 minutes! Do not forget not NOT use forwarding, nor let DHCP set your DNS resolver.)
Not surprising (Score:2)
Sniffing plaintext traffic to detect threats (Score:1)
I would be more worried about getting your deep packet inspection [ccexpert.us] system compromised.