Hi, I'm Matt Chung, and I want to talk today about DNS privacy. Now, usually with DNS,
we hear about DNSSEC as in authenticating DNS queries. Here, I'm interested in a different
aspect of DNS security, and that is the privacy of DNS queries to protect users from
eavesdroppers finding out what sort of sites they're visiting if they are of sensitive nature.
And I decided to talk about this topic after coming across a paper that I found about a year
ago that talked about a novel approach to this problem. And so I decided to create this talk
that goes over some of my experience with this topic over the years, leading up to this paper
and some future thoughts about the topic. To begin with, I'm just going to do a brief
introduction to DNS, just a very high-level introduction so that we know what we're
talking about, and then we can talk about how we can preserve DNS privacy.
So, at a very high level, DNS, or the domain name system, is a way of translating a host name
into an IP address so we can find that on the internet. And basically, the way that works is
when your client is trying to access a site on a host, then it first sends out that host name
to its DNS server, which, if it doesn't know it, will try the root name server. And in this case,
if they're looking for www.wikipedia.org, it tries the root name server, and it says,
well, I don't know where that is, but try the org name server. And the org name server may say,
I don't know where that is, but try the wikipedia.org name server. And from there,
that name server says, oh, I know, it's this IP address. So it has this hierarchical structure
that it works through recursively. Now, the first aspect of DNS privacy that I'm going to talk about
is what we sort of call local privacy. It's the first aspect that I considered in terms of my own
personal threat model. And so we'll discuss what the challenge is and some solutions that can
easily be undertaken. So the first situation is you might be browsing the web at a cafe using open
Wi-Fi. And so what I have here is just a screenshot of Wireshark capturing DNS packets.
Now, this isn't particularly for Wi-Fi, but this just gives an example of what that would look like.
Here, we're seeing a DNS query for google.com. And it would be very simple for somebody with
a laptop and Wi-Fi card to sniff traffic like this on open Wi-Fi at a coffee shop. So
as you can see, it's all plain text. In this case, looking at google.com,
it's generally not considered a purely sensitive post. But if you're looking up information about
a health condition or any other issue that you don't want to... or other information that you
don't want people to know that you're looking up for the reason if it's not considered socially
acceptable, you don't want people to just be able to sniff that information over Wi-Fi.
So the first solution that I considered over the years was to tunnel DNS over SOCKS proxies. So
first, I just wanted to make sure that all traffic was being encrypted, especially
10 plus years ago, not every site was using HTTPS. So if I was out and using open Wi-Fi,
I would use an SSH server that I was running and tunnel all of my traffic through there.
And this diagram just gives a basic overview of what that does. But the idea is I use SSH,
which is an encrypted protocol, as a tunnel for all the rest of my web traffic. And by default,
most browsers will tunnel the main HTTP traffic, but it doesn't always tunnel the DNS traffic.
So ultimately, the SOCKS proxy will tunnel it to the remote server over SSH. And then from there,
it all gets sent as if you were local there. So whether it was any traffic that is encrypted or
plain text gets sent from that location. So the idea being that I don't trust my immediate Wi-Fi
neighborhood, but I might have greater trust in the network area where the SSH server resides.
As I mentioned, browsers don't necessarily, by default, tunnel DNS traffic over SOCKS proxies.
However, in browsers like Firefox, there's usually a setting that you can set. So in this case,
if you go to about config, you'll get a little warning that making changes to these settings
may be dangerous. But if you search for SOCKS remote DNS, you'll see that by default,
this actual value is set to false, but you can set it to true. And then whenever you're using
a SOCKS proxy, it gets sent over that. And if you're using SSH, it's all encrypted. So
the only traffic that somebody over Wi-Fi will see is SSH traffic. And they won't even be able
to tell if you're surfing the web or making any other DNS queries. It's all tunneled over SSH.
The other alternative is to use a VPN. Many people use VPNs now. Corporations use VPNs for
remote workers, which is especially common nowadays. And that just tunnels all traffic
from one machine over to another over an encrypted tunnel. Similar to the SSH setup,
however, with the SSH SOCKS proxy, that was primarily web traffic. Other network connections
could be sent over the local network. And in that case, those DNS queries could be leaked out.
But it requires a little bit more infrastructure to set up a VPN. Many Linux servers, Linux machines
have SSH just installed by default. So it's simpler if you have a home machine, you could
do the SSH SOCKS proxying without having to set up a VPN. And then the next consideration I had,
and this is something that I played around with, but many of you are maybe familiar with Tor.
And this just gives a brief overview of how Tor works. Tor basically encrypts your communication
through multiple hops, so that your client and the first entry node into the Tor network
know about each other. And that node knows about the next node. And then that next node
knows about the exit node. But each node doesn't know about ones outside of the ones that they're
communicating with. And each level is encrypted. Now, Tor only works with TCP traffic, and DNS is
a UDP protocol. And we're not going to worry too much about the details of that. But typically,
Tor clients will actually, underlying, it's using a SOCKS proxy, and it will just manually,
forward that host name all the way to the exit relay. And then the exit relay will make the
DNS request, and then forward that back to the client for the final TCP connection.
So this provides perhaps even more protection than the others, because
it disassociates the client with the DNS in a more obfuscated way. However, there are
network analysis attacks that could correlate the query, the traffic from the client,
including the DNS queries, back to the exit node. So now we'll talk about encrypted DNS protocols.
So in this case, we're going to have modified DNS protocols that will encrypt the traffic
to prevent eavesdropping and protect the confidentiality of their queries.
The first one is DNS over HTTPS slash TLS. Now, many of you may know that HTTPS is just HTTP
over TLS, so you might wonder what's the difference. Primarily, the main difference is that
DNS over HTTPS uses port 443 and will look like regular HTTPS traffic to anyone who's observing
it, whereas DNS over TLS uses its own dedicated port of 853. And there are pros and cons to
using this protocol, the different protocols here, depending on your perspective. From a privacy
perspective, DNS over HTTPS is generally the preferred one because you're not only hiding
the DNS query, but you're also hiding the fact that you're making a DNS query by just making
it look like it's a regular HTTPS traffic. For network administrators, though, they might want
to know that DNS queries are being made so that they can potentially be blocked, and so DNS over
TLS is generally preferred in that situation. Now, as I mentioned before, Tor, by default,
has a mechanism to make, essentially, DNS queries on behalf of the client
without you really tunneling the full DNS protocol over the Tor network. But there's also
been work towards actually implementing a DNS protocol over Tor. That's something that
Cloudflare has been doing. So Cloudflare also does the DNS over TLS, but they
are also doing DNS over Tor. And so, briefly, how that's working is, first, using a hidden service.
And just to briefly describe what hidden services are in Tor, basically, there is a rendezvous point
in the middle of the Tor network, and the hidden service and the client
essentially connect through that rendezvous point. So they don't actually know who's on either side
of it. But it's so that all the traffic is living inside the Tor network. And, essentially, DNS over
HTTPS or DNS over TLS can be tunneled through this hidden service. And that's one other
service that Cloudflare provides. Now, this protocol that I read about and referred to earlier
that came out a little over a year ago, it was called Oblivious DNS. And this takes a bit of a
different take on how to protect the privacy of clients. So this diagram goes over the basic
protocol. And I'll just talk through how it works. So the client would have an ODNS stub
running on their machine. And it would talk to a DNS recursive server. And
what it would... what the ODNS stub will do is create a session key and encrypt the DNS
name. And then append the .odns top-level domain to the domain name. So the encrypt...
the domain name gets encrypted, but will then act as like a regular domain name. And then
the authoritative ODNS server will have a public key, which will be used by the ODNS
stub to encrypt the session key. And that gets sent along with additional information in the
additional information section of the DNS request. That gets forwarded onto the recursive DNS server,
which then sends that off to the authoritative ODNS server. So what this does is it hides
the query from the recursive DNS server that you can see right after the stub.
So this server here can't tell what host the client is looking for. And over here,
it can't tell where that request came from. So even though it will decrypt the session key and
then decrypt the original host name that the client was looking for, all it knows is it came
from this recursive server and not from the client. And then from there, it acts as a regular
DNS server. Now in the actual implementation, they have it fall back to regular DNS if the ODNS stub
doesn't work. And in the paper, they get into more details about
how to manage load balancing of the DNS servers. But the basic idea is to hide
the information from this server so that if anybody were able to compromise the recursive
server, they wouldn't be able to tell what hosts the client was looking for. And on this end,
on the authoritative ODNS server, you wouldn't be able to know which clients were making the
requests in the first place. And this differs from the DNS over HTTPS and DNS over TLS standard
setups because even though that preserves privacy from an eavesdropper on the network,
someone could still gain access to the DNS server and it could be logged who made which request.
So if this was through a government request or somebody hacked the server and dumped logs,
you're still vulnerable. Or even if it wasn't logged, a hacker could then monitor what's going
on that DNS server. So it will compromise the privacy of everybody who uses
that server, whether it's over TLS or not. And this way, it keeps information separate
and makes it harder to correlate. I will say that the DNS over Tor seems to accomplish a similar task,
but I think this was a very interesting solution to the problem. And I just will include here
for a moment and just reiterate the basic process. So when you are going to make a DNS request,
you first generate a session key. And hopefully this makes it a little more clear. You encrypt
the domain name. And so that's what the brackets are indicating is that the original domain name,
in this case foo.com, is being encrypted with the session key K. And then it's appended with
the ODNS top level domain. And then the session key is encrypted with the ODNS authoritative
server's public key. And it's included in the additional information section in the DNS request.
So that it essentially looks like regular DNS traffic, but it's still encrypted and preserves
that privacy. And makes for an easy fallback to regular DNS. So after seeing this, and it was
because when I first saw the title of Oblivious DNS, it made me think of a particular cryptographic
primitive that I learned about 10 years ago called Oblivious Transfer. And that was actually
initially what I thought it was going to involve. And it didn't. But it got me to thinking that
perhaps one could combine these two just to add an additional layer of potential privacy.
So the concern I have is that actually if we go back and look at
the diagram of the Oblivious DNS setup, if one had enough network visibility,
they could potentially see traffic going from the ODNS stub to the DNS, recursive DNS server,
and then from there to the authoritative server and then help found there. That'd be a lot of
network visibility, but it's conceivable. And so there could be correlations between
the DNS requests made by the authoritative server and the requests coming from the clients.
So it got me thinking, what if the authoritative ODNS server cast results like most DNS servers do,
and these would have to be invalidated after a timeout as, again, as regular DNS servers do,
but they could store it in what's called an encrypted distributed hash table. And so that
I can talk about how one could essentially query the authoritative server. And this is
very high level. I don't have a fully worked out protocol, but just something to think about.
But they could query the authoritative server to see if it already knows the host that it's
for without revealing what that host is. And then if it already knows it, it can get that
IP address, again, without revealing additional IP addresses from the DNS server and revealing
which host to the DNS server the client is looking for. So that involves a couple of things first.
So with a hash table, you have a key that you need to search for. And so you need some way of
searching text. And you can use additively homomorphic encryption to do this. And I'll
describe actually in a plain text version of the protocol first how that works. And then
you can see how if I'll briefly explain additively homomorphic encryption, and you
can see how this technique would allow you to send an encrypted query to search the hash table
to see if the key exists. And then we'll talk about blues transfer and how to actually get the
value out of it. So this protocol was developed actually for, well, as a modification
of a neural network protocol or method to do text pattern matching. And it was developed
as a way of creating an encrypted text pattern match protocol. And the way it works is that you
have some alphabet. In the original technique, it was... in the original protocol, they were
concerned with potentially searching for DNA sequence patterns. So you'll see the alpha
that here is A, C, G, and T. And what you do is you have what you call a character delay vector.
So for each letter in the alphabet, you say, okay, the idea is assuming as we're moving through
the text that we're searching, if at this point from here on out, we're going to match the pattern,
how much further should we go in order to say that we're at the end of the... what we mean so that
it's at the end of the pattern. A little complicated, but we'll look at this example
here. So the pattern here is TACT, T-A-C-T. And the first letter is A. So if that... if the A that
we find is in this... is part of this pattern, then two letters later, we'll be at the end of
the pattern. So we'll put a one there. If... or for the next letter, C, if we find a C,
then there's only one letter later that we need to go to get to the end of the pattern.
There are no Gs, so if we find a G, we're not in that pattern at all. And for T,
there's actually two possibilities. We could be at the beginning of the pattern,
in which case you'd put a one at the end of this little vector.
Or we could be at the... so if it's the T at the beginning, we put a one at the end of the vector.
And if it's the T from the beginning... sorry, T from the end, then we put a one at the beginning
of the vector. So you'll see this one, zero, zero, one vector. The ones correspond to the
opposite Ts from the original pattern. And this diagram basically shows how
this text pattern matching algorithm works. You start off with a vector of all zeros, and then
through each letter in the text you're searching, you go through... you get the
corresponding vector from the pattern you're searching, and you just add shifting one over
as you go. So with G being the first letter, those all zeros, we add that, the vector remains unchanged.
We take the next letter A, and we add this vector one, zero, zero, one, zero, and we get... we update the
activation vector, as it's called, and so on and so forth. And you'll see that at the end,
because the pattern is there, there is a four, because that's the length of the pattern.
And the idea is that when you have the entire pattern, those ones all will add up in the same spot
to the whole length of the pattern you're looking for.
And so, basically, you just look for the number four, and you might say, okay, the pattern was found.
Now, as I mentioned, we want to do this in encrypted fashion. It turns out there are some
cryptographic algorithms that allow you to perform an operation that will give you the
ciphertext of the sum of the plaintext. So, if you have an encryption of zero and an encryption of one,
you can do an operation, and you'll get, well, in that case, the encryption of one as well. Or,
if you have an encryption of one and another encryption of one, and you perform an operation,
you'll get something that will be equivalent to the encryption of two. In other words,
if you decrypt that value, run it through the decryption algorithm, you'll get out two.
So on and so forth. So, the idea here is that you would encrypt these values, so you'd have
an encryption of zero, an encryption of zero, an encryption of one, an encryption of zero for A,
similarly for C, G, and T. And then you can do the same addition, as we see here,
and you'll end up with a vector that will have a value that's an encryption of four.
Now, one nice trick is that you can essentially subtract the encryption of the pattern length
from the entire vector. And then, instead of looking for the length of the pattern,
you're going to look for zero. And this is useful because there are some algorithms,
some ciphers, that while they do perform this homomorphic operation, it's actually
hard to really decrypt them. One example is using elliptic curves,
where the encryption of a number M is M times a base point. I won't get into too many details
about that. But for those who are familiar with elliptic curves, you can see that that's
additively homomorphic, but based on the security of the cipher, actually finding out what that M
is from a given point is hard. But if you're actually looking for zero, you know that's
going to be the identity, and that's easy to identify. So that's basically how you can do this
search in the key space of the hash table.
And then, once you know if the host name is in the cache of the Oblivious DNS server,
then you want to actually retrieve it. And here we'll use a technique called Oblivious Transfer.
And basically what this is, is we have an index into the... so maybe we find out that it was the
fifth host that was in the list. Then we can essentially request the fifth entry without
revealing that we're actually asking for that one. And the DNS server will send us back data that
will only give us information about the fifth one and not any of the other IPs for the other hosts.
Now, I will admit that Oblivious Transfer actually has a fairly high bandwidth, so
requires a lot of data transfer. But that's something that could be considered for the future.
And just want to end with some references for the actual... above is the actual paper that
started this idea for this talk, the Oblivious DNS paper. And then a couple links to Cloudflare
that just talks about the DNS over HTTPS and DNS over TOR. So with that, I look forward to
answering any questions. Thank you. Hi Matt, what a fantastic talk. Thank you so much for speaking
this year again at the Crypto Privacy Village as a longtime volunteer. It's always great to
have you back. I am pulling up some questions here from the Discord. Oh yeah, I see that one
coming through. So there's a question. Do you mind if I... Oh yeah, go ahead. Go ahead, please take it.
Yeah, so I see that somebody's asking, are there any implementations of ODNS?
If I recall correctly from the paper which I referenced in the reference slide, they do refer
to a Go implementation, I believe. So they do have one. I actually mean to check it out,
but I haven't got around to it. But yeah, if you grab the link off the slide deck or
if you just search for ODNS or Oblivious DNS, it shouldn't be hard to find.
And the one thing that occurred to me when thinking about playing with this is, well,
if I don't have more than one person using the same server, then it semi-defeats the purpose.
Because part of the point is to have multiple people connecting to the same ODNS server and
making it difficult to track which one made which request. But yeah, that's something I've
been thinking about playing around with myself. Fantastic. Does anyone have any more questions
for Matt? You can drop them into the Discord. People are typing.
Yeah, I figured it wasn't like a super technical talk, so there might not be a ton of questions,
but just something that I came across last year. I was like, this sounds interesting. I want to
read up on it and figured this would be a good way to force myself to actually read the paper.
We have another question that just came in. Are there specific foreseeable problems with ODNS?
Oh, that's a good question. So, not necessarily that I can think of. So,
one of the things I've been thinking about is comparing ODNS versus some of the other options.
One of the... like, I think the only other option that provides similar levels of privacy
was the DNS over Tor. So, doing DNS over HTTPS over a hidden service in Tor.
But one of the problems with that is that people can see they're using Tor. So, as I understand
the way the ODNS works, it more or less looks like regular DNS traffic. If you do look at it
closely enough, you can see the ODNS TLD, which will somewhat flag that. But you have to look
fairly hard. But other than that, I don't know of any other issues. But something to think about,
certainly. Fantastic. I will... I'll throw a question at you, since I have you.
And just to give anyone some extra time, if they have any additional questions.
Are there any... you know, we're all virtual. I've heard there are, like, hundreds of talks.
Are there any other talks that you're really looking forward to seeing during this DEF CON
virtual weekend? That's a good question. So, there's actually one that I found out about
yesterday. But it was actually earlier. So, and this is... I saw that Chris Weisoppel was
doing a talk in the Red Team Village. So, I actually did check that out this morning.
You know, partially because he's the founder of the company I work for.
So, and I've got to know him a little bit. I was curious to see what he had to say.
And we got to learn a little bit more about his history with Loft, which was pretty cool.
Because I hear the stories about those days from Chris and Christian. But there was more
interesting things. Like the... he was talking about pen testing his prospective employer,
which was pretty interesting. Because he was, like... not many times do you get the opportunity
to hack your future employer's voicemail and find out what they're actually thinking about
your negotiations. Because apparently, they were asking for a sneakers van. Like,
from the movie Sneakers. And they were, like, these guys want a Winnebago.
I don't think they quite understood what the purpose of it was. So, that was actually one
that I found about and did get to check out. I've been kind of... blank on the word. But I
haven't really been keeping up with all the entire schedule. So, I need to take a look at that.
But of course, I also enjoyed the talks from the village... from this village so far today.
Been watching the streams since 10 Pacific time.
Fantastic.
And look forward to the ones tomorrow, too.
Yeah, I'm looking forward to all of them, too. And thankfully, everything is going to be
available after the conference to download, to stream on various services. Oh! We have another
question that just came in. Are there any practical implementations of ODNS yet?
Or is this theoretical at this point?
Yes. I'm not sure if you caught the... so, somebody else asked about an implementation. And
so, as far as I know, there's a Golang implementation out there that the researchers
used. And I believe it's on GitHub, but I don't remember. I could be remembering incorrectly.
But it is referenced in their paper. So, if you caught that from my reference slide,
or if you just Google for ODNS, you should be able to find their paper fairly easily.
And I'll have links there, I think. Pretty sure.
Fantastic. Well, thank you so much, again, for your time. And as always, for being a volunteer
at the Fitzgerald Privacy Village. I look forward to seeing you, hopefully, in person next year.
Yep. Hopefully.
And all that other fun stuff. So, thanks again.