Opened 4 years ago

Closed 4 years ago

#8673 closed task (not a bug)

Host a flashproxy-reg-http listener on s3.amazonaws.com

Reported by: proper Owned by: dcf
Priority: Medium Milestone:
Component: Archived/Flashproxy Version:
Severity: Keywords:
Cc: proper Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Psiphon (circumvention tool) uses amazon s3 to distribute it's software in censored areas. It's not censored according to greatfire.org. Seems like the censor don't dare to ban that domain.

My suggestion is, as alternative to

https://tor-facilitator.bamsoftware.com/reg/0labtDob545HeKpLZ8LqGeOi-OK7HXoQvfQzj0P2pjh1NrCKNDaPe91zo

Host also

https://s3.amazonaws.com/reg/0labtDob545HeKpLZ8LqGeOi-OK7HXoQvfQzj0P2pjh1NrCKNDaPe91zo

Users can probable use it and won't need to find out their external IP, don't need some service to retrieve that url and don't need to mail it to someone.

Just an idea. It's up to you to decide if that idea is worth the cost/work, depending on how likely it is, that s3.amazonaws.com gets banned and on how much this improves usability.

I've also read that (some) censors don't dare to block gmail/google, but throttle it instead. My hypothesis is, that google could be interested in having their users using their services faster (so they can serve more ads). Therefore I think it's worth asking google if they could consider hosting a flashproxy-reg-url on google.com. That same goes for other pages, the censor does not dare to ban/throttle or only dares to throttle.

Child Tickets

Change History (4)

comment:1 Changed 4 years ago by dcf

Thank you for your suggestion. I think perhaps the purpose of flashproxy-reg-url is not clear. The domain that the URL points to is not meant to be unblockable. If it was, then we would just put the facilitator there and not have to do any fancy rendezvous. Actually, we would just put a Tor bridge there and not deal with flash proxies at all.

The idea, rather, is that it's pretty easy to get someone on the "free Internet" to retrieve a URL for you. (Where "someone" may be an automated web service.) We hypothesize that it's hard to block all the services that will do that for you, or even a lot of them, and even if blocked there is collateral damage. (Think of an online translation service for example.)

However it is interesting that Psiphon apparently uses S3 with success. One of the potential rendezvous methods we discussed in the flash proxy service used such online storage servers, and there was even a prototype implementation: https://gitweb.torproject.org/flashproxy.git/shortlog/refs/heads/storage. I think it doesn't offer anything special for URL registrations, though. I could be wrong or misunderstand your request.

Even if you host a flashproxy-reg-url listener on S3, the user still needs to know their external address. That's what all that base64 in the URL encodes.

Of course, anyone could host their own web server on S3, that just reflects requests to the main facilitator web server, and it would have the same effect.

comment:2 in reply to:  1 ; Changed 4 years ago by proper

Replying to dcf:

I think perhaps the purpose of flashproxy-reg-url is not clear. The domain that the URL points to is not meant to be unblockable.

I know. But, but would ever better if it was "unblockable" (by censor's own policy)? I mean, it would be easier for the user.

However it is interesting that Psiphon apparently uses S3 with success.

One of the potential rendezvous methods we discussed in the flash proxy service used such online storage servers, and there was even a prototype implementation:

Ok, so my idea is not new.

I think it doesn't offer anything special for URL registrations, though. I could be wrong or misunderstand your request.

As far I understand s3, it's just a server you can rent. Once someone connects to that domain, you know they're interested to get a flashproxy (you see the IP, because you rent the server). So users don't have to find out their external IP.

Even if you host a flashproxy-reg-url listener on S3, the user still needs to know their external address. That's what all that base64 in the URL encodes.

My idea was, if users can access s3, you could get the IP of any user who connects, because it's your rented server.

Of course, anyone could host their own web server on S3, that just reflects requests to the main facilitator web server, and it would have the same effect.

Yes. I think it would be a bit simpler, since this doesn't require to tell people "find a service like w3 validator who checks the url".

comment:3 in reply to:  2 Changed 4 years ago by dcf

Summary: host a flashproxy-reg-url on s3.amazonaws.comHost a flashproxy-reg-http listener on s3.amazonaws.com

Replying to proper:

Replying to dcf:

I think it doesn't offer anything special for URL registrations, though. I could be wrong or misunderstand your request.

As far I understand s3, it's just a server you can rent. Once someone connects to that domain, you know they're interested to get a flashproxy (you see the IP, because you rent the server). So users don't have to find out their external IP.

I see. You should look at flashproxy-reg-http, which already does what you want, not flashproxy-reg-url. flashproxy-reg-http uses a simple HTTP POST, not any fancy encoded URL. And it gets the client address from the TCP source address, as you suggest. flashproxy-reg-http and flashproxy-reg-url work differently and one isn't a replacement for the other.

Of course, flashproxy-reg-http is trivially blockable, just by blocking the listening web server. Therefore it doesn't count as a "real" rendezvous method. We include it just for censors who aren't paying attention.

You can use flashproxy-reg-http on a different web server like this:

./flashproxy-reg-http -f http://s3.amazon.com/blahblah

Someone would need to host a listener there that would forward registrations to the real facilitator. I'm not that interested in doing that, because flashproxy-reg-http remains easy to block, and whatever URL we use, the censor can just get from the source code.

comment:4 Changed 4 years ago by dcf

Resolution: not a bug
Status: newclosed

I'm closing this because it is more about flashproxy-reg-http than flashproxy-reg-url, and because I'm not planning to install a listener on Amazon. flashproxy-reg-http fails against a minimally capable adversary, and looking for hosts on which to install rendezvous listeners puts us right back in the bridge distribution game.

Anybody is of course welcome to install their own flashproxy-reg-http listener CGI on a host they think is unlikely to be censored, and forward the registrations to the facilitator.

Note: See TracTickets for help on using tickets.