Take the Chinese Government Out of Firefox

If you use the Firefox Web browser, you are unwittingly granting the Chinese government the ability to make your browser validate the identity of any Web site controlled by that government. How is this possible?

When a Web browser visits a secure Web site, it validates the site's identity by checking the digital signature on the SSL/TLS certificate presented by that Web site. Those digital signatures are generated by Certificate Authorities (CAs) which are trusted implicitly by every Web browser. A company that operates a secure Web site, such as Amazon.com, wants your browser to validate the identity of their site, so that customers can trust that their credit card info is being sent to the real Amazon.com instead of a site that is pretending to be Amazon.com. To do this, they pay a Certificate Authority to verify their identity and issue a digital signature on their site's SSL/TLS certificate. That digital signature is how a CA vouches for the identity of a secure Web site.

We trust Certificate Authorities never to issue digital signatures for fake Web sites. We believe they won't do that, because if a CA loses its trustworthy reputation, it loses money. Your Web browser is created to automatically trust many different CAs. How many? Well, it might surprise you, but it's hundreds of CAs — from all over the world. And one of them is the Chinese state Network Information Center, known as CNNIC.

If you use Firefox, you can see the list of trusted CAs by choosing Options from the Tools menu, then select the Advanced tab, then the Encryption tab, and click on View Certificates. This will open the Certificate Manager dialog. Click on the Authorities tab. Scroll down to the entry for CNNIC ROOT: It should look like this:

CLICK IMAGE TO SEE A LARGER VERSION

Select the CNNIC ROOT entry and click on the Edit button. This opens the Trust Settings dialog for that CA, which should look like this:

CLICK IMAGE TO SEE A LARGER VERSION

Those checkboxes tell your browser to trust the CNNIC Certificate Authority to identify Web sites, mail users, and software makers. Uncheck all of the checkboxes and click OK on each dialog.

Now your browser refuses to trust the Certificate Authority operated by the Chinese government.

SSL's Dirty Little Secret

SSL is the Secure Sockets Layer protocol that Web browsers and Web servers use to secure the data they exchange with each other. SSL is more formally known as TLS (Transport Layer Security). The name of the protocol was changed because SSL is a trademark of Netscape Communications Corporation. But a lot of people still call it SSL.

You probably know that SSL is used to secure an HTTPS connection when you browse to a secure Web site. Most people know that a secure Web connection uses SSL to encrypt all data sent in both directions. This prevents someone who is snooping your network traffic from seeing sensitive information, such as your credit card number. A lesser known benefit of an SSL connection is that your browser authenticates the Web server so that you can be sure the Web server is who it says it is. You don't want to send your credit card info to a Web site pretending to be Amazon.com, even if it is encrypted during transit. The bad guy still gets your credit card number, and the encryption only serves to prevent different bad guys from stealing it in transit.

Your browser can authenticate a secure Web server because the server sends an SSL certificate to the browser. That certificate (or "cert" in technical jargon) contains the identity of the server along with a public key that can be used to encrypt data sent to the server (see http://en.wikipedia.org/wiki/Public_key_cryptography for more info on how public-key cryptography works). The obvious question is: How can your browser be sure the identity information in the certificate is not fake? That is done using a digital signature.

A digital signature is a piece of data that someone creates using a digital signature algorithm (see http://en.wikipedia.org/wiki/Digital_signature for more info). A digital signature is like a fingerprint of some other piece of data (such as an SSL cert). Your Web browser takes the digital signature that comes with the SSL cert and performs some math on the cert and the digital signature. The outcome of that math tells your browser two things:

1. Was the content of the cert modified in any way after it was digitally signed?
2. Is the identity information in the cert to be trusted?

These two facts can be computed mathematically thanks to the wonders of public-key cryptography (which is beyond the scope of this little blog post to describe). Now you might ask: Why can't a fake Web server simply put a fake digital signature on their fake SSL cert to fool my Web browser into believing the server really is Amazon.com and thus leading me to send them my credit card number?

The answer is that it is mathematically impossible (again thanks to public-key cryptography) to fake a digital signature. The math behind public-key cryptography allows your browser to detect a fake digital signature. Your browser only trusts digital signatures that have been created by a short list of trusted certificate authorities (CAs) — organizations that make money by digitally signing SSL certificates to vouch that the identity information in a cert is correct. That short list of trusted CAs is built into your browser by the browser vendor, and those CAs obey strict rules guiding how they will digitally sign a Web server's SSL cert.

This combination of encryption and server-authentication has allowed Web-based commerce to flower in the last 15 years. We all know to look for some icon or color change in our browser that tells us "This Web server is who they say they are, and all data exchanged with this server is encrypted." This is the reason you can read your email and buy things on Amazon.com when using your local coffee shop's free WiFi without worrying that your data is being seen by the bad guys. It's perfect.

Or is it? The SSL/TLS protocol has a dirty little secret: Your browser will trust any CA it is configured to trust, and anyone with administrative access to your computer can configure a new trusted CA in your browser without you knowing about it! If someone adds a new (fake) trusted CA to your browser, that person can set up a fake Web site that presents an SSL cert digitally signed by that fake CA, and your browser will validate the fake cert, leading you to believe the site is legitimate when it really isn't. You might give the site your credit card number or some other sensitive data. That's bad.

I know what you're thinking: This can only happen if someone has administrative access to my computer, so I'm safe. This is probably true for your home computer, but consider your work computer. Many people believe that if they use a secure Web server from work to read their personal email or buy something online, then their employer cannot see the content of the Web traffic exchanged with that server. This is not true!

It is standard these days for employers to run so-called net nannies, software that watches the content of Web sites browsed by employees. This enables the employer to block unwanted content and to watch for data leaks. This happens so much that there's a name for the category of products that do this monitoring: Data Loss Prevention (http://en.wikipedia.org/wiki/Data_Loss_Prevention). If your company is running a DLP product, then you might be surprised to learn that it can monitor your SSL-encrypted Web traffic as well as your non-encrypted Web traffic. How is that possible?

Simple. Your company, which has administrative access to your work computer, adds a new (fake) CA to the list of trusted CAs in your Web browser. Then it sets up a server to transparently proxy your outbound HTTPS connections. When your browser connects to a secure Web server outside of the company, the proxy responds in place of the secure server, giving your browser a cert that claims to be from the outside server but which contains the public key of the company-owned proxy server and a digital signature generated by the fake CA operated by your company. Your browser validates the digital signature, because it comes from a trusted CA. Your browser believes it has connected to the outside secure Web server but it is really connected to your company's proxy server. The proxy server then makes its own connection to the external secure Web server and forwards data between the outside server and your browser, monitoring it in the process.

There's a name for this. It's called a Man-in-the-Middle (MITM) attack (see http://en.wikipedia.org/wiki/Man-in-the-middle_attack), because the company's proxy server is sitting in the middle of the communication between your browser and the outside Web server. How can you prevent this? The best way is to use the Firefox browser and install the Certificate Patrol add-on (https://addons.mozilla.org/en-US/firefox/addon/6415). This add-on watches for changes in the SSL certs received by your browser. If you previously have visited a secure Web server and your company begins intercepting your SSL traffic using a DLP product, you will be alerted that the SSL cert has changed. This add-on does not trust the list of CAs configured into your browser. It simply compares the newly-received cert with the previously-received cert and alerts you if it has changed.

That's great if you know the SSL cert previously received by your browser is legitimate, but what if it's your first day on the job, or you get a new computer from your IT department, or the IT department wipes your hard drive to install a new OS? The Certificate Patrol add-on can't help in that case. Instead, you should manually examine the SSL cert to see if it matches a known-good copy of the cert. Don't visit the secure Web server until you know for certain that the cert you get from inside the company is the same as the cert you get from outside (i.e., from home).

So how do you manually examine the SSL cert of a secure Web server? If you have a Linux machine (or have Cygwin installed on a Windows machine), you can use the openssl utility like this:

$ echo | openssl s_client -connect mail.google.com:443 2>/dev/null |
         sed -ne '/BEGIN/,/END/p'

Simply change mail.google.com to the hostname of the secure Web server you want to examine. The output of the above command looks like this:

-----BEGIN CERTIFICATE-----
MIIDIjCCAougAwIBAgIQHxn23jXdY6FCkYrVLMCrEjANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x
MTEyMTgyMzU5NTlaMGkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRgw
FgYDVQQDFA9tYWlsLmdvb2dsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBANknyBHye+RFyUa2Y3WDsXd+F0GJgDjxRSegPNnoqABL2QfQut7t9CymrNwn
E+wMwaaZF0LmjSfSgRSwS4L6ssXQuyBZYiijlrVh9nbBbUbS/brGDz3RyXeaWDP2
BnYyrVFfKV9u+BKLrebFCDmzQ0OpW5Ed1+PPUd91WY6NgKtTAgMBAAGjgecwgeQw
DAYDVR0TAQH/BAIwADA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnRoYXd0
ZS5jb20vVGhhd3RlU0dDQ0EuY3JsMCgGA1UdJQQhMB8GCCsGAQUFBwMBBggrBgEF
BQcDAgYJYIZIAYb4QgQBMHIGCCsGAQUFBwEBBGYwZDAiBggrBgEFBQcwAYYWaHR0
cDovL29jc3AudGhhd3RlLmNvbTA+BggrBgEFBQcwAoYyaHR0cDovL3d3dy50aGF3
dGUuY29tL3JlcG9zaXRvcnkvVGhhd3RlX1NHQ19DQS5jcnQwDQYJKoZIhvcNAQEF
BQADgYEAicju7fexy+yRP2drx57Tcqo+BElR1CiHNZ1nhPmS9QSZaudDA8jy25IP
VWvjEgaq13Hro0Hg32ZNVK53qcXwjWtnCAReojvNwj6/x1Ciq5B6D7E6eiYDSfXJ
8/a2vR5IbgY89nq+wuHaA6vspH6vNR848xO3z1PQ7BrIjnYQ1A0=
-----END CERTIFICATE-----

That block of apparently random text is the binary SSL cert encoded in base64 form, which allows it to be easily transmitted textual form and visualized by people. If you fetch a cert from outside your company and save it in a file, then you can fetch it again from inside your company and compare them (the Linux diff utility is the simplest way to do that). If they are byte-for-byte identical, then you know that your company is not intercepting your SSL traffic. If they are different, do not connect to that secure Web server, until you can re-verify the cert from outside. Occasionally, secure Web sites change their SSL certs, so you might see a difference that is not caused by an SSL interceptor.

File this under What They Never Told Me About the Web.

Prevent Web Sites from Accessing Your Facebook Info

It's all well and good to configure your Facebook privacy settings to limit what other Facebook users can see of your personal info, but Facebook also allows other Web sites to access your account info if you are logged into Facebook when you visit the other site. Yes, you can configure Facebook not to allow this, but there is no guarantee that Facebook will always allow you to block other sites from accessing your profile, so you need to take matters into your own hands.

You can use Firefox's Adblock Plus add-on (https://addons.mozilla.org/en-US/firefox/addon/1865) to prevent any other Web site from talking to Facebook when you visit that site. Just install Adblock Plus and then add the following filters:

||facebook.com/*$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||facebook.net/*$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||fbcdn.com/*$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||fbcdn.net/*$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net

Enter them exactly as shown, including the vertical bars (|), asterisks (*), dollar signs ($), equal signs (=), and tilde (~) characters. Don't add any spaces either. This screenshot shows what the rules should look like after you've added them to Adblock Plus:

CLICK IMAGE TO SEE A LARGER VERSION

How does this work? When you visit a site such as http://cnn.com/, the CNN Web server sends you a page that might contain code that tells your browser to interact with Facebook. That allows the CNN Web site to access your Facebook profile (and even change it). The above filters tell Firefox never to allow any site other than Facebook's four sites (facebook.com, facebook.net, fbcdn.com, and fbcdn.net) to access Facebook. Thus, Facebook continues to work perfectly, but other sites don't get to talk to Facebook at all.

This has nothing to do with blocking ads. Adblock Plus was invented to block ads, but we're using it to block any access to Facebook from other sites.

NOTE: This doesn't eliminate the need to configure your private settings within Facebook, but it stops any secret agreements between Facebook and other companies from allowing those companies to access your Facebook profile.

Stop Firefox from Following Links That You Never Click

If you use Firefox, you may not be aware of one its hidden features that not everyone likes. When you fetch a Web page using Firefox, that page typically contains many links to other pages. Obviously, since you fetched the page in the first place, you are likely to click on some of the links on the page. Firefox tries to guess which links you are likely to click next, and before you click on them it follows those links and caches the downloaded pages. It does this to give you a faster browsing experience. If you actually click on one of those links, the resulting page loads very fast, because Firefox has already followed the link before you clicked on it.

On the face of it, this seems desirable, but there are some serious issues with this behavior. If you pay for your bandwidth by the byte — or if you have a bandwidth cap imposed by your ISP — then all that hidden page-fetching by Firefox still counts as downloading to your ISP.

But worse, if you visit a page that contains links to content that your employer finds objectionable or that your government finds illegal, then shouldn't it be your decision whether or not to click on those links? The fact is — unless you are surfing using anonymous free WiFi — your IP address can be tracked directly to you personally, and nearly every page you fetch is logged in some Web server's access log. So how do you turn off this "feature" in Firefox?

It's pretty simple. In the Firefox address bar, type:

about:config

and press Enter. If this is the first time you've done this, you'll have to click a button that means you promise to be careful. This brings you to a list of Firefox's internal configuration options. In the Filter field at the top of the page, enter "prefetch". You should see a single line for an option named "network.prefetch-next" that has the value true. Double click the option to change the value to false. That's all there is. Your change takes effect immediately, though I suggest that you close and re-start Firefox just to be safe, because it's possible that this configuration value is only consulted at start-time.

Digital Alchemy

Medieval alchemists sought to transmute base metals, such as lead and bronze, into gold. Modern science has taught us the futility of that pursuit. In the digital world, there's a kind of digital alchemy that exists thanks to the lowly Boolean XOR operation. The XOR operation is a cousin to the more widely known OR and AND operations. Here's a table showing how XOR works when computing A XOR B for all possible bitwise values of A and B:

As you can see, it's the same as the Boolean OR except the value of 1 XOR 1 is 0. This minor difference enables some truly unique properties, which are commonly used in the field of cryptography.

Suppose you have a message that you want to encrypt (the plaintext). If you represent the message as a string of bits, and you generate a random sequence of bits of the same length to use as the encryption key, then you can encrypt the message by simply XOR'ing each bit of the key with the corresponding bit of the message. The resulting ciphertext is indecipherable without the key. If you send the ciphertext to someone, they can decrypt it simply by XOR'ing the cyphertext with the key, which gives back the original plaintext.

This can be summed up as follows:

C = P XOR K
P = C XOR K

where P is the plaintext, K is the key, and C is the ciphertext. Clearly, XOR'ing with K is a bidirectional transmutation of the plaintext into the ciphertext and vice versa.

This is called a One-Time Pad, and it's a mathematically perfect encryption system, but it's completely impractical to use, because the key is just as large as the message, and you need to have a way to distribute the key to the recipient securely. Oh, and you can never — ever — reuse a key, or it is trivial to crack the encryption. But this post isn't about using XOR as an encryption tool. Instead, I want to show how to use it to transmute any data into any other data, much like the medieval alchemists sought to transmute base metals into gold. This ability to turn any data into any other data has implications for file sharing.

Suppose I want to share the latest DVD image of Windows 7 with other people. If I take the DVD image of Windows 7 and XOR it with an equally large DVD containing, say, a free Linux distribution, then the resulting string of bits will appear to be garbage. Anyone who downloads that string of garbage bits can transmute it back into a Windows 7 DVD image by downloading the same free Linux distribution and XOR'ing it with the garbage bits. The result of that XOR operation is a Windows 7 DVD image.

Of course, it's probably still copyright infringement to do this, but the main idea of this post is that any string of bits can be transmuted into any other — arbitrary — string of bits by XOR'ing with the appropriate string of (apparent) garbage bits. Convert the CD image of Black Sabbath's first album into Handel's Messiah, the text of Mein Kampf into the New Testament, the source code of vi into Emacs, or a DVD of the worst movie ever made into an Oscar-winning classic. This is the modern world's digital alchemy.

How to Break Out from Inside a Draconian Firewall

If you work at an organization where outbound Internet traffic is restricted — and possibly closely monitored — you may long for the freedom that we old-timers had back in the day, when most firewalls blocked only inbound traffic and allowed people inside the firewall to make arbitrary outbound connections. By "arbitrary", I mean the kinds of connections that let you do more than simply surf the Web using the HTTP and HTTPS protocols. For instance, most organizations these days don't allow you to make outbound connections that use these protocols:

• FTP (file transfer)
• TELNET (remote login)
• NNTP (Usenet news)
• SMTP/POP3/IMAP (sending and receiving email)
• SSH (encrypted remote login)

Wouldn't it be nice if there was a way to make secure outbound connections using arbitrary protocols, even from behind a firewall that allows only monitored Web surfing? Well, you can, and here's how to do it.

First, you'll need a Linux machine outside of the firewall to which you have "root" access. You could take an old PC, install Linux on it, and hook it up to the Internet from your house. You'll probably need to ask your Internet Service Provider to give you a public IP address. Another way is to purchase a virtual Linux server from a Virtual Private Server (VPS) hosting company, such as Linode, where you can get a nice low-end server with a public IP address for US$19.95/month.

Next, install the OpenSSH server on that machine. If you're using Ubuntu Linux, you can do that by executing this command:

sudo apt-get install openssh-server

You probably won't have to do this, since most Linux distributions come with an OpenSSH server already installed. Next, install the stunnel utility with this command:

sudo apt-get install stunnel4

stunnel is a tool that listens for TLS (also known as SSL) connections on a specified port, decrypts the incoming client traffic, and forwards it to an arbitrary host and port. If you don't use apt-get to install stunnel, then you'll have to manually generate the TLS certificate file (see these instructions).

Next, we'll configure stunnel to listen on port 443, the HTTPS protocol port, which mimics the behavior a secure Web server, and forward the traffic received there to port 22, the SSH server port, on the same machine. Do this by creating a text file named stunnel.conf containing this text:

foreground = no
output = /tmp/stunnel.log

[sshtunnel]
accept = 443
connect = 22

Then, start stunnel with this command:

sudo stunnel stunnel.conf

The stunnel process will continue to run in the background as a daemon, writing log information to the file /tmp/stunnel.log. Any connection made to port 443 (the HTTPS port) on your Linux box will be received as an encrypted TLS connection, and the decrypted traffic will be forwarded to port 22 (the SSH server port) on the same machine.

Maybe you can see where this is going. Most firewalls that let you surf the Web will let you make connections to port 443, the HTTPS port, because that's how Web browsers connect to secure Web servers. Thanks to the stunnel process running on your Linux box, any TLS connection made to port 443 on your Linux box is automatically forwarded to your SSH server. If we can get an SSH client to make a connection to port 443 on the Linux box, then we can login to it.

Of course, this means you need to have an SSH client on a machine behind the firewall. If you're running Linux, you probably have the OpenSSH client installed already, but if not, you can get it under Ubuntu Linux with this command:

sudo apt-get install openssh-client

If you're running Windows, you have two options:

• Install Cygwin, a free Linux emulation package that includes the OpenSSH client
  
• Install Putty, a free Windows-based SSH client
  

I recommend installing Cygwin, because it contains both stunnel and OpenSSH. The commands shown below use the OpenSSH client syntax.

Now all we need to do is find a way to make the OpenSSH client that's behind your organization's firewall connect to port 443 on your Linux box. The OpenSSH client has a –p option that lets you specify the TCP port to which the client should connect. We could try to use that option to tell the OpenSSH client to connect to port 443 on your Linux box, but that wouldn't work. The problem is that the SSH client doesn't speak the TLS protocol, which is needed to communicate with the stunnel daemon listening on port 443. The solution is to use stunnel again, but running in client-mode on your machine inside the firewall. Just create a file named stunnel.conf on your machine inside the firewall containing this text:

foreground = no
output = /tmp/stunnel.log

[sshtunnel]
client = yes
accept = 9999
connect = yourlinuxbox:443

where yourlinuxbox is the hostname or IP address of your Linux machine outside the firewall. Start the client-side stunnel daemon like this:

stunnel stunnel.conf

Now you have an stunnel client listening for TCP connections on port 9999 on your machine inside the firewall. When an SSH client connects to port 9999 on your machine, the connection will be tunneled over an TLS-encrypted connection through the firewall to port 443 on your Linux box. From there, the traffic will be forwarded by the stunnel daemon to the SSH server on your Linux box, and you are logged in to the Linux box. To make such a connection, execute this OpenSSH client command on the same machine that's running the stunnel client:

ssh -p 9999 localhost

This works because the outbound connection to port 443 looks exactly like a normal Web browser connecting to a secure Web site! Your organization's firewall cannot tell that it's really carrying SSH protocol data, because it is encrypted end-to-end using the TLS protocol, a Web standard for securing the traffic between browsers and Web servers.

So all of this lets you SSH to your Linux box from behind a firewall. What about all those other protocols? How will this help you connect to a public NNTP or IMAP server — or surf to a Web site that is blocked by your firewall? This is where the power of SSH comes in. The OpenSSH client has a –L option that forwards connections received on arbitrary local TCP ports over the encrypted SSH connection. We'll use that option to open any number of other tunnels through the firewall.

Suppose you want to connect to Google's secure IMAP mail server (which listens on TCP port 993) to read your email using a desktop email reader such as Thunderbird or Outlook, but your organization's firewall blocks outbound secure IMAP connections. After setting up the stunnel client and server as described above, use this OpenSSH client command to login to your Linux box:

ssh -p 9999 -L 10993:imap.gmail.com:993 localhost

The –L option tells OpenSSH to listen for connections on port 10993 on your machine and forward them over the encrypted SSH connection (which is itself forwarded over the encrypted stunnel connection) to Google's IMAP server — imap.gmail.com — listening on port 993. Then simply configure your mail reader to connect to port 10993 on host localhost, and it will actually connect to Google's IMAP server. You can use as many –L options as you want, each one forwarding a different local TCP port to an arbitrary remote host and port.

Clearly, this is a powerful way to make arbitrary TCP connections from behind a firewall when that firewall only allows Web surfing. But what if your organization's firewall implements a "net nanny", which is software that watches your outbound Web connections and blocks connections to sites deemed unacceptable? Since you can't forward hundreds or thousands of ports to every possible Web server you might want to browse, the above SSH client command doesn't help. Instead, we'll use OpenSSH's built-in SOCKS proxy.

A SOCKS proxy is a software server that lets applications connect to it, and it forwards those connections to arbitrary remote hosts and ports. The application needs to have built-in support for SOCKS proxies, but thankfully every Web browser supports SOCKS. We can use this to enable unrestricted Web surfing over our SSH tunnel. We do this by using OpenSSH's –D option:

ssh -p 9999 -D 8888 localhost

The above command creates a SOCKS5 proxy listening on port 8888 on your machine inside the firewall. Applications that connect to port 8888 on your machine can request the connection to be forwarded to an arbitrary remote host and port. That forwarded connection is tunneled through the firewall over the encrypted SSH connection (which is itself tunneled over the encrypted stunnel connection).

Now configure your Web browser to use a SOCKS5 proxy on port 8888 on host localhost, and you are good to go. If possible, configure your Web browser to do remote DNS queries, which causes it to tunnel DNS queries over the SOCKS proxy instead of doing them from behind your firewall (Firefox users see these instructions). You don't want your organization's DNS administrators seeing all those name resolution requests.

When using this tunnel, your organization's firewall sees only a single outbound TLS connection to port 443 on your Linux machine. This looks like a single, long-lived connection to a secure Web server. The only evidence that it's not normal Web-surfing is that it lasts for a long time and, if you are uploading a lot of data over the tunnel, the traffic is not dominated by data flowing inbound. If you think that might arouse suspicion, then don't upload data and don't leave the tunnel up for more than a few minutes at a time. If you are asked about the duration of the connection, you can always blame your Web browser for leaving the connection open. No matter what happens, the traffic over the tunnel is completely encrypted.

Yes, this is complicated. Yes, this is something only geeks will want to do. But if you've made it this far, it's time to admit you're a geek. Since this procedure requires running two separate commands on your machine behind the firewall, I've written a shell script called tunnel that automates the process. You still have to start the stunnel server on the Linux box outside the firewall, but this script can do that for you too. Download the script from here: http://li58-96.members.linode.com/~franl/code/tunnel. Invoke it with option --help to see a usage summary.