Subject: Re: [perpass] FW: [IP] Details of how Turkey is intercepting Google Public DNS

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 May 2014 10:25:06 -0400

On Sun, Mar 30, 2014 at 1:35 PM, Christian Huitema <[email-masked]> wrote:
> Could be of interest for this list. An example of Internet infrastructure
> vulnerability exploited by various operators. Mount an intercept attack on
> the DNS protocol, and then use it for censorship or man-in-the-middle
> insertion.
>
> From: Lauren Weinstein <[email-masked]>
> Subject: [ NNSquad ] Details of how Turkey is intercepting Google Public DNS
> Date: March 30, 2014 at 12:45:00 PM EDT
> To: [email-masked]
>
>
> Details of how Turkey is intercepting Google Public DNS
>
> http://j.mp/1lwpwcV  (Bortzmeyer)
>
>    "If you try another well-known DNS resolver, such as OpenDNS,
>     you'll get the same problem: a liar responds instead.  So,
>     someone replies, masquerading as the real Google Public DNS
>     resolver. Is it done by a network equipment on the path, as it is
>     common in China where you get DNS responses even from IP
>     addresses where no name server runs? It seems instead it was a
>     trick with routing: the IAP announced a route to the IP addresses
>     of Google, redirecting the users to an IAP's own impersonation of
>     Google Public DNS, a lying DNS resolver. Many IAP already hijack
>     Google Public DNS in such a way, typically for business reasons
>     (gathering data about the users, spying on them). You can see the
>     routing hijack on erdems' Twitter feed, using Turkish Telecom
>     looking glass: the routes are no normal BGP routes, with a list
>     of AS numbers, they are injected locally, via the IGP (so, you
>     won't see it in remote BGP looking glasses, unless someone in
>     Turkey does the same mistake that Pakistan Telecom did with
>     YouTube in 2008). Test yourself: ... Of course, DNSSEC would
>     solve the problem, if and only if validation were done on the
>     user's local machine, something that most users don't do today."

This isn't an authenticity attack that DNSSEC is designed to protect
against. It is a service attack which DNSSEC does not help against.
All that DNSSEC does is to allow the user to know that they can't get
to Twitter or YouTube. As someone who has recently come back from
Turkey, I can assure you that you don't need DNSSEC to know that you
can't get to YouTube.

DNSSEC was an attempt to use the DNS as the basis for a PKI to
authenticate Internet services. It can be used as a mechanism for
publishing policy about Internet services. It is not a protection
against service attacks.

That does not make DNSSEC a bad security solution, it means that it is
a solution limited to one purpose. Which is actually good.

Here we have a group of users who have decided to use the Google DNS
(or the Comodo DNS service or one of any number of competitors). But
they can't because the packets are being interfered with. To defeat
such attacks it is necessary to ensure that:

* The client can verify that the information it receives comes from
the intended source.

* The communications between the client and server can't be identified
as DNS conversations permitting them to be blocked.

* The services can't be brought down by DoS attacks.

If we want to go the next step and enable the use of censorship
resistant transport (e.g. TOR) then it is also necessary to move up
from DNS to a discovery mechanism that allows responses of the type
'to get to that particular site from where you are now, you need to
use TOR')

Only the second of these is strictly a privacy issue. But if you want
a robust Internet privacy solution then you need a discovery and
naming infrastructure that supports all of them.

-- 
Website: http://hallambaker.com/