Re: Bridge scanning resistance

[Roger Dingledine <arma@xxxxxxx>]

On Thu, Mar 19, 2009 at 01:00:38AM +0000, Christopher Davis wrote:
> I'm thinking of sending in a GSoC proposal for consideration by Tor/EFF
> this year.

Welcome!

> I see in item #4 on your volunteer project list work involving
> improvement of bridge scanning resistance, and it looks like it could be
> an interesting project.

Yes indeed. It's also a messy project -- rather than knowing what to
build, you need to grapple with a lot of vague security requirements,
along with a lot of potentially contradictory engineering requirements,
and then choose the right balance of "protects well enough against
the important attacks" vs "can be build and deployed without too many
subtleties which induce bugs, and can be maintained afterwards". So
that requires a lot of intuition; it's not a project for a beginner at
this stuff.

> It seems the trick in the bridge-as-webserver design is making it appear
> as normal and boring as possible, while still accommodating bridge
> clients. Clients would have to upload an authentication string to the
> server in order to use it, but the server would have to take care in
> reporting authentication failure, etc, to avoid alerting a scanner to its
> true purpose.

Yep. I haven't looked at TLS lately, and our variant where we do rekeying
inside TLS:
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/130-v2-conn-protocol.txt
but it seems contradictory to both a) authenticate that you're talking
to the right relay, and b) not act funny until you've authenticated, if
we need to demand rekeying (which is pretty odd) before we can see all
the right certs. So there's definitely some design work involved here too.

> Also, there could be some application to having OR servers
> respond to HTTP requests with an informational message, etc.

Check out DirPortFrontPage in the man page.

> Certain aspects of the TLS handshake could also clue in a scanner. Are
> there any things about Tor's current implementation that could be
> improved to make it seem more like a web server? If required, answering
> this question could be one point of research in comparing Tor to
> Apache's mod_ssl or other HTTPS servers.

Yep. My current thought is that you'll never achieve bug-compatibility
with Apache (consider for a moment how good nmap is at distinguishing
OSes based on how they chose to implement TCP), so the only foolproof
plan here is to intercept Tor connections and handle them as Tor, else
pass the connection through to Apache.

Of course, if you're "close enough to Apache", that may be good enough.
Nobody has looked carefully enough to know how much work that would be.

> Another part of the project is to address the specifics of bridge
> authentication. The bridge user has to get a password from us, then they
> would send it when they connect to the bridge. The web application to
> advertise bridges would need to be updated.

Yep. That wouldn't be so bad though -- the web application doesn't much
care what its bridge lines look like. It's really the bridge descriptor
that needs to get updated, so it includes the password that the bridge
expects.

Overall, this looks like one of those high-risk summer projects, where
you might spend your whole time being dismayed at the number of confusing
variables.

--Roger