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
