[tor-dev] DNS/DNSSEC resolving in Tor (PoC implementation)

[Watson Ladd]

On Tue, Jan 31, 2012 at 2:57 PM, Nick Mathewson <nickm at alum.mit.edu> wrote:
> On Tue, Jan 31, 2012 at 3:35 PM, Roger Dingledine <arma at mit.edu> wrote:
>> On Tue, Jan 31, 2012 at 10:04:21AM -0500, Nick Mathewson wrote:
>>> On Mon, Jan 30, 2012 at 1:34 AM, Roger Dingledine <arma at mit.edu> wrote:
>>> > So it looks like Tor would get two new libraries linked in, and exit
>>> > relays would inherit whatever security/stability issues libunbound has
>>> > since clients can basically hand them packets that they have to parse
>>> > and deal with.
>>>
>>> FWIW, I'm okay thinking about adding new library dependencies so long
>>> as the libraries are portable enough; libunbound and ldns have a
>>> reasonably good reputation.  (And our friends at NLnet labs probably
>>> wouldn't mind another bunch of users.)
>>>
>>> I believe that as we add dnssec support, we are going to cross the
>>> threshold of stuff we'd be willing to clone ourselves, since writing
>>> our own dnssec code would be absurd.
>>
>> I totally agree that writing our own dnssec code would be absurd.
>>
>> But I'm confused here about why we're adding dns support to Tor itself.
>> Are we doing it to be able to proxy more requests from applications to
>> dns servers? Or are we doing it because the Tor client itself wants to
>> be able to learn the answers to dnssec questions?
>>
>> If it's the former, then we should try as much as we can to *not* learn
>> the details of the protocol. After all, Tor doesn't have an ssh protocol
>> parser or validator, but it can proxy ssh traffic just fine.
>
> I guess it depends on what you think should happen for SOCKS+hostname
> connections.
>
> One possibility is this:
>
> Browser -> Tor Client: "SOCKS5: Connect to www.example.com,port 80"
> Tor client -> Tor net -> Exit node: "BEGIN+: Connect to
> www.example.com, port 80, and answer the following DNS questions about
> it."
> Exit node -> Tor net-> Tor Client: "CONNECTED+: Connection is open.
> Here's a bunch of DNS replies for you."
> Tor Client -> Browser: "SOCKS5 connection complete."
This would also break things like DNSSEC certificate stapling without
some hackery or standards.
>
> But that would require that Tor recognize DNSSEC traffic.
>
> Another possibility is this:
>
> Browser's resolver -> Tor Client (as DNSPort): "Resolve
> www.example.com, give me an A, and give me DNSSec stuff too."
> Tor Client-> Tor net-> Tor Exit: "Yeah, resolve that stuff."
> Tor Exit -> Tor net -> Tor client: "Here's your answer."
> Tor client -> Browser's resolver: "Here's that A record you wanted,
> and some dnssec stuff."
> Browser -> Tor client: "Okay, now connect there."
> Tor client -> Tor net -> Tor exit: "Connect to <ip address>:80!"
> Exit node -> Tor net-> Tor Client: "CONNECTED: Connection is open."
> Tor Client -> Browser: "SOCKS5 connection complete."
>
> But that would involve an extra round trip that I'd rather save if possible.
We could cross our fingers and be optimistic, opening a connection to
the server queried. Probably a bad idea.
>
> --
> Nick
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin