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

[Nick Mathewson]

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?

Incidentally: No new SHA1 in Tor!

>> Also, how useful is the followup DNS check?  If it's checking that DNS
>> leaks aren't happening... You're going to need torbrowser or something
>> of equivalent complexity for this to work at all; isn't it easier then
>> for torbrowser to make sure that it  set up SOCKS ?
>
> Hrmm. I was under the impression most apps have url fetch capabilities.
> Pidgin appears to. Thunderbird definitely does. Both have XML deps
> already (as does any XMPP chat app).
>
> But yes, the plan was for this to be used by custom software we wrote.

So, why can't this custom software just check the SOCKS settings?

(Sure, there might be a SOCKS bypass.  But there might also be a SOCKS
bypass anywhere in the application that doesn't use the same path to
the network as the URL fetch code.)

>> >  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 n 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.)

[...]
>> If that's the issue, I'd strongly suggest that instead of going with a
>> more complex data format, we could add a layer of encoding over the
>> json, or use an even simpler format.
>
> I wanted to avoid requiring our clients write parsers, and everything I
> could think of already parses XML.
>
> But if you think hand-parsing is less dangerous than relying on an XML
> lib, we can do line-based key=value instead.

Not all hand-parsing is less dangerous/bloaty than XML, but some sure is.

>> >  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.



-- 
Nick