Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] free SSL certs from the EFF



"Edward Ned Harvey (blu)" <blu at nedharvey.com> writes:

>> From: Derek Atkins [mailto:warlord at MIT.EDU]
>> 
>> 1) the root zone is signed with a known key, and
>> 2) most of the TLDs are signed (in particular .com is definitely signed)
>
> When you first connected to the network, DHCP told you to use some DNS
> server.  When firefox, or anything else in your OS queries that DNS
> server to resolve some name, you do not receive the response from the
> TLD.  You just get a response to your query, and not all the
> subsequent queries that were necessary in order to resolve your query.
> Better yet, your OS itself caches the response, so once again, FF
> makes some query, and doesn't get a signed response.

And you've already violated rule #1: You must trust your resolver.  In
general this implies running your own DNSsec-aware recursive resolver on
your client (or on some other trusted host).  It does mean that, in
general, you should not blindly trust the DNS servers provided by DHCP.

In my experience you fix this by running your own local caching name
server on your laptop.  That service can go off to the DNS server
provided by DHCP, or it can go out to the servers on the net.  Part of
the design of DNSsec is that it can be proxied.

> This may be a shortcoming of implementation, but if so, that doesn't
> make it any less relevant, because neither your OS name caching
> daemon, nor the upstream caching server are doing "the right thing"
> and the world is a *long* way off from having all the dumb Linksys
> routers upgraded to the point of DNS security being effectively
> universally deployed.

I'm not sure what you mean by "your OS name caching daemon ... are [not]
doing the right thing"?

> These are yet another two possible solutions to the problem - 
>
> Don't use caching DNS servers; every client must query the TLD
> directly and do all its own resolving.  Or, globally adopt a new
> standard where the caching DNS server gives your client not only the
> response you requested, but the entire signed chain...  But these
> solutions very definitely do not exist as globally universally
> standard deployed solutions today.
>
> Today, FF queries for www.google.com, and the query is handled by
> whatever DNS server was doled out to the client via DHCP, and the DNS
> server response is only going to be the final result of the query,
> which could have been mangled in transit.

There are two other ways to handle this:

1) Run a local caching nameserver on your system, or
2) Run a DNSsec-aware resolver on your system which uses the local DNS
   proxy as its cache.

The only real difference between my #1 and #2 is where the cache is
stored.  The resolver still needs to query for everything up to the
root, which it can receive from the cache.  The cache doesn't need to be
trusted if you reverify every time, so what you get from #1 is the
ability to trust the cached data.

I'll note that Firefox could implement #2.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org