[tor-bugs] #5548 [Tor Bridge]: Write a proposal for using a front-end proxy like apache for bridge scanning resistance

[Tor Bug Tracker & Wiki]

#5548: Write a proposal for using a front-end proxy like apache for bridge
scanning resistance
------------------------+---------------------------------------------------
 Reporter:  karsten     |          Owner:  nickm                  
     Type:  project     |         Status:  new                    
 Priority:  normal      |      Milestone:  Sponsor F: July 1, 2012
Component:  Tor Bridge  |        Version:                         
 Keywords:              |         Parent:                         
   Points:              |   Actualpoints:                         
------------------------+---------------------------------------------------

Comment(by asn):

 Some more questions:

 a) Can this scheme work without changing the tor codebase at all?

 It seems that with Shane's scheme, the server-side Apache can work
 independently from the tor bridge (if auth succeeds, port is forwarded. if
 auth fails, apache logs, tor never learns about the client.).

 Can we also do the same for the client-side by letting a specialised
 external program connect to the bridge, do the auth, see if it succeeds or
 fails, and forward ports accordingly?

 Also, do we actually want to do this out of the tor codebase? It will be a
 cleaner implementation for sure, but we might also lose the benefits of
 tor knowing about failed attempts etc. (for example, maybe Apache should
 report to tor that ''client at IP:PORT failed at auth. I presented him
 webpage X for camouflage'')

 b) What happens if auth fails in this scheme? Do we simply give the prober
 an Apache "It works" page for index.html, and 404 for everything else? Do
 we randomly generate webpages by using something similar to bananaphone?
 Do we randomly (using the GET request as a seed) select an Alexa 1million
 site (or a twitter feed) and proxy it? Or do we do something else?

 I would say that the first solution seems like a good beginning step; it's
 trivial to implement (just let apache do its job) and it doesn't expose
 too many fingerprints. On the other hand, the other solutions, while more
 sophisticated and advanced, have lots of technical problems and are harder
 to implement.

 BTW, b) might be out of scope for this ticket, but it's still useful to
 think about.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5548#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online