| 1 2 3 | ||
|
Editor: Beuc
Time: 2009/07/08 23:43:47 GMT+0 |
||
| Note: update tor config | ||
added: # Old config syntax: changed: - ReachableAddresses *:80,*:443 #ReachableAddresses *:80,*:443 # New config syntax
CVS member access can be done on cvs.sv.gnu.org:22 and download.sv.gnu.org:443 (without long-term warranty for the latter).
Anonymous CVS can be done on cvs.sv.gnu.org:2401. As long as you have 'CONNECT' privileges on the proxy, it should work, even if the connection is not TLS (eg. cvs pserver is not crypted).
First, this documentation is complainware. It means that you can freely use it provided you complain to your local system administrator, or to your Internet Service Provider (ISP), if you are using a restrictive Internet environment as described below.
This FAQ is about a system we had to setup so that people behind restrictive firewalls, or proxies, or ISP that blocks some ports, can access our CVS services. More precisely, those people experience outgoing traffic filtering. Please read the following attentively.
There is no security issue in allowing people to access a remote CVS repository, or more generaly a remote SSH server. It is rather a matter of policy, when administrators decide what kind of action they allow their users to perform. For example, some ISPs decided to block outgoing traffic to port 25 (smtp) so as to keep people from sending mail using any other service than their SMTP smarthost, and think they can fight spam (and control their users) that way.
You should know, however, that it is possible to bypass such a setup by two ways:
at the price of a decreased connection speed, to redirect your traffic to any public computer, and any port, provided you have outgoing access to port 80 (http) and 443 (https) - which anybody should have whatever their setup. Unlike what we stated in a previous version of this document, Tor now does work from behind either a firewall or a proxy.
Therefore, limiting outgoing traffic with per-protocol rules cannot be effectively done. Moreover, a lot of websites now use HTTPs?, a secure, encrypted protocol that encapsulates HTTP. That means it is not possible for the firewall to tell anything more than the fact it is SSL-encrypted traffic, and cannot try to analyse the packers to discover what the user is actually doing. Preventing HTTPs? traffic is not an option, unless the system administrator wants to prevent access to all e-commerce websites, as well as websites that only use HTTPs? such as Gna! (https://gna.org/).
work from the remote host administrators. Basically he opens the same service but on port 443 (https). This removes the proxy and speed limitation from the above. This is used, for example, by OVH (see http://help.ovh.com/EmailConfigurationAOLouTELE2/) so that people can send mail even if their ISP block port 25 (smtp). We also setup CVS over SSH on port 443 (https) in addition to port 22 (ssh) to allow people to access our CVS repositories.
Note: we implemented that method, without warranty, for project member SSH access only - not anonymous access. Anonymous access is available via pserver which ought to be available to you, just like HTTP.
In conclusion, remote outgoing traffic is a burden for us (the Savannah hackers) and does not bring any real value.
That's what it is important that you tell your local system administrator or your ISP about it. You can for example refer them to this page. I mean it: that's the only clean and reliable solution to access Savannah and other services on the Internet. You need to mention it to your local sysadmin so he realizes that opening outgoing traffic is needed, and that trying to control is ineffective and just a burden to his/her users.
Now let's see how to access our CVS services using any of those methods.
(check http://wiki.noreply.org/noreply/TheOnionRouter/TorifyHOWTO#SSHtorify for more information). This method can be used to access any remote CVS repository. Here are instructions for a Debian GNU/Linux-based distribution:
# Install Tor. Check http://tor.eff.org/download.html for more information aptitude install tor # Configure Tor cat <<'EOF' >> /etc/tor/torrc # Old config syntax: #FascistFirewall 1 #ReachableAddresses *:80,*:443 # New config syntax FirewallPorts 80,443 ##If you use a proxy: #HttpProxy yourproxyhost:port #HttpsProxy yourproxyhost:port EOF # Restart Tor invoke-rc.d tor restart
Now you should be able to use tor the easy way:
export CVS_RSH=ssh torify cvs -d:ext:username@cvs.savannah.gnu.org/cvsroot/project co module
If you don't like typing 'torify', you may want to have a look at http://shellscripts.org/project/toraliases
If for some reason that doesn't work (notify us!), you can try the difficult way:
# Get connect wget http://www.taiyo.co.jp/~gotoh/ssh/connect.c # Local copy here: https://savannah.gnu.org/maintenance/connect.c # Compile it gcc connect.c -o connect # Install it somewhere in your path install -m 755 connect ~/bin/ # Configure SSH cat <<'EOF' >> ~/.ssh/config Host cvs.savannah.gnu.org ProxyCommand connect -S localhost:9050 %h %p EOF # You now can use SSH normally export CVS_RSH=ssh cvs -d:ext:USERNAME@cvs.savannah.gnu.org/cvsroot/PROJECT co MODULE ...
If you are not root on your machine, you will need to compile Tor by hand, but that should not be a problem.
We heard that some ISPs block most of the Tor nodes. If that's the case, the fist move is to explain your system administrator that this is blocking your legitimate work, and ask him/her the reason of this filtering (we would be pleased to know that reason as well). Last time a Savannah user had this kind of issue, he didn't contact the sysadmin and didn't even know why Tor nodes were blocked - we don't think that's the way to go.
Please note again that this is a burden for us to offer this method and is not garanteed in the long run, nor will we necessarily apply it consistently to other services. Here are generic instructions for the GNU/Linux OS:
If you are connecting through a proxy, you first need to do this:
# Get connect wget http://www.taiyo.co.jp/~gotoh/ssh/connect.c # Compile it gcc connect.c -o connect # Install it somewhere in your path install -m 755 connect ~/bin/ # Configure SSH cat <<'EOF' >> ~/.ssh/config Host download.sv.gnu.org ProxyCommand connect -H PROXYHOST:PROXYPORT %h %p EOF
Replace proxyhost by your proxy host name, and proxyport by your proxy port (3128 if you use Squid).
Now, proxy or not, you need to tell SSH to use a different port:
# Create a wrapper, in your path cat <<'EOF' > ~/bin/sshwrapper #!/bin/sh exec ssh -p 443 $* EOF # Give it executable permissions chmod 755 ~/bin/sshwrapper # You now can use SSH with sshwrapper export CVS_RSH=~/bin/sshwrapper cvs -d:ext:username@download.sv.gnu.org/cvsroot/project co module ...
If that doesn't work, try typing:
Tor:
$ ~/bin/connect -S localhost:9050 download.savannah.gnu.org 443 SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4 <Ctrl+d to exit> $ socat - -SOCKS4A:localhost:cvs.savannah.gnu.org:443,socksport=9050 ...
HTTPs? Proxy:
$ ~/bin/connect -H yourproxyhost:yourproxyport download.savannah.gnu.org 443 SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4 <Ctrl+d to exit> $ socat - -PROXY:yourproxyhost:download.savannah.gnu.org:443,proxyport=yourproxyport ...
If you don't see the the remote SSH version after a few seconds, then there's a problem; please note any error message and contact us if you can't fix your configuration.
It is pretty easy to make any redirection by your own means. Buy a minimal virtual server for you and you collegues (as cheap as 9 USD per month), so you control an external IP, and use the 'redir' (or 'stunnel') tool to redirect port 443 to any plain or crypted port you want. To redirect traffic from you.somehosting.net (port 443) to cvs.savannah.gnu.org (22):
root@you.somehosting.net:~$ daemon --respawn -- redir --syslog --lport 443 --caddr=cvs.savannah.gnu.org --cport=22 For cvs-pserver:: root@you.somehosting.net:~$ daemon --respawn -- redir --syslog --lport 443 --caddr=cvs.savannah.gnu.org --cport=2401 You then can hit on you.somehosting.net port 443 to access the target Savannah service you need.
All those methods are based on a single feature: when https access is allowed, there's no way to analyse the (encrypted) traffic. In particular, URL-based filtering doesn't work with https. So you can do whatever you want on remote port 443.
However, I've already seen networks where https was simply disallowed, probably for that reason. Only port 80 was available and thus the only choice available to you was: talk the network administrator into allowing outgoing CVS access.
So don't believe those tricks can work in the long term. Some admins are already blocking Tor nodes, disabling port 443 is just the next step. The only real work around is talking with your system administrator.