[or-cvs] make connection_tls_finish_handshake() more plausible.

[Roger Dingledine]

[ For context, the cvs commit message is here:
http://archives.seul.org/or/cvs/Jul-2004/msg00087.html ]

On Tue, Jul 20, 2004 at 11:32:12PM -0400, Paul Syverson wrote:
> If we're going to accept connections from unknown routers, then
> there should probably be a policy choice setting for that, possibly
> a bound on how many rather than just a yes/no. Yes? No?

Is accepting connections from unknown routers a security risk? We still
choose paths the same way we did before (that is, from the list of
verified routers in one of the directories).

The only changes here are:

- OPs can now provide an SSL certificate (signed by some identity key)
when they're doing the TLS handshake with you, and you won't freak out
and hang up on them.
- If somebody happens to send you an extend cell that asks you to extend
to this identity key, then you'll notice you're already connected,
so you won't have to launch a new connection.

So I think this particular change is safe enough.

Now, some time down the road we might commit a change that makes people
build circuits through (or starting at, or ending at) a router which isn't
in the directory, or one that is but hasn't been verified by the dirserver
operators. I could imagine doing that if you have a private enclave and
want to get encryption and per-cell-padding to it. I could also imagine
doing it if you don't mind the Sybil threat, relative to the speed
advantage you get (e.g. if the core Tor network is highly congested).

I expect that change to generate lots of discussion. :) My plan for now
is for Nick and me to play around and get a feel for what would need to
change, and how flexible we can make the code-base in the meantime. I
will write up a list of changes and their effects, so we'll have something
from which to base our discussions.

Thanks,
--Roger