SoylentNews is people
SoylentNews
from the can't-see-where-you're-going dept.
Submitted via IRC for chromas
Dutch Govt Explains the Risks Behind DNS-Over-HTTPS Move
The Dutch National Cyber Security Centre (NCSC) explains how DNS-monitoring will get more difficult as modern encrypted DNS transport protocols are getting more popular in a fact sheet published this week.
The fact sheet's audience is represented by system or network admins and security officers who want to move to DNS over TLS (DoT) and DNS over HTTPS (DoH) DNS encryptions protocols that offer increased security and confidentiality.
Both DoH and DoT are designed to allow DNS resolution over encrypted HTTPS connections instead of using the currently common plain text DNS lookups.
Google and Mozilla are both running DoH trials for their browsers, with Chrome to upgrade to a provider's DoH server if it present on a pre-defined whitelist or to a shortlist of fallback providers (i.e., Cleanbrowsing, Cloudflare, DNS.SB, Google, OpenDNS, Quad9) if not.
By only upgrading the DNS resolution to DoH if the users' current DNS provider is supported, Google believes that the users' DNS resolution experience will stay the same.
Mozilla's DoH experiments have already been met with criticism from network admins and Linux distro maintainers after the decision to enable DoH by default and using Cloudflare's DoH server rather than a user's existing DNS provider.
Senior scalability engineer Kristian Köhntopp said that Mozilla is "about to break DNS" seeing that Cloudflare will be used for DNS resolution over the default server assigned by system administrators, leading to leaking visited website addresses inside corporate environments to Cloudflare.
Peter Hessler, an OpenBSD developer, tweeted at the time that OpenBSD disabled DoH in their Firefox package in the current releases and will also disabled it in future ones since "sending all DNS traffic to Cloudflare by default is not a good idea."
(Score: 3, Insightful) by Anonymous Coward on Saturday October 05 2019, @11:00PM (7 children)
DNS over HTTPS might be great, but browsers are supposed to ask the OS to do that. The OS needs to make the change.
It is nasty to have a situation where different programs on the same computer are getting different DNS results. Firefox, Chrome, Pidgin, Xchat, fetchmail, ncftp, wget, curl, apt-get, ssh, rlogin, netcat, Wireshark, tftp, ping, traceroute, smbclient, and everything else should all be in agreement.
(Score: 0) by Anonymous Coward on Sunday October 06 2019, @12:13AM (5 children)
"It is nasty to have a situation where different programs on the same computer are getting different DNS results."
I'm sure some of the carriers are spoofing DNS, so there is no way to validate this isn't already happening. It should be simple enough to check. Do a dig on a server halfway around the world and check the round trip times. If it is faster than the speed of light, then you know there is spoofing going on.
(Score: 2) by maxwell demon on Sunday October 06 2019, @08:16AM (4 children)
And how id the provider supposed to figure out from the DNS traffic which program on the same computer has sent out the DNS request? There's no field in the IP header for "name of the program that initiated the request."
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Sunday October 06 2019, @02:10PM (1 child)
Uh, in the context of this question? The provider knows which software because they're using different DNS resolving mechanisms (DNS, DoH, DoT) or explicitly calling different DNS resolvers?
A concrete example - I have tools which are bundled into micro VMs; they might well emit DNS to addresses they have internally configured instead of using the host OS.
(Score: 2) by maxwell demon on Tuesday October 08 2019, @02:53PM
Your internet provider installs software on your computer? My provider certainly doesn't, and I would not accept it if it did.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Tuesday October 08 2019, @02:05PM (1 child)
"There's no field in the IP header for "name of the program that initiated the request.""
that would be the port number field in either the TCP or UDP header.
(Score: 2) by maxwell demon on Tuesday October 08 2019, @02:52PM
No. The source port is a random number which only the local operating system could associate with a program, but certainly not the ISP. The destination port is the DNS port, no matter which program does the DNS request.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Sunday October 06 2019, @03:02PM
"Chrome, Pidgin, Xchat, fetchmail, ncftp, wget, curl, apt-get, ssh, rlogin, netcat, Wireshark, tftp, ping, traceroute, smbclient, and everything else should all be in agreement."
They would be if they were all transported over a single ciphered session protocol. A lot of this stems from the misconception that DNS is an OSI layer 7 protocol. It really isn't. It really should be considered a layer 5 protocol at the highest, and personally I think it should probably run at layer 3 or 4.
A big part of this is a fundamental design flaw in in the OSI model. The OSI model transposed layers 5 and 4. The reason I say that is that an exposed port number is not necessary for routing datagrams. The carriers have used "network management" as an excuse to snoop. If you want optimized traffic, you should be able to volunteer an optimization flag from the transport layer down to the routing layer, but it should not be mandatory.
So basically Berkeley sockets needs to be rewritten from scratch putting a crypto layer between IP and TCP/UDP. After which the carriers can suck it, and the whole problem goes away.