to run, deploy the image, connect as ec2-user in the normal way and then:
- modify ~/tor.sh to change the port on which obsproxy listens, if you want
- change the security group to allow ports 9100 and 2189 (or whatever you change 2189 to above) (you may need to restart the instance at this point to apply the security group).
- modify the bandwidth limit in /usr/local/etc/tor/torrc (ie sudo emacs -nw /usr/local/etc/tor/torrc) - currently it's 50 KB/s which i think comes out as around $10-20 a month if it's fully used.
- start with the tor.sh script.
- check tor.log and note your external IP address.
- check external access using something like "telnet xxx.xxx.xxx.xxx 2189" (which generates a screenful of binary on success).
- contact tor-assistants at torproject.org so they can give the bridge location out to someone that needs it.
please post here or email me if there are any issues (a confirmation that you can access the ami would be cool too :o). also, are AWS external IP addresses permanent (if not, may need to use elastic IP + DNS)?
It looks like you left your public key in authorized_keys. I guess it was an honest mistake, but at the very least anyone using this AMI should remove it.
Now, please don't be offended, but this is one of the reasons I prefer instructions or more generally an easy way to replicate a result - which is easier to verify - rather than the built software/AMI/whatever. It's trivial to offer a compromised system and nearly impossible to verify that a system is secure.
On the other hand, tor and obfsproxy work for me using your AMI.
Security groups are applied as soon as you save your changes, no restart is required.
I've never seen an external IP address for an EC2 box change, I don't believe they do. They are typically part of the hostname and it would be strange to have amazon change this at random points in time. Elastic IP is good if you want to change a server a domain points to without having to wait for DNS propagation.
I just confirmed that I can access your AMI in the US East region. Be aware, however, that AMIs are region specific and thus your AMI cannot be found or used in any other region (such as US West).
thanks to the comments, i've created a new ami, ami-2b61b142, which should not have my keys. again, this is in US east.
i will delete the ami described in the post above, please use this one.
this will still have my contact details in the tor config /usr/local/etc/tor/torrc - you should change those too... (not a security issue, but if they email me about your install, there's not much i can do...)
Although AWS is cool to allow lots of people, all the eggs are still in the AWS basket, which makes it easy to block. If lots of people were to run things on their own servers scattered all over the global, all over the IP space, then it's harder to block.
i understand that there's 15GB/month of bandwidth included in a free micro instance (and i have used one as a personal ssh tunnel without paying anything). the images in the link i gave - https://cloud.torproject.org/ - look like they include some limited to the free amount.
for something like this, personally, i am also willing to spend some money [i am still working on aws trying to get an image working - last attempt failed through lack of scsi drivers afaict - will post here if successful].
Just FYI, what andrew said sounded like a plan to me, but AWS only gives 750 hours with the free tier. Might suffice for now, but not forever. So looks like I'll have to do this on an linux vm instead (at home).
i was trying to get an opensuse 12.1 ami from suse studio running (as it has libevent 2). however, i am now following this http://news.ycombinator.com/item?id=3579531 and with the fixes i posted in the comments there, things appear to be ok (waiting for tor compile to finish).
Here's the beauty of an interconnected world. You can actually help someone else directly. People can easily organize around the globe to let those in power know they can't just keep doing whatever they want. Keep up the good fight!
Iran wants to prevent users from getting into the Tor network and going to sites that they do not have control over. Since it is easy for them to block the public routers Tor uses "bridges" which are nodes that will allow people to connect to the entry nodes through them. The lists of these nodes are then treated as semi-secret (in that they try to limit any one person or organization from learning all of them). This is exactly what they are looking for people to make, more bridges, not more exits.
edit: They actually say that Iran does very little active blocking and are just throttling anything that looks like TLS, so the bridge vs. entry node distinction does not really apply in this case, but it is relevant to the attack you are trying to describe.
Iran is doing an extreme version of precisely that, where the whitelist is a null set.
Tor also has a well-established way of fighting blacklists. Normal relays are all listed on a public network, but there is also an opt-in program which exists for Tor relays: a Tor relay can choose to be "hidden" in a certain sense. A "hidden" relay node accepts only entrance connections, and these are advertised more quietly by the Tor Project folks, who don't reveal too many too fast. It is therefore the case that blacklists can be circumvented by asking Tor for a couple of hidden entrance nodes and configuring yourself appropriately.
The goal of obfuscation is to buy a little more time during which people can use encryption again, by making the encryption look like normal traffic. (But I have no further knowledge of the particulars, so take what I have said with a grain of salt.)
Where is the obfuscation bridge covered in more detail? (I've already checked the link in Jason's email.) He says it's highly technical, maybe to some it is, but it only coves installation; not how the obfuscation actually works: how a TLS connection can appears to be HTTP? Someone might say read the source, but my literacy in that area is questionable.
If you're running an intermediate node, then you're proxying an encrypted datastream from one node to another. You don't know what's in the datastream, who it's from (the endpoint), or where it's going (the other endpoint). See here: https://en.wikipedia.org/wiki/Onion_routing
That's still a legal gray area. The short answer is maybe, but the EFF will probably take your case if you get in legal trouble.
> Can EFF promise that I won't get in trouble for running a Tor relay?
> No. All new technologies create legal uncertainties, and Tor is no exception. Presently, no court has ever considered any case involving the Tor technology, and we therefore cannot guarantee that you will never face any legal liability as a result of running a Tor relay. However, EFF believes so strongly that those running Tor relays shouldn't be liable for traffic that passes through the relay that we're running our own middle relay.
speaking of this, does anyone have the html/images of the iranian block page? I collect them and would really appreciate it if someone was able to send that along. Or does the iranian firewall just drop the connection without the censorship notice?
They're dropping SSH too, so I'd just assume that they're dropping everything. No block page for you. ^_^
The goal might not be censorship, even. Iran's most prominent recent actions have been provocative trade threats and hacking a US drone -- and US Presidential candidates have been discussing the possibility of eventually invading Iran. Iran has plenty of paranoia to spare:
why would it help? socat just sets up a tcp connection. whatever data you send across it is going to look like data sent across any other tcp connection (including the ones that browsers and servers use).
No I think you're probably right. Not knowing how exactly the DPI is done, I was abstractly thinking that perhaps shoving the SSL handshake through another TCP/UDP connection might defeat it but tbh I have no idea. Hence the question :)
Edit: the reason I mentioned socat was because when I used it to help the guy in China, it was because they were apparently filtering openvpn and we found that when it went via socat the connection was much more stable and faster.
Edit 2: if TCP through a UDP socat wouldn't work, how about something totally off the wall like an ipv6 tunnel over ipv4 (using http://en.wikipedia.org/wiki/Teredo_tunneling) and then an ipv4 tunnel within that ipv6 tunnel (through which the tor or openvpn connection would go). Sorry if I'm spouting garbage but it's quite fun thinking about all the random ways one might be able to tunnel one stream of data through another. (although given the Iranians urgent predicament, my mental masturbation is probably best saved for another day...)
I know jack about tor except other than it's purpose, but shouldn't it be possible to configure a virtual machine to do this and upload it, so that one would "only" have to mount the machine and turn it on in order to help?