[tor-dev] Proposal 211: Internal Mapaddress for Tor Configuration Testing
mikeperry at torproject.org
Mon Oct 15 21:53:56 UTC 2012
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?
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
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,
> >> > 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
Should we forget the nonce+DNS stuff then, and just scale this back to a
simpler local-IP HTTP status port?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the tor-dev