nakedsecurity.sophos.com Open in urlscan Pro
2a04:fa87:fffd::c000:42e3  Public Scan

URL: https://nakedsecurity.sophos.com/2018/04/10/how-odns-keeps-your-browsing-habits-secret/?utm_source=feedburner&utm_medium=feed&utm...
Submission: On November 22 via api from DE — Scanned from DE

Form analysis 3 forms found in the DOM

GET https://nakedsecurity.sophos.com/

<form target="_top" role="search" class="search-form" method="get" action="https://nakedsecurity.sophos.com/">
  <fieldset>
    <div class="field">
      <input type="search" value="" name="s" class="search-field" placeholder="Search naked security...">
    </div>
    <div class="submit">
      <button type="submit" class="search-submit button">Go</button>
    </div>
  </fieldset>
</form>

POST

<form onsubmit="return false" method="post" action="" id="newsletter" class="ready" autocomplete="off">
  <div class="newsletter-messaging">
    <h3 class="newsletter-title success-hide">Get the latest security news in your&nbsp;inbox.</h3>
    <div class="state failure">
      <div class="icon"></div>
      <p>Sorry, something happened and we could not sign you up. Please try again later.</p>
    </div>
    <div class="state success">
      <div class="icon"></div>
      <h3>Congratulations, you have successfully signed up for our daily news!</h3>
      <p>Check your inbox for our confirmation email.</p>
    </div>
    <div class="state bademail">
      <p>Sorry, we will not accept that email address. Please try a different address.</p>
    </div>
    <div class="state busy">
      <p>We're adding your address to our list...</p>
    </div>
  </div>
  <div class="state ready controls">
    <div class="capture"><input type="text" value="you@example.com" class="email virgin" name="email"><input type="submit" value="Subscribe" class="button" name="submit"></div>
  </div><button class="close-link">Don't show me this again</button>
</form>

POST https://nakedsecurity.sophos.com/wp-comments-post.php

<form action="https://nakedsecurity.sophos.com/wp-comments-post.php" method="post" id="commentform" class="comment-form" novalidate="">
  <p class="comment-form-comment"><label for="comment">Comment <span class="required">*</span></label> <textarea id="comment" name="comment" cols="45" rows="8" maxlength="65525" required=""></textarea></p>
  <p class="comment-form-author"><label for="author">Name</label> <input id="author" name="author" type="text" value="" size="30" maxlength="245" autocomplete="name"></p>
  <p class="comment-form-email"><label for="email">Email</label> <input id="email" name="email" type="email" value="" size="30" maxlength="100" autocomplete="email"></p>
  <p class="comment-form-url"><label for="url">Website</label> <input id="url" name="url" type="url" value="" size="30" maxlength="200" autocomplete="url"></p>
  <p class="form-submit"><input name="submit" type="submit" id="submit" class="submit" value="Post Comment"> <input type="hidden" name="comment_post_ID" value="402891" id="comment_post_ID">
    <input type="hidden" name="comment_parent" id="comment_parent" value="0">
  </p>
  <p style="display: none;"><input type="hidden" id="akismet_comment_nonce" name="akismet_comment_nonce" value="bd6927efbd"></p>
  <p style="display: none !important;"><label>Δ<textarea name="ak_hp_textarea" cols="45" rows="8" maxlength="100"></textarea></label><input type="hidden" id="ak_js_1" name="ak_js" value="1669149959354">
    <script>
      document.getElementById("ak_js_1").setAttribute("value", (new Date()).getTime());
    </script>
  </p>
</form>

Text Content

Skip to content
by
 * Products
 * Free Tools
 * Search
 * Free Sophos Home

Go
XG Firewall
Next-Gen Firewall
Intercept X
Next-Gen Endpoint
 * Sophos Cloud Optix
 * Sophos Central
 * Sophos Mobile
 * Intercept X for Server
 * Secure Wi-Fi
 * Phish Threat
 * SafeGuard Encryption
 * Secure Email
 * SG UTM
 * Secure Web Gateway

For Home Users

Sophos Home protects every Mac and PC in your home

Learn More
Free Security Tools
Free Trials
Product Demos
Have you listened to our podcast? Listen now



HOW ODNS KEEPS YOUR BROWSING HABITS SECRET

10 Apr 2018 15 Privacy


GET THE LATEST SECURITY NEWS IN YOUR INBOX.

Sorry, something happened and we could not sign you up. Please try again later.


CONGRATULATIONS, YOU HAVE SUCCESSFULLY SIGNED UP FOR OUR DAILY NEWS!

Check your inbox for our confirmation email.

Sorry, we will not accept that email address. Please try a different address.

We're adding your address to our list...


Don't show me this again



POST NAVIGATION

Previous: How to check if your Facebook data was shared with Cambridge Analytica
Next: Congress grills Zuckerberg, day one: How does this online stuff work?
by Mark Stockley
 * 
 * 
 * 
 * 

In computing, popular ideas have a way of becoming part of the bedrock and, once
petrified, they’re extremely difficult to dislodge.

It doesn’t matter how good or bad an idea is, how well or how poorly something
is coded or how insecure it is, if something is widely adopted it’s not going
anywhere fast.

For example, despite its inherent insecurity email remains central to our lives,
and Flash, despite a ready replacement and countless should-have-been-fatal
wounds, is dying as if there’s an Oscar on the line.

Finding new ideas is easy but replacing or retooling old ideas is hard.

That puts a premium on solutions that make things better, faster or more secure
by working with, or adding to, what’s already there with minimal disruption.

And that’s why ODNS (Oblivious DNS) is such an interesting idea.

ODNS is the latest entrant to an increasingly crowded field of solutions looking
to address the privacy problems of the global DNS (Domain Name System).


THE TROUBLE WITH DNS

DNS maps human-readable names for computers and services, like
nakedsecurity.sophos.com, into the numeric IP addresses that computers need in
order to communicate with each other, like 192.0.79.33.

Unfortunately DNS has a privacy problem – an adversary who can see DNS queries
can tell who is browsing where, even if those people are taking care to encrypt
the precise details of their browsing with HTTPS.

DNS traffic can be read in two ways: on-the-wire, as it passes over the
internet, or when it arrives at its destination.


HOW DNS WORKS

Let’s say you want to visit www.example.org with your web browser. In order to
reach that site your computer has to know its IP address, information it can get
via DNS.

It does this by asking the question “what’s the IP address
for www.example.org?” of a recursive resolver, which might be operated by your
ISP or perhaps a third party service, like CloudFlare’s 1.1.1.1 or Google’s
8.8.8.8.

In turn the recursive resolver consults the server that knows
about  .org addresses, which passes it on to the server that knows about
.example.org addresses, which passes it on to the authoritative server that
knows about www.example.org.

The authoritative server answers the original question, and sends the IP
address 93.184.216.34 to the recursive resolver, which sends it back to your
computer.

All this traffic is visible on-the-wire to anyone on the same network as you and
to your ISP (or your VPN provider) as it passes through their network.

It’s also visible at a number of destinations. The most useful vantage point is
the DNS resolver but traffic is also visible at the authoritative server and,
often, at the other servers the recursive resolver consults too:

> This information can be visible to a 3rd party eavesdropping on the
> communication between a client and a recursive resolver, or even between a
> recursive resolver and an authoritative server. As this information is sent to
> each DNS server, DNS operators can also see clients’ information.


SECURING DNS

There are a lot of schemes afoot to deal with DNS’s privacy issues but most
solutions only tackle a part of the problem and some require the kind of
retooling that could make adoption slow.

 * DNS Query Name Minimisation reduces the amount of information that recursive
   resolvers share with some DNS servers. Snooping at or between the resolver,
   ISP or authoritative server is still possible though.
 * DNS-over-TLS and DNS-over-HTTPS require retooling of existing systems to
   encrypt DNS traffic and prevent snooping on-the-wire. They solve that problem
   at a cost but do nothing to prevent traffic being monitored at the resolver
   or other destinations.
 * Recursive resolvers built for privacy, like 1.1.1.1, tackle the resolver
   problem by promising not to monitor you or keep logs of your activity hanging
   around. It’s nice, but privacy and security requires stronger underpinnings
   than assurances of “you can trust us”.

Enter ODNS.


OBLIVIOUS DNS

Oblivious DNS attempts to tackle spying on-the-wire and snooping at the
resolver, or other destinations, without significant retooling.

Your computer still asks the question “what’s the IP address
for www.example.org?” but this time it’s sent to a local ODNS resolver on your
computer.

That local resolver creates a session key, encrypts the domain with it and then
adds .odns to the end, giving you a completely unrecognisable domain name,
like 9fab9405429045fe5.odns.

The session key is then itself encrypted using a public key provided by an the
authoritative server for the .odns TLD (Top-Level Domain). Anyone can encrypt
something with the public key but only the authoritative server can read it
(you’ll see why in a few paragraphs).

The encrypted session key is added to the DNS query and it’s sent on to a normal
recursive resolver, such as the one operated by your ISP.

Snooping between you and the resolver, or at the resolver itself, is foiled
because a voyeur can identify who’s making a request but not what the request is
for, since the domain name is encrypted before leaving your computer.

Just as it would with any other domain, the resolver then identifies the
authoritative server for 9fab9405429045fe5.odns and asks it for the
corresponding IP address.

On receiving that request the specially equipped authoritative server uses its
private key to decrypt the session key, and then uses the session key to
decrypt 9fab9405429045fe5.odns, revealing www.example.org.

The authoritative server then acts like a recursive resolver: consulting
the server that knows about  .org addresses, which passes it on to the server
that knows about .example.org addresses, which passes it on to the authoritative
server for www.example.org, which provides the IP address.

The IP address is then passed back down the line to your computer.

Spying on-the-wire during this phase, or at any of those destinations, is foiled
because, although a voyeur can now see what domain the requests are for, they
can’t see who made them since all the requests appear to start at
the .odns server rather than your computer.

Right now ODNS is only a prototype and according to the research team there’s
work to be done:

> …we have some future work to continue in this direction. We have implemented a
> prototype of ODNS to evaluate its feasibility and to measure its performance
> overhead in comparison to current DNS performance.

This puts it a way behind some other DNS privacy solutions but, as I said at the
beginning, solutions that require existing systems to change have a way of
rolling out really, really slowly.

ODNS’s ability to work with DNS as it is, rather than as we wish it to be, could
give it head start, even though it’s starting from behind.




 * Follow @NakedSecurity on Twitter for the latest computer security news.

 * Follow @NakedSecurity on Instagram for exclusive pics, gifs, vids and LOLs!


FREE TOOLS

SOPHOS FIREWALL HOME EDITION

Boost your home network security.

SOPHOS SCAN & CLEAN

Free second-opinion scanner for PCs.

SOPHOS CLOUD OPTIX

Monitor 25 cloud assets for free.


POST NAVIGATION

Previous: How to check if your Facebook data was shared with Cambridge Analytica
Next: Congress grills Zuckerberg, day one: How does this online stuff work?


15 COMMENTS ON “HOW ODNS KEEPS YOUR BROWSING HABITS SECRET”

 1. Anonymous says:
    April 10, 2018 at 6:07 pm
    
    Does the ODNS server not know who is asking for the domain name to be
    resolved? If it does, then it’s just another case of “you can trust us.”
    
    8
    
    0
    i
    
    Rate This
    
    
    
    Reply
    * Paul Ducklin says:
      April 10, 2018 at 11:12 pm
      
      Apologies if my question below repeats yours…I must have been typing mine
      in while yours was being approved :-)
      
      2
      
      0
      i
      
      Rate This
      
      
      
      Reply
      
    * Mark Stockley says:
      April 11, 2018 at 11:46 am
      
      As far as the ODNS server is concerned all of the requests start at the
      resolver so an attacker on the ODNS server can see what domains are being
      requested but not by whom.
      
      There is a possible exception to this. The EDNS0 extension to DNS can be
      used to pass the client subnet on to authoritative servers (the content
      written about ODNS also mentions client IP addresses being passed along in
      this way, not just subnets, but we’re at the limits of my DNS protocol
      knowledge so I can’t confirm this).
      
      This is how IP information sometimes ends up at the authoritative server
      and why the resolver, which always has the full IP of the client, is a
      better place to observe traffic.
      
      If EDNS0 is used in that way then it’s possible that some, possibly all,
      of a client’s IP will be visible at the ODNS server. I have written to the
      researchers to clarify this point, and to see if the client’s local ODNS
      resolver has a role to play here.
      
      Thanks for asking and watch here for updates…
      
      5
      
      0
      i
      
      Rate This
      
      
      
      Reply
      * Mark Stockley says:
        April 23, 2018 at 4:18 pm
        
        The researchers responded to say that the ODNS stub resolver that issues
        the DNS request does not include the client’s subnet (no EDNS0 Client
        Subnet option) in the DNS query.
        
        The only other time that a client’s subnet could be inserted into a DNS
        query is at the recursive resolver. According to the researchers it’s
        still unclear how common it is for recursive resolvers to do this and
        how many even support it, but they are trying to measure it.
        
        They recommend that clients should use a recursive resolver that does
        not add a client subnet and hope that their research will shed light on
        how many open recursive resolvers actually do this.
        
        1
        
        0
        i
        
        Rate This
        
        
        
        Reply
        
      
    
 2. Cvnk says:
    April 10, 2018 at 6:11 pm
    
    Couldn’t a snoop see the IP addresses returned since they don’t appear to be
    encrypted? Or are they?
    
    Granted, a single IP address could be associated with any number of domains
    but it could still be revealing, no?
    
    6
    
    0
    i
    
    Rate This
    
    
    
    Reply
    * Hansi says:
      April 11, 2018 at 12:58 pm
      
      The IP address you connect to is visible to your ISP anyway. You’d need
      VPN to avoid that.
      
      2
      
      0
      i
      
      Rate This
      
      
      
      Reply
      * Mark Stockley says:
        April 11, 2018 at 2:11 pm
        
        The ISP knows that it asked an authoritative server for .odns and which
        IP address is associated with it.
        
        A snoop at the ISP could look for other requests from people not using
        ODNS and match their DNS lookups to IPs returned with ODNS. That would
        probably work well for popular sites where there’s a one-to-one mapping
        of IP to domain but because of name-based virtual hosting one IP can
        host thousands of different websites on different domains, so it’s
        probably much less effective for smaller sites.
        
        Using a VPN just turns your VPN provider into your ISP effectively – you
        share everything with them instead.
        
        3
        
        0
        i
        
        Rate This
        
        
        
        Reply
        
      
    
 3. Paul Ducklin says:
    April 10, 2018 at 6:22 pm
    
    Does ODNS aim to solve the assurances of “you can trust us” problem too?
    
    Does the ONDS network use a Tor-like random-routing process to prevent the
    ODNS proxy itself from knowing where the request originated, or does/could
    each ODNS server end up with a list mapping “who asked” to “what they asked
    for”?
    
    4
    
    0
    i
    
    Rate This
    
    
    
    Reply
    * Mark Stockley says:
      April 11, 2018 at 11:48 am
      
      Good question, and one that was at the back of my mind writing this. The
      written material on ODNS was ambiguous on this point so I wrote to the
      researchers to ask – see my answer to the first comment.
      
      3
      
      0
      i
      
      Rate This
      
      
      
      Reply
      
    
 4. boredsysadm (@boredsysadm) says:
    April 10, 2018 at 6:37 pm
    
    What About HTTPS’s SNI issue. Does ODNS fixes that as well?
    
    1
    
    0
    i
    
    Rate This
    
    
    
    Reply
    * Paul Ducklin says:
      April 10, 2018 at 7:11 pm
      
      To explain, that’s where the setup part of an HTTPS connection has to tell
      the web server it’s visiting, up front and unencrypted, which domain name
      it intends to access. (Many servers host many different virtual websites,
      all with different names, at the same place, so the server needs to know
      which HTTPS certificate to send back to start te encryption process. Thus
      the website name, but not the whole URL, leaks out in the clear first.)
      
      I can’t see how ODNS could deal with that issue, because it’s [a] a
      different protocol [b] at a different time [c] and doesn’t even need a DNS
      query first – the HTTPS connection setup could be directed at an IP
      number, given that the Server Name Indication (SNI) specifies the wanted
      name.
      
      4
      
      0
      i
      
      Rate This
      
      
      
      Reply
      
    * adamwinn says:
      April 11, 2018 at 2:19 am
      
      TLS 1.3 addresses SNI.
      
      2
      
      0
      i
      
      Rate This
      
      
      
      Reply
      
    
 5. Adam says:
    April 11, 2018 at 2:18 am
    
    ODNS is a common acronym for OpenDNS (which uses dnscrypt). Gonna be
    confusing having two different ODNS out there.
    
    2
    
    0
    i
    
    Rate This
    
    
    
    Reply
    * Mark Stockley says:
      April 11, 2018 at 11:52 am
      
      The .odns TLD isn’t yet officially recognised, as far as I know, and if
      this gets close to production I imagine OpenDNS’s lawyers will be quite
      keen to raise the same point you’re making 🙂
      
      3
      
      0
      i
      
      Rate This
      
      
      
      Reply
      
    
 6. Dick says:
    April 24, 2019 at 6:01 pm
    
    Will “one IP can host thousands of websites” still be true once we’ve all
    migrated to IPv6?
    
    0
    
    0
    i
    
    Rate This
    
    
    
    Reply
    


WHAT DO YOU THINK? CANCEL REPLY

Comment *

Name

Email

Website





Δ




RECOMMENDED READS

Sep29
by Paul Ducklin
0


S3 EP102: HOW TO AVOID A DATA BREACH [AUDIO + TRANSCRIPT]

Sep08
by Paul Ducklin
2


S3 EP99: TIKTOK “ATTACK” – WAS THERE A DATA BREACH, OR NOT? [AUDIO + TEXT]

Sep19
by Paul Ducklin
4


LASTPASS SOURCE CODE BREACH – INCIDENT RESPONSE REPORT RELEASED

 * About Naked Security
 * About Sophos
 * Send us a tip
 * Cookies
 * Privacy
 * Legal

 * Intercept X
 * Intercept X for Server
 * Intercept X for Mobile

 * XG Firewall
 * Sophos Email
 * Sophos Wireless

 * Managed Threat Response
 * Cloud Optix
 * Phish Threat

 * 
 * 
 * 
 * 
 * 

© 1997 - 2022 Sophos Ltd. All rights reserved. Powered by WordPress VIP