Bridge scanning resistance

[Christopher Davis <chrisd@xxxxxxxxxxx>]

Hello,

I'm thinking of sending in a GSoC proposal for consideration by Tor/EFF
this year. 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.

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. Also, there could be some application to having OR servers
respond to HTTP requests with an informational message, etc.

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.

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.

Are there any other things to think about?

Thanks,
-- 
Christopher Davis
Mangrin Remailer Admin
PGP: 0x0F8DA163