Thus spake Nick Mathewson (nickm@xxxxxxxxxxxx): > On Mon, Oct 15, 2012 at 4:38 PM, Mike Perry <mikeperry@xxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev