Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#5548 closed project (implemented)

Write a proposal for using a front-end proxy like apache for bridge scanning resistance

Reported by: karsten Owned by: nickm
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: SponsorF20120701 tor-bridge
Cc: asn, ioerror Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Item 18 from org/sponsors/SponsorF/Year2 is: "write a proposal for at what level of abstraction the "Tor does an SSL handshake with a real apache, posts a password over http to the server, and then gets passed to the real Tor relay" design should take place. Should the Tor client simply talk to a local proxy which does this dance, a la pluggable transports? Should Tor use a libevent2 filter? Something else?"

Nick and I talked about this deliverable last December. Nick thought that writing a proposal is doable. He didn't have a specific design in mind, but he didn't see any obstacles to writing one. He said we should definitely be working on this stuff earlier, not later. I said I'd assign the project ticket to Nick and to the July milestone, which I'm doing now.

I'm also cc'ing asn and ioerror who both expressed interest in working on this deliverable.

Child Tickets

Change History (12)

comment:1 Changed 8 years ago by arma

Whoever works on this should be aware of proposals 187, 189, 190, 191 too.

I don't have an opinion yet on which direction we'll want to go, or even if they're compatible or incompatible. I worry that these proposals don't actually provide a good way to act like an apache if the auth fails.

comment:2 in reply to:  1 ; Changed 8 years ago by asn

Replying to arma:

Whoever works on this should be aware of proposals 187, 189, 190, 191 too.

I don't have an opinion yet on which direction we'll want to go, or even if they're compatible or incompatible. I worry that these proposals don't actually provide a good way to act like an apache if the auth fails.

True, I'm not sure if there is a truly good way to act like an Apache if the authentication fails, when "Tor first; Apache if auth fails" is used.

In https://lists.torproject.org/pipermail/tor-dev/2011-November/003073.html, I suggested to have an Apache binding on localhost, and if the bridge receives a bad AUTHORIZE cell, switch the bridge to act as a tunnel between the bad client and Apache. (also, we can use IRC, SMTP, etc. servers, in place of Apache here)

Still, I'm not sure if that's a good way.

comment:3 in reply to:  2 Changed 8 years ago by arma

Replying to asn:

True, I'm not sure if there is a truly good way to act like an Apache if the authentication fails, when "Tor first; Apache if auth fails" is used.

In any case, this ticket is about doing it the way that will more clearly work: have a real Apache and if it gets the right password dance, it proxies the traffic into Tor.

comment:4 Changed 8 years ago by arma

Summary: Write a proposal for password-protected bridgesWrite a proposal for using a front-end proxy like apache for bridge scanning resistance

comment:5 Changed 8 years ago by karsten

Adding a few notes from the #tor-dev meeting yesterday:

  • Nick is going to write a proposal for using a front-end proxy like Apache for bridge scanning resistance. Roger is most interested in the question "what changes on the Tor side will make it easier for people who want to stick a $foo in front of Tor to make Tor look like $foo unless you authenticate right;" where Apache is the first $foo. George added that the other question is "what changes on the $foo side will be needed."
  • George asked how the Apache->Tor transition on correct password is going to happen. Roger mentioned a master's student at UT who wrote an Apache module to proxypass Tor traffic if you GET the right URL first.
  • Nick says that July 1 is fine as a milestone if the deliverable is just "a proposal with some discussion." We probably don't need substeps for this deliverable.
  • Roger says that Dan Boneh is excited to think about front-end proxies for bridge scanning resistance from a theory level. So once we have something we should involve him.

comment:6 in reply to:  5 ; Changed 8 years ago by arma

Replying to karsten:

  • George asked how the Apache->Tor transition on correct password is going to happen. Roger mentioned a master's student at UT who wrote an Apache module to proxypass Tor traffic if you GET the right URL first.

His name is Shane Pope. You can read about him at point 'j' on https://www.torproject.org/getinvolved/volunteer.html.en#OtherCoding

comment:7 in reply to:  6 Changed 8 years ago 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.

comment:8 Changed 7 years ago by nickm

Wrote an initial stream-of-consciousness document in the branch "ticket-5548" in my torspec repository. It needs more revision and thought before I give it a proposal number and ask for general review: right now it is fairly stupid.

comment:9 Changed 7 years ago by nickm

Resolution: implemented
Status: newclosed

Finished up my draft as proposal #203; let's discuss it!

comment:10 Changed 7 years ago by karsten

Keywords: SponsorF20120701 added
Milestone: Sponsor F: July 1, 2012

Switching from using milestones to keywords for sponsor deliverables. See #6365 for details.

comment:11 Changed 7 years ago by nickm

Keywords: tor-bridge added

comment:12 Changed 7 years ago by nickm

Component: Tor BridgeTor
Note: See TracTickets for help on using tickets.