Back to IndexBy John McDowell
Did you know that much of the internet traffic your computer generates (such as your emails or instant messages) travels across the internet in plain text?
Many protocols (such as POP3, which is widely used for mail delivery) were never intended to be secure. Because the packets sent out by your mail program are forwarded across the 'net in plain text, the computers in or near the path of the routed packets can often log the traffic passing through.
Ok, well if you are really insistent you can try it yourself on your own network if you like. Be careful to note though, while it is nearly impossible to electronically detect, packet sniffing has been made illegal on most all networks at universities and businesses. That said, it is extremely easy to demonstrate on you own private network.
My favorite network analyzer is called Ethereal (available for most operating systems) which analyzes the packets leaving from and arriving at your computer's network interface. It can be very handy for doing things like low level network programming. In this case, however, you want to set Ethereal to perform a "promiscuous" capture of all the traffic arriving at your network interface.
(Normally, your network card is configured to drop any packets that are not specifically addressed to your computer's MAC address, but Ethereal is able to put most network cards into so called "promiscuous" mode which allows the program to display all the packets addressed to any MAC.)
Once you see the tons of packets arriving at your computer, stop and reconfigure the program to filter out only, say, email or instant messaging packets into the log.
At this point, sending emails or instant messages between two computers on your network will often result in receiving the packets at your network interface, regardless of whether or not your computer was the intended recipient. This type of reception is somewhat less common now that today's switching hubs try to deliver each packet to the correct network card without broadcasting it to everyone, but certainly not the only way the a potential sniffer could receive the traffic. (For example, the perpetrator might have physical access to a monitor port on the switch, or could be sniffing a wireless network, or could even generate false ARP replies to reroute all packets destined for the local gateway to through the sniffing computer.)
In short, if you can sniff your network, it almost certain that a determined (and likely more sophisticated) criminal can intercept at least some traffic that is not intended for him.
Well, no actually, probably not. There's generally simply too much traffic to sort through and it's too troublesome to try to reconstruct partial conversations that may or may not have even been entirely routed though your local network for it to be "worth it" to a criminal in most cases. Who really cares what time you're meeting for volleyball practice, anyhow?
However, that doesn't mean there aren't certain situations that you should be aware of. Now that you've seen that it's is possible, notice how trivial it would be create a sniffer that would log all packets that appear to contain a credit card number (or a social security number, or a Microsoft CD-Key, for example). A well placed sniffer could easily log this type of information.
This motivates the need to have some way to secure at least the contents of certain sensitive communications, which is the subject of the remainder of this document. (Besides, it's a pretty cool idea, don't you think?)
The obvious solution, of course, is to selectively use end-to-end encryption for those communications which need to be protected. The common way to do this nowadays is to obtain a public-key encryption certificate from a certificate authority like Verisign or Thawte which is then used to encrypt your emails or instant messages.
While the technical details of public-key encryption are certainly interesting (to me, at least) they are really beyond the scope of this document. What follows is a basic overview of obtaining and using an encryption certificate to encrypt emails and instant messages.
Though you use any certificate authority, we'll use Thawte here as it is the only one I know of that does not charge a fee. In about five to ten minutes you can go through Thawte's process to obtain your free certificate. Be sure to use your real information as you'll be able to keep this certificate for life!
The only drawback of Thawte's (free) process is that they are only able to put your email address into your certificate initially, until you choose to go to the effort of verifying your name through their web of trust system. Note, however, that the even with just the free certificate, you'll still be able to send encrypted communications that are verified to be from someone with access to your email account.
Once the certificate is generated, follow the instructions to install it in Internet Explorer or Netscape. We will assume a Windows OS at this point, but installs on other OSes should be similar. You will be prompted to protect your private key with another password. Depending on your computer situation you may want to check the box that has Windows prompt you for a password every time something accesses your private key, but keep in mind that can get annoying really quickly.
You also have the option (in the IE list of your certificates) of exporting the certificate to a file. (For example, to manually give someone your public key.) You will need to export your private key in some cases for applications like AIM to use it, but be careful not to let others get to it even though it is password protected. In all of these situations you will want to include all certificates in the certification path.
We will also assume you are using Outlook as your email client, though Netscape also has pretty decent S/MIME support. First go to the Options -> Security tab, and click "Settings" under the "Secure Email" section. Ensure that your certificate is shown in both the signing and encryption certificate fields. The other options on the "Secure Email" tab above are usually set on a per-email basis, so it's usually fine to leave them alone here.
To send an encrypted email, the sender must have the recipient's public key. To attach your public key to an outgoing email (say, one to request a credit card number) click the "Options" button on the window where you are composing the new email and click "Security Settings". Check the box to append your digital signature.
To save someone's public key that is attached to an incoming email (so that you can send them encrypted mail), open the message that has their public key attached (a little red ribbon icon is usually shown), right click the author's name and select "Add to Contacts". (Merge the new record into an existing contact if you already have this person as a contact.) You should then see their certificate in the "Certificates" tab of the contact. Note that if you had their public key as a file, you could have directly loaded into the contact here, rather than adding it from an email attachment.
Now that the recipient's public key is attached to their contact record, you can now send encrypted mail to them by again clicking the "Options" button on the window where you are composing the new email and clicking "Security Settings". Check the box to set the email to be encrypted.
The latest versions of AIM now have the ability to seamlessly use your email certificate to encrypt your AIM conversations with any other Instant Messenger user who is also "Security Enabled." This is easy to tell, as the "Security Enabled" users have a lock icon next to their screen names in your buddy list.
To set up your AIM to use encryption, export the full path of your certificate from the IE certificate configuration window, including both the public and the private keys. You should then be able to import the certificates into AIM under My Preferences -> Security -> Advanced. Besides having to type an extra password to give AIM access to your private key when you log on, using encrypted AIM is just as easy as it ever was!
Hopefully, you should have a better understanding of how to use end-to-end encryption to secure your communication and also better understand what sort of communication is worth going to that initial effort to set up the encryption.
Please be sure to let me know if there's anything I should add or anything I can do to make this guide clearer!
| Last Modified: | © John McDowell (john.mcdowell@duke.edu) |