I should qualify my comments from my prior blog entry and say that I’m appalled at Service Providers (not users) that continue to offer insecure services to their clients. Users, however, should be asking their Providers for secure services. Most don’t know to ask this, and that’s why I think the responsibility falls on the Provider.
Here’s my crash-course in simple anti-sniffing techniques.
- Evaluate your network: if you’re on open Wireless, any one interested can see all communications to/from your computer. Be paranoid. If you’re on a wired network, your communications can still be seen, but it tends to be much less likely.
- Evaluate your services: do you care about your various services? Do you have a different password for each service? Details below…
Evaluating your services requires creating a short list of all the things you send over the network from your computer. For basic anti-sniffing, there are two types of “encryption” available for most services:
- Authentication: logging into anything. Checking email, logging into IM, logging into websites, etc. Some services offer “encrypted” authentication. Modern AIM clients, “APOP” POP clients, etc. If your authentication is encrypted people can’t just sniff your account/password off the wire.
- Communication: all the traffic to any site/service. All services have a fully encrypted counterpart. Almost everything uses SSL for encryption, and appends an “S” to the protocol name. HTTP has HTTPS, POP has POPS, IMAP has IMAPS, SMTP has a TLS mode, Jabber has an SSL mode, good IRC networks have an SSL mode, etc. These SSL-protected services encrypt ALL of your communciation, including the username/password authentication.
It’s best to have fully encrypted communications, but if you can’t, just getting some kind of obfuscated authentication mechanism is better than nothing. Just ask yourself any time you type in a username/password, “How is this being sent to the remote server?”
So, here are some specifics to various common services:
- Receiving email: POP and IMAP have SSL modes that run on different ports. See if your email Provider offers these services and switch your client to using those instead. If that’s not available, see if POP or IMAP support other authentication modes besides the clear-text “Plain” and “Password”. For example CRAM-MD5, Challenge/Response.
- Sending email: SMTP has an SSL mode too. This is either called “STARTTLS” or “SSL”. A good Provider will offer SMTP on port 587 with STARTTLS. Hopefully your Provider requires you to authenticate before sending email. Instead of SSL, like POP/IMAP above, they may offer CRAM-MD5, etc.
- Web sites: only use “https://” for logging into websites. If there isn’t a little lock in the corner of your browser, don’t log in. The browser folks have done a lot to help folks with this part. Ecommerce has caused a huge push to avoid in-the-clear authentication on websites. Unfortunately, some sites will still let you log in without SSL. (Like flickr, it seems.)
- IM: I’m not sure about ICQ, MSN, etc, but Jabber offers a full SSL mode. The “old” style runs on a separate port (5223). The “new” style gets “turned on” during the initial jabber session setup. This would give you fully encrypted communications. I know AIM has both a Challenge/Response and MD5 mechanism for logging in, so at the very least, use those.
If you’re not sure if your communication is being encrypted or not, it’s very easy to install a network sniffer. Ethereal is available for almost every platform around, via the libpcap libraries. Just start it capturing before you use a service, use the service, and then go find the traffic in the capture log. Ethereal will identify almost all services by name (“HTTP”, “POP”, “IRC”, “AIM”, etc.) To see the traffic, click on the “Analyze > Follow TCP Stream”. This will show you all the communication for a given connection. (Click on “Clear” in the Filter bar to see all your traffic again.)
If you want to browse the traffic more easily, you can type in other filter terms. For example, to make sure your POP password isn’t being sent in the clear, enter “pop.request” in the Filter, and click “Apply”. Pick a packet, and select the “Request” section in the Packet Tree. If you see:
Request: USER omfg
Request: PASS intheclear
Then your “omfg” account is showing it’s password to the rest of the network. :)
Another alternative to all this pain is to have a VPN connection to some other network that you trust. This is the easiest to configure on the client side. If that’s not available, you can also tunnel all your traffic through an SSH connection. This is easiest to configure on the server side (no config). Here is an example of tunneling your POP service through SSH:
ssh -L 2110:pop.example.com:110 account@example.com
That’ll set up a local port 2110 that gets forwarded to “pop.example.com” port 110 (POP) after logging you in to some SSH account. This means you have to configure your POP client to use “localhost” port 2110 instead of “pop.example.com” on the regular POP port. And then you can only POP when your SSH connection is up.
© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.