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

[Paul Syverson <syverson@itd.nrl.navy.mil>]

On Wed, Jul 21, 2004 at 04:00:53PM -0400, Roger Dingledine wrote:
> 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'm also thinking that a corporation would be happy to have an OR on
their corporate firewall serving as an intermediate node connected to
registered ORs and providing access to the OR network, but might not
want to be an OSP ;>) for just anybody.

So far we're a beta network and this configuration probably has not
occurred. But it's definitely one we should plan for.

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

Delaying implementation of this until the need is less abstract makes
perfect sense to em.

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

Right. This is why I spoke more abstractly about resource depletion.
As long as clients and nodes are fairly distinct, it is easy to have
separate mechanisms and responses to cope with DoS from each of them.
As that line blurs, so does the distinction between insider and outsider
attacks. I don't think any of us understands the implications of this
yet. Anyway I did not mean to imply that we should not do this. I just
want to have a discussion so that we will have worked out what we need
to cope with and how by the time that we need to do so.