My co-worked Steve mentioned that he was in a bookstore the other day and saw a book on security in instant messaging systems. He said he flipped through the index and table of contents to see if he could find references to S/AIM, the feature we added to AIM (AOL Instant Messenger) in 2001.  (I wrote about this before)

Nope.  There were chapters talking about how to shoehorn PGP into IM clients and other hacks.  But nothing on the feature that's build into the AIM 5.x series. I find this odd given that you can search the web for "AIM certificates" and get pages that talk about it.

I just downloaded the AIM 5.9 client and found that the security is still in there.  Here's the preferences window.  At the bottom is the "Security" tab where you can import a valid certificate. We never got to implement our transparent certificate enrollment scheme, so this part of the UI is still a little clunky.  Still, if you have a certificate it's trivial to import it and to start to use it.








This next picture shows what a normal AIM conversation looks like in secure mode. As you can see (when you click on the image), the conversation is both encrypted and signed. It's very important that the messages you receive be signed.  It's not enough to just encrypt the messages.  Without signing, you can't really have encryption between the intended parties. (Think about it for a minute if that sounds wrong to you. It's important.) 

If you click on the lock icon, you can see a summary of the other person's certificate (who issued it, when it was issued, when it will expire, etc.)

In the main AIM buddy list window, you can see who among your friends also has a certificate by noting the presence of a lock icon to the left of his/her screen name. The system in its current form requires that both parties have certificates for the security to kick in.  When both parties have certificates, the client automatically sets up a secure channel when they start an IM session.  Users don't have to initiate anything or go into a secure mode.  It just happens.  Even when both parties use smart cards, there's no noticeable delay in the communications.

This system is based on the CMS (Cryptographic Message Syntax), which is used in systems like S/MIME. That means that it provides end-to-end security.  No evesdropper between you and your friend will be able to understand the gibberish that's being sent back and forth, including AOL.  It's all opaque to them.

I miss having real end-to-end security in my IM client.  If anyone from the GAIM team wants to learn more about how to put this great feature into that product, please give me a holler. We'd love to help.

Seth sent me this link to the Google Talk Help Center which includes this help for linking Psi to your Google account for chatting.

It reads:

Congratulations! You are now ready to connect to the Google Talk service using Psi.

Once you've configured Psi to connect to the Google Talk service, you may receive a warning message that stating that the 'gmail.com certificate failed the authenticity test. This error message is incorrect; click 'Continue' to sign in.

Here's the actual screenshot:




I was interested to see what was going on, so I loaded Psi.  Indeed they do seem to like the idea of trusting certs without verification.  Check out this configuration window, with the "Ignore SSL warnings" option:




When I examined the cert, it looked like it might be legit.  It seems to be from Equifax. 



I cracked a number of the certs in the Psi root certificate database.  Some of them were familiar, and some were not.  Since there were well over 100 roots, I would have expected Google's Equifax-issued cert to work. Maybe it's not really Equifax.  Or maybe we're missing an intermediate CA.

Whatever the reason, teaching users to ignore serious security warnings, and making an "Ignore SSL warnings" preference are marks of bad security.