Re: Bridge scanning resistance

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Sun, 22 Mar 2009 14:21:49 -0400 Roger Dingledine <arma@xxxxxxx>
wrote:
>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.
>
     Judging from your final sentence and your earlier comments, I'd say the
project should be broken up into several smaller pieces.  If proposals come
in for each of the pieces, it might perhaps then be appropriate to have the
various students working on those pieces consult with each other as needed,
working on the overall project as a team, each student with his/her own
piece of it.  Doing it this way would increase the chances of success within
the summer time frame for all of the students involved.  Alternatively,
perhaps some of the pieces could be spun off as completely independent
projects, while others might be grouped into one or more smaller teams.
     Perhaps you and Nick could take a couple of hours to look at the project
in question to see how it might be better specified.  There's no real benefit
in spending the money without getting end results or in leaving a student
overwhelmed by a badly specified project leading to failure.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************