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

[Roger Dingledine]

On Wed, Jul 21, 2004 at 08:15:16AM -0400, Paul Syverson wrote:
> > 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).
[snip]
> More significantly, with this change (automatic and
> without a policy setting), someone who thinks he is running just an
> intermediate node (accepting only local connections to other ORs or
> relaying between other ORs in the directory) can find himself
> effectively running an entrance node for others.  Maybe he doesn't
> want to do that.

In practice, nobody so far has cared whether they're an entrance node
or not. The only thing that matters is the liability issue from being
an exit node.

I guess running an entrance node can in theory have bad consequences,
because somebody watching Alice thinks she's talking to you.

I can put in an 'AcceptOnlyVerifiedRouters' option, if that would make
you more comfortable. I'm tempted to wait til a verified server operator
asks for it, though, or at least until things stabilize a bit more and
we figure out how things are likely to work in practice. I'll put it on
the low-priority todo list.

(I should point out that we've had no 'intermediate node only' option
so far, and nobody has asked for one. And it benefits the network to
not encourage people to want it. ;) )

And Adam writes:
> It seems to me that it may open a DOS risk, where a client can send
> messages that claim to be starting a SSL session, and then require an
> assymetric amount of work from the router.

Unfortunately, we already have this risk too. You can show up right
now and demand an SSL handshake. You can do this as an OP or an OR.

Our response so far is that if it turns into a problem, we can implement
client puzzles or something before the actual SSL handshake begins.

Thanks,
--Roger