[tor-dev] Proposal 211: Internal Mapaddress for Tor Configuration Testing

[Mike Perry]

Thus spake Nick Mathewson (nickm at alum.mit.edu):

> On Mon, Oct 15, 2012 at 4:38 PM, Mike Perry <mikeperry at torproject.org> wrote:
> [...]
> >> What does that protect against?  My first thought is that you're
> >> trying to prevent the case where a malicious local DNS server maps
> >> "selftest.torproject.org" to some IP address in their control, and
> >> then just runs a server at that IP address to say "yes I'm Tor".  But
> >> that doesn't make sense, since you could just make one of those that
> >> said "yes I'm Tor" no matter what you say for the nonce.
> >
> > *Headdesk*. Doh. Yes, the DNS test needs to be given a transform of the
> > nonce (SHA1? SHA1+salt?), and needs to spit the original back out again
> > in the response for validation by the client.
> >
> > But yes, that is exactly what we're trying to protect against.
> 
> Okay.  So to write up crypto/protocols that work, you actually need to
> start by writing up the security features you actually get from your
> protocol: what the client needs to do, what the attacker might do, and
> so forth.
> 
> Let's say we want the property where a client who has connected via an
> IP address learns something that the client can use to conclude that
> it is talking to the same Tor when it connects by hostname.  Let's say
> that the attacker *can* cause the client to make connections to
> Tor-by-IP or Tor-by-hostname, but can't learn or interfere with the
> content.  Let's say that the attacker can't make his own connections
> both to Tor-by-IP or Tor-by-hostname.  Let's say that the attacker
> _can_ impersonate Tor-by-hostname.
> 
> Is that about right?

Yeah.

However, I am beginning to wonder if the nonce complexity is worth it at
all. It sure is hard to get right, and check.tp.o already does *not*
tell you if your DNS is configured properly today.

This is making me think we should table this multi-request nonce idea
and instead just focus on the simple case: Replacing check with a local
IP-only test.

We can then consider bringing the nonce+DNS test back later on, if we
decide we do actually want the DNS test.

> >> >  The list of pending nonces should not be allowed to grow beyond 10
> >> >  entries.
> >>
> >> This means that any webpage could flush out the list of pending
> >> nonces.  Does that matter?
> >
> > Hrmm. Maybe. I was balancing this with other issues:
> >
> > 1. Without any limit, web pages could oom the tor client.
> >
> > 2. A website that managed to access this service could track a user
> > for a long period of time by getting a pile of nonces to use, all known
> > to be bound to that user.
> >
> > We could rely only on a shorter default timeout instead, though.
> 
> Or design something that uses less server-side memory.
> 
> Like, instead of remembering every N, you could construct each N as
> "r, HMAC(X,r)" where r is a one-off random value and X is an HMAC key
> Tor creates at startup.  Then you could recognize all of the N that
> you generated without having to remember more than a single HMAC key.
> 
> (This doesn't solve the actual protocol problem, but it does show how
> you can avoid storage issues.)

But then, wouldn't we need to have a way to handle expiry for r, or you
could be tracked by simple replay? That's the main reason I opted
against making the nonce generated by a function. I suppose an HMAC
construction would allow us encode a timestamp as part of that r,
though...

> >> >  Because there are many exceptions and circumvention techniques
> >> >  to the same-origin policy, we have also opted for strict controls
> >> >  on dns-nonce lifetimes and usage, as well as validation of the Host
> >> >  header and SOCKS4A request hostnames.
> >>
> >> Of course, this all comes down to the fact that we're using http.  Can
> >> we spell out why we need HTTP for this?
> >
> > See https://trac.torproject.org/projects/tor/ticket/6546#comment:18 and
> > the following comment.
> >
> > Do you want that in the proposal, you mean?
> 
> Yeah, and also we should discuss it.
> 
> The argument as I understand it is that your browser's TCP sockets API
> is not guaranteed to use the same proxies as the browser uses for http
> URL access.
> 
> (Of course, that goes the other way: if we were trying this for
> something like a chat client, there would be no guarantee that the URL
> access would use the same proxies as are used for regular chat.)
> 
> I don't think, though, that "Are my socks proxies configured right?"
> is the primary use for this tool.  Any application we write had
> *better* get the socks proxies right, and verify that they're right,
> and audit to make sure they're not bypassable, etc etc.  The "is my
> Tor running" and "can my Tor build circuits" questions seem much more
> useful.

Should we forget the nonce+DNS stuff then, and just scale this back to a
simpler local-IP HTTP status port?

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20121015/775036ce/attachment-0001.pgp>