Sorry spooks: Princeton boffins reckon they can hide DNS queries The Domain Name System (DNS) is a plain-text service that lets anyone who can see “the wire” capture a user's DNS traffic and work out whether they're asking for naughty.com or nice.com. So to help enhance its privacy a group of researchers has proposed a more "Oblivious DNS” protocol. However, as the group explained here, …
"how does this differ in its security model from NAT over TLS? Both approaches rely on a client-end gateway to mask/translate the user IP, both give a level of encryption across the standard infrastructure."
1. Aggregation of queries at the ODNS servers helps resistance to de-anonymizing timing attacks.
2. Splitting the functionality over two different security domains increases resistance to other attacks. If it is set up to ensure queries are sent to ODNS servers in other countries, even more benefits may ensue.
Same way they're identifying TOR users, by matching the timing of encrypted packets to and from the user to the ones that come out various endpoints. Timing could be randomized a bit, but who wants unnecessarily delayed DNS queries? I don't think we can really trust a chain of new servers out there beyond our watchful ISPs. We need to install a new component on our devices which encrypts/tunnels all DNS queries, perhaps along with padding and random fake activity.
Timing could be randomized a bit, but who wants unnecessarily delayed DNS queries?
Me. If it restores a bit of privacy I'll accept a small delay and so long as the server is good and busy it does only need to be small. A local DNS cache will ensure only the first request for a domain gets hit anyway.
Why on earth is this being considered?
Things are already slow enough as they are these days. The TLS handshakes underneath https are dog slow, and TLS is for the vast majority of internet traffic utterly unnecessary. For example, why does a free, public tech news website like The Register use https? It's not like the content being served up is personal or private in any significant way. The only thing it does do - that is, prove that the web page is coming from the site you think it is (depending on the degree of trust we can have in all the world's root CAs, i.e. not much) - is all well and good, but unfortunately where "proof of origin" seems to matter the most these days, where actual hard knowledge of where some content originated would be very useful, is inside ecosystems like Facebook, YouTube, etc. All https is doing there is proving that the fake news articles I'm being shown have genuinely been dished up by Facebook or YouTube. Great. What's the bloody point?
ODNS sounds slow, and added on top of https is going to make use of the Internet slower than it already is. How is that supposed to be regarded as "progress"? And if one were truly worried about "The Surveillance State", how on earth is the use of ODNS going to prevent a state observer seeing what IP address you actually connect to and doing their own reverse lookup in their own tables?
ODNS sounds like something wanted by only the most paranoid of Internet users or those who truly have something to hide. The vast majority of us don't give a shit about it. So before a small clique of privacy wonks force the world to abandon use of DNS as we know it and roll something like this out across the entire bleedin' Internet, please, someone tell them where to get off.
downvote for the something to hide gibe: the fact that your current stance is acceptable to TPTB doesn't give immunity for all time.
however, have to agree with some of it, I see no reason to trust CAs and given that you eventually get to naughty.com I can't see how you can hide that fact other than by using tor.
I think a look at the threat model would give some clarity.
The vast majority of us don't give a shit about it.
Thanks for summing up the issue in once sentence.
I'm sure when Hitler came to power the vast majority also didn't give a shit. Yes, it's early to invoke Godwin's law but there really is no better analogy. A government that keeps taking power and the liberties of the people is only going to go one way and if they don't there will be a government in waiting to abuse those powers. Have you learnt nothing from history?
Thats the point - most people don't care about this and it will slow things down. From an end-user perspective, when they browse, if pages take longer to load (which they will having to do TLS encryption/decryption) they will moan that their internet is slow!
From my history in desktop support and now working for an ISP, I can see it from both sides and I'm not find a positive!
@Sir Runcible Spoon,
However, if you prefer to make it more costly for tptb to snoop on you then it's nice to have options.
Eh? TPTB probably don't give a damn what DNS look ups you do, they're going to be more interested in what IP addresses you actually connect to. Using a pseudo anonymous resolver in no way hides the IP address you end up connecting to. I don't see this making any difference whatsoever to TPTB, or to a nosey ISP. In short, it adds almost nothing to the privacy of one's Internet usage.
@AC - "I'm sure when Hitler came to power…"
During the English Civil War, there was a lot of grief for the political classes, but for most of our ancestors life just carried on more or less as usual. The King had been accused of trying to ignore parliament; but then Cromwell famously told parliament to get lost.
After Cromwell's death, the Good and the Great decided to restore the monarchy under negotiated terms. The Restoration was a time of great joy: not for the political changes but because it was the end of Puritanism, which had been a much greater offence against the Englishman's ideal of robust common sense within a Merrie England.
There is far too much Puritanism in modern life. The West needs changes akin to the Restoration, which would end the need for Big Brother to pry into our Internet usage.
Yeah, why on Earth would a large website with lots of readers who work in IT want to make sure it isn't easily subject to MITM data injection attacks, or a website used by 2bn people. No one would ever want to inject anything malicious in to them would they? Nothing to be gained :rolleyes:
Yeah, why on Earth would a large website with lots of readers who work in IT want to make sure it isn't easily subject to MITM data injection attacks, or a website used by 2bn people. No one would ever want to inject anything malicious in to them would they? Nothing to be gained :rolleyes:
Yeah, because no Certificate Authority anywhere on the planet will ever sell a cert for google.com to someone who isn't Google. What's that? That's already happened? Well that's just crap.
The system of CAs we have is junk. There's too many, and they don't do a decent enough job. We've seen time and again the use of stolen certs, or inappropriately acquired certs, in a variety of malware (some of it state originated, apparently), phishing sites, etc. The browser developers are gradually reducing the number of CAs they blindly trust, but that doesn't really solve the problem. The problem is that for a CA to properly attest to the identity of a person / organisation should cost quite a lot of money, access to government records, examination of government issued identity documents, etc, but no one wants to spend that much establishing customer's identity because it comes straight off their profit margin.
Whilst running a CA remains a profit-motivated business, MITM will continue to be a problem.
"Whilst running a CA remains a profit-motivated business, MITM will continue to be a problem."
Then you can't win. You can't trust private enterprise to do it right because they're corrupt, you can't trust government to do it right because they're corrupt, and you can't trust yourself to do it right for lack of knowledge. IOW, who CAN you trust?
"The Register use https? It's not like the content being served up is personal or private in any significant way."
So says an AC.
Besides, by seeing your traffic and your comments, even as "AC" which of course isn't in anyway (The register know your source IP, email address you created it with, timestamps and every post you've ever created), you can build up a profile of when you are online, your likes, dislikes and even political leanings, simply by tying your comments together.
Speaking for myself, I don't care for the Glorious Republic of Gilead going over my once-legal public discussions for signs of being a compelling Influencer who would probably benefit from a Holy Redemption.
Nor do I care to accommodate today's bastards, who will be the Gilead's Commanders one day, to inject fake news into my newsstream, or monitor my fertility discussions with partner and doctors.
I guess I'm just a silly-willy.
Crafty but obvious. It simply recurses to the odns server which has the other half of the key-pair, which then proxies the lookup. I suppose if one is trying to build a map of what a particular computer is doing, then this would help prevent that, but then so would using a revolving DNS package with a very disparate list of lookups. You'd have to scour dozens of resolvers to gather the map. This method concentrates all of the DNS requests to a single resolver. Unless one combined those methods of course; that would be like putting a jigsaw through a shredder that dumps its load in front of a leaf blower powered playground roundabout.
The ODNS stub server is local to your machine - it's yours. It's there to convert standard dns requests to encrypted odns requests before the information leaves your system to go to the ISPs recursive server.
It's your ISPs recursive server that contacts the ODNS server - All ODNS servers (and any spies) would see is your request coming from them.
All your ISP (and any spies on that side) would see is an encryped request.
To track it down, you'd have to have access to both the ISP and ODNS servers (not simply their traffic) to tie the two together, or of course, access to your own machine, in which case, game is already over!
Of course, if you don't use the ISP's DNS, but run your own directly, this won't protect you.
Been hearing about DNS stuff since a while already, and I don't get why DNS should be encrypted. After all, this "security" measure sounds nice (not a network expert), but once I have the IP to use, I use it, and that can't be encrypted, now can it ?
So it's all nice and well to encrypt my DNS request, but it does bugger all when my browser then uses the encrypted response in a non-encrypted way to get me to the page I expect to go to.
In other words, if someone is watching my line and can intercept the DNS requests, then they can intercept the result as well. If they are just watching the DNS server and have no link to me, it must be as exciting as watching paint dry. Oh look, somebody else has asked for the IP of cupcakesgalore.org !
After you've done a DNS lookup, you're going to do something with the result, by connecting to the resolved IP address. Obviously, if that's a non-encrypted session then it's game over.
But what you might not realise is: if that something is a TLS connection (e.g. HTTPS) then the name of the site you're connecting to is contained in clear text in the first couple of packets, thanks to Server Name Indication (SNI). Use Wireshark if you want to prove this to yourself.
SNI was designed to allow multiple HTTPS web sites to share the same IP address. So suppose we backed away from this, and gave each web site its own IP address (as would be possible with IPv6)? In that case, you could trivially build a database of hostname to unique IP address mappings by logging at any busy resolver, and therefore reverse IP address to hostname directly.
Either way, the name of the host you're connecting to is trivially exposed. Being able to monitor individual DNS lookups is not the weakness here.
Thank you for the explanation, but I still don't "get it".
You talk about an encrypted session, and that I totally understand, but even in an encrypted session, the IP address is not encrypted, right ? On top of that, the actual server name is in cleartext, so what is the point of encrypting the DNS request ?
Additionally, you say yourself that "Being able to monitor individual DNS lookups is not the weakness here", but the issue in the article is about encrypting DNS lookups.
I like my privacy as much as the next guy (certainly more than FaceBook users), but unless I have my own DNS server, I have to accept that where I'm going is pretty much an unavoidably clear bit of information that any governmental agency can get a hold of.
With encrypted sessions, what I do there is my business, but just like going to the cinema, the fact that I went there is pretty much public knowledge these days. What film I saw, on the other hand, is a lot more difficult to find out if I pay for my ticket in actual, cocaine-covered cash.
You talk about an encrypted session, and that I totally understand, but even in an encrypted session, the IP address is not encrypted, right ?
Absolutely correct. So if you see a user sending a packet to 1.2.3.4, and you happen to know that badsite.com (and no other DNS name) resolves to that address, then you can be pretty sure that the user was connecting to badsite.com, regardless of the packet contents. [^1]
My point is just that if an attacker can snarf your DNS traffic, then they can probably snarf the rest of your traffic as well. And the rest of your traffic is either unencrypted, or (in the case of TLS) contains the name of the site you are connecting to, in cleartext.
So encrypting or obscuring the DNS is only valuable for one small corner case: an attacker who has access to all your DNS traffic, but not the rest of your traffic.
As has already been observed: DNS queries coming *from* the resolver are already aggregated across many users, so the only valuable part is DNS queries going *into* the resolver; and the attacker still has to know which source IP address belongs to which user. If they have that level of access, then they probably have access to all your traffic.
[^1] You can easily find out that badsite.com resolves to 1.2.3.4 just by logging all the forward DNS queries that a large group of users perform - which just needs access to the resolver logs at any large ISP.
However with the very widespread use of virtual hosting and CDNs, many names will often resolve to the same IP address. Hence the SNI information inside the TLS handshake is actually much more valuable.
"Either way, the name of the host you're connecting to is trivially exposed. Being able to monitor individual DNS lookups is not the weakness here."
Being able to monitor DNS lookups is one weakness, which needs to be addressed.
The plain text URL is another issue that should be fixed in a better form of https.
The URL matters a lot less if it is coming out of a VPN service.
Browser fingerprinting or system fingerprinting represents another attack surface, but there are measures for those issues, as well.
If you are securing a building you don't lock a few random doors and windows, you systematically lock them all.
>Being able to monitor individual DNS lookups is not the weakness here.
What if you combine it with TOR?
The other handy thing I can think of is to have a dns cache pretend to be a zone and allow isps to push their caches to on-prem dns servers as secondaries. Also you could have dns servers automatically refresh expiring entries regardless of user requests or lack thereof.
I'd argue that adding a TLD to the internet is certainly not the "no change" approach to deployed DNS infrastructure. While they've avoided the necessity for software to be deployed, they've added the necessity for a TLD to be added to the root zone. Just ask the homenet people how easy it is to get your own personal tld enshrined in an RFC and added to the root. The other alternative is via ICANN. Good luck.
As many people have pointed out in the IETF DPRIVE group, being observed using a privacy service may in and of itself represent a risk to the user. And the ODNS model will allow any spying entity to easily harvest logs for .odns destinations from compliant recursive operators or from their own network observations.
I applaud their efforts, but would caution against any assumptions that this will be easy or secure enough.
The "attack surface" is roughly speaking "The ISPs DNS logs every packet in its entirety and that log is readable by a hostile agent. This enables a client's entire internet activity to be mapped out where DNS lookups are being made."
The mitigation is to encrypt the request which the ISP is logging, but to do so in a way that a bog-standard DNS service can handle the query.
Application asks the transport layer for a website, say. l33th4xerr.org
The transport layer is charged with sorting this out, and presumably the .odns stub will sit here.
The .odns Top Level Domain is added by the stub inside the client or in the client's own Firewall/NAT/DNS relay, and this encrypts the requested address, so you get a lookup request for something like:
x.x.x.x wants the IP for 30831r]83Rouy[498tby[8nyr84[B'CRB.odns
The ISPs DNS throws its hands up in the air and says "I'll have to refer this to .odns as the source of authority".
The x.x.x.x is now replaced by the DNS relay...
r.r.r.r wants the IP for 30831r]83Rouy[498tby[8nyr84[B'CRB.odns query reference number 12345
.odns, as a source of authority, strips out the session key which it will use to encrypt the response, decodes the real request, looks it up, gets the response and encrypts that before sending it back to the ISPs DNS, which is the only IP address that it has - the originating requestor's IP address isn't included in the query string.
So the response now reads:
To r.r.r.r from .odns. In response to query reference 12345
The IP addresses for 30831r]83Rouy[498tby[8nyr84[B'CRB.odns are 4c34c3442r2cc5gdfgr4344tf33, dfarf7fpqn8tt9[]5t5]tbq5[t and fifty98[b3[[];'\g-0]-k
Now, the ISPs DNS isn't going to understand what the response is. The reason that the response is encrypted is so that the reply doesn't reveal the IP address of the query because the ISPs DNS is going to change the response to:
To x.x.x.x from r.r.r.r.
The IP addresses for 30831r]83Rouy[498tby[8nyr84[B'CRB.odns are 4c34c3442r2cc5gdfgr4344tf33, dfarf7fpqn8tt9[]5t5]tbq5[t and fifty98[b3[[];'\g-0]-k
And that will be logged.
The .odns stub then takes the encrypted part of the response and uses the private key to the session key that it sent to change the reply to:
To originating computer, the IP address for l33th4xerr.org is 12.43.128.12
or if the stub is sitting in the transport layer of the client, it will pass that on to the resolver and add it to the local address resolution list.
If you pwn the .odns, you only see an ISPs DNS asking for dodgy URLs, if you pwn the ISPs DNS, then you see a lot of nonsense requests for a particular IP address on that network - a household with a NAT Firewall or something. If you pwn both then you can get the complete picture.
The problem I have with this is that the encrypted reply might need to be understood by the ISPs DNS. Surely it will be trying to parse the response in order to cache it or something. And the character set of both request and response must fit within the footprint of what a domain name can be, although with multibyte domain naming allowed now, I guess that restriction is cited slightly.
To originating computer, the IP address for l33th4xerr.org is 12.43.128.12
At which point the client presumably opens up a connection to 12.43.128.12 using port 443 with the data 'l33th4xerr.org' in the header.
So, what would be the point of hiding the DNS query?
Much better to run your own VPN server and DNS proxy remotely and connect to that.
If you have spooks either (A) watching a DNS for trigger events or (B) going through DNS logs, then this method either (A) doesn't trigger the alert flag at the ISPs DNS or doesn't reveal the exact origination of the request at the .odns end and (B) means they have to obtain two sets of logs, potentially in two different jurisdictions, in order to decode the footprint.
All bets are off if they are watching an individual user; this methodology simply makes casting-a-net-and-see-what-we-get less worthwhile of an activity.
"That would take some organisation, and legislation. Have they really gone to that trouble?"
???
As I recall, GCHQ's avowed goal is to record and save every packet on the internet. NSA's seems to be to hack every accessible server and network. Maybe the CIA is taking care of the endpoints.
Rinse and repeat for other major or ambitious countries.
"@TRT. not in the UK they don't - they only need to look at your ICR. (Internet Connection Record)"
So either you can drive a VPN tunnel out to a less Orwellian country, or you should stop using the internet in the UK.
In particular, if you are a business, don't locate there, if you are a person, add it to your list of flyover countries.
"All bets are off if they are watching an individual user; this methodology simply makes casting-a-net-and-see-what-we-get less worthwhile of an activity."
I'm all for avoiding the million to one ratio of false positives to real hits provided by universal surveillance.
"Much better to run your own VPN server and DNS proxy remotely and connect to that."
Not at all.
If it is your private VPN server, it is a unique identifier, albeit one which may take some minimal effort to interpret.
A VPN service, on the other hand, aggregates hundreds or thousands of users together, making identification much more difficult.
"It would make more sense to code the .odns tld details into the client side part, at which point this is just moving the trust model to odns from the ISP/whoever. i.e. no real difference to now."
Collapsing the entire thing into one security domain almost certainly increases vulnerability.
"As many people have pointed out in the IETF DPRIVE group, being observed using a privacy service may in and of itself represent a risk to the user."
On the other hand, if you are already using one or more 'privacy services' then adding to the available protections is all to the good.
Also, the more people using it, the better off everyone is - this should be the default DNS configuration, once available, just as https has become the default browsing protocol.
The whole DNS thing is quite an antiquated model imo, surely we can all have a copy of the TLD database if we are that worried about security. Use blockchain for something other than laundering drug money for a change!
If the DNS databases are on my machine/server then I don't have to tell anyone what i'm looking up, I can look it up locally!
The TLD database (the root zone) is only a few hundred entries and is easily downloaded.
You may even be able to get a copy of some of the second-level domains: e.g. dot com which is nearly 134 million records.
But that's still no use to you, because it only points to 134 million sets of nameservers which contain the data for those domains. They are not publically downloadable. For example: the second-level list will tell you who the nameservers are for amazon.com, but you won't be able to get the contents of the amazon.com zone. So if you want to look for www.amazon.com, you're still stuck sending a DNS query for "www.amazon.com" to one of Amazon's nameservers.
I've got a better idea.
The DNS database is distributed, right? So why not just distribute the processing as well?
I mean _really_ distribute it.
My ADSL would then be doing random lookups for everybody on the planet, as well as for me, and nobody would have any idea which ones were for me. (Or at least they couldn't prove anything, and even NSA/GCHQ couldn't monitor that lot anyway.)
My ADSL would then be doing random lookups for everybody on the planet, as well as for me ...
Riiiggghhhtt. I've run resolvers before, and one thing I can recommend you don't have is an open resolver on your ADSL line ! We had to lock ours down to just IP ranges used by our clients - otherwise I will guarantee that it isn't long before you start getting used for DDoS attacks* and other dodgy practices.
The other issue is that in so many jurisdictions, plod tends to take the line that it happened on your connection so it must be you doing lookups for (eg) kiddy porn sites. In fact, some jurisdictions expressly make it your responsibility for whatever is done on your connection. Yeah, you might be able to prove your innocence ... eventually. But in the meantime, you'll have been branded a kiddy fiddler in all the local papers, had to manage without any of your IT stuff because the plods took it for examination (you'll get it back, maybe a year or two later - and it might even still work if you're lucky), locals will assume there's no smoke without fire, depending on what you do you could lose your job, the stress could cause your family to break up, and so on.
And when you do eventually prove that it wasn't you and you are totally clean, the papers will report on it in tiny print on the gazzilionth page that no-one reads - so no-one will know that you've been shown to be clean and you'll have this whiff of being a dodgy type following you around for evermore.
* Because DNS defaults to UDP first, there's no verification of client IP address - it can be spoofed. So the b'stard doing the DDoS attack searches for a query that returns a large response that still fits within one reply packet (if it's too big then the resolver tells the client to switch to TCP). So the attacker sends you requests for "foo.bar.com ANY" having found that foo.bar.com actually resolves to 20 cnames. Thus one small query resolves to a lot of data, the small packet is amplified, and the larger result is sent to the target of the attack. That way, a relatively small number of compromised machines can generate a lot of small packets which result in much bigger packets being sent to the target - way more data than the small number of compromised machines could manage on their own.
> The recursive resolver a user connects to knows the IP address of the user, but not the query; while the ODNS resolver can see the query, but only knows the address of the recursive resolver the user connects to, not the user.
Right, so, it's a single-node Tor relay basically - just without Tor.
Or even a proxy server, as it were.
Got it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
