WaveLAN's silver and gold cards

In November, I wrote an introduction to Lucent's WaveLAN wireless card, the 802.11b PC card that we've been using at the O'Reilly Network to bring our machines online in a wireless local area network.

A lot can happen in a couple of months. In
that article,
I explained the difference between the WaveLAN silver and gold cards, and suggested that since the gold cards were only a few dollars more for much stronger encryption, it was worth it to buy the gold cards (assuming that breaking total compatibility with the 802.11b spec wasn't an issue.)

Since then, a team of cryptographers at the University of California at
Berkeley identified weaknesses
in the way the Wired Equivalent Privacy (WEP) algorithm was implemented in 802.11b, potentially making the
strength of encryption irrelevant.

This news should not be cause for alarm, or even discomfort. WEP was not
designed to be the ultimate "killer" security tool (nor can anything claim
to be). Its acronym makes the intention clear: wired equivalent protection.
In other words, the aim behind WEP was to provide no greater protection than
you would have when you physically plug into your Ethernet network.

So, if it has been cracked, what good is WEP? And how can one protect
oneself if WEP isn't the answer?

802.11b's security weaknesses

"You can try it for
yourself; run tcpdump on your laptop, and watch the traffic going through your access point just fly by!"

WEP has never provided much more than a form of access control to your
wireless nodes. With a shared private key, everyone participating in your
network has the potential to eavesdrop on everyone else. You can try it for
yourself; run tcpdump on your laptop, and watch the traffic going through
your access point just fly by! Passwords, private e-mails, web traffic,
everything could potentially be logged and pored over later by anyone who
can associate with your access point.

Plus, key management under 802.11b is difficult. Who wants to distribute a shared password, only to have to change it regularly (and revisit all of those clients who weren't adept enough to set it up themselves in the first place?) Some drivers try to cope with this by letting the user assign multiple keys and pick between them, but this just postpones the inevitable.

Tunneling for security

WEP insecurity really isn't a problem for people who are already tunneling their traffic. Sure, Johnny and Jane Cracksalot may point their high-gain dish at the company from two blocks away, and even take the 5+ hours and gigs of disk space necessary to track every packet. But if you're using an SSH tunnel from your laptop to your servers, they'll still have the insurmountable task of cracking strong cryptography (Blowfish, 3DES, Arcfour, etc.). Until someone finds a cheap way to build a quantum computer (and perhaps a cold fusion cell to power it) this is generally considered a waste of time. Ditto for SSL (Secure Sockets Layer) connections to secure web servers.

A tunnel is a networking term with an appropriate name. It refers to a
connection, usually encrypted, that connects two computers together across
another, usually untrusted network. Picture a mountain of evil 3l33t d00dz
sitting between your laptop and a server on your internal, protected
network. You don't want to just throw your traffic really hard at the
mountain and hope it gets there; you want to first form a protected
tunnel from you to your machine, and then send the traffic through it.

Take this typical scenario:

You're at work or at home, merrily typing away on your wireless laptop. You
want to retrieve your e-mail from work with a POP client (Netscape Mail,
Eudora, fetchmail, etc.). If you connect to the machine directly, your e-mail
client will send your login and password "in the clear." This means that a
nefarious individual somewhere between you and your mail server (either
elsewhere on your wireless network, or even "on the wire" if you are
separated by an untrusted network) could be listening, and grab a copy of
your information en route. This login could then be used not only to gain
unauthorized access to your e-mail, but in many cases will also grant a shell
account on your mail server!

To prevent this, you can use the tunneling capabilities of SSH. An SSH
tunnel works like this: Rather than connecting to the mail server
directly, we establish an SSH
connection to the internal network that the mail server lives in
(frequently, the mail server itself). Your SSH client software sets up a port forwarding mechanism, so that traffic that goes to your laptop's POP port magically gets forwarded over the encrypted tunnel and ends up at the mail server's POP port. You then point your e-mail client to your local POP port, and it thinks it is talking to the remote end (only this time, the
entire session is encrypted.)

With the tunnel in place, anyone who tries to monitor the conversation
between your laptop and the mail server will get something resembling line
noise.

Setting up SSH

To set this up, you'll need an SSH client capable of tunneling. My personal
favorite is
OpenSSH.
Under Windows, you'll need a client like
SecureCRT
(which is commercial software). You might have luck with OpenSSH
under Cygwin.
(I haven't tested this; let me know if you manage to get it working!)

Once you've installed an SSH client, you can use it to tunnel
POP traffic from your local laptop
to your mail server (called "mailhost").

We'll assume you have a shell account on the mail server for this example,
although any machine on your internal network that accepts SSH connections
should suffice.

Step One. Establish the connection

Under OpenSSH:

laptop# ssh -L 110:mailhost:110 -l user -N mailhost

(Naturally, substitute user with your username, and mailhost with your
mail server's name or IP address). Note that you will have to be root on
your laptop for this example, since you'll be binding to a privileged port
(110, the POP port). You should also disable any locally running POP daemon
(look in /etc/inetd.conf) or it will get in the way.

Assuming you have your RSA or DSA keys setup, you can even run this in the
background (tack on a &). This sets up the tunnel, and starts
forwarding your local ports to the remote end through it. The -N switch
tells SSH to not bother running an actual command on the remote end, and
just do the forwarding.

Click the Advanced button and the Port Forwarding tab. Fill in
110 as the local port, the mail server's hostname (or IP address) for the
remote hostname, and 110 for the remote port. Click the Save button (not
the New button!) Click OK.

Make the connection, and give it your username and password. Voila! You
now have your very own tunnel.

Step Two. Configure your mail software

You now need to tell your mail software to connect to your tunnel rather
than connecting to your mail server directly. This is different in each
application, but the idea is always the same: You want your e-mail client to
connect to localhost instead of mailhost.

Here's how to set it up under Netscape Communicator; other clients
may have different menu choices, but the principle is the same:

Naturally, it doesn't have to end with POP. You can also forward SMTP for
outgoing mail (port 25). This is mostly left as an exercise to the reader,
but here's a hint: A single ssh line can have multiple -L entries, like
this:

ssh -L 110:mailhost:110 -L 25:mailhost:25 -l user -N mailhost

And for Windows users, SecureCRT can have multiple active tunnels.
Just stack 'em on, and it will take care of the rest.

All of the above can be automated. Make it as easy
as possible to use the tools, and you'll find that you will get in the habit of using them. Security doesn't have to be hard. And SSH is a very flexible tool to help keep your data secure -- WEP or no WEP.