On Tue, Jan 31, 2012 at 2:57 PM, Nick Mathewson <[email protected]> wrote: > On Tue, Jan 31, 2012 at 3:35 PM, Roger Dingledine <[email protected]> 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 <[email protected]> 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 > [email protected] > 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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
