Web-Based Encrypted E-Mail
A version of this essay appeared on ZDNet.com.
The idea is enticing. Just as you can log onto Hotmail with your browser to send and receive e-mail, there are Web sites you can log on to to send and receive encrypted e-mail. HushMail, ZipLip, YNN-mail, ZixMail. No software to download and install…it just works.
But how well?
HushMail <http://www.hushmail.com> is basically a PGP or S/MIME-like e-mail application that uses Java (although oddly enough, HushMail is not compatible with either). The sender logs onto the HushMail Web site, and encrypts messages using a Java applet that is automatically downloaded onto his machine. Both the sender and receiver need to have HushMail accounts for this to work. Accounts can be anonymous.
The algorithms are 1024-bit ElGamal for key exchange and signatures, and Blowfish for bulk encryption. But everyone’s private key is stored on the HushMail server, protected in a passphrase. This means that one weak link is likely to be the passphrase; it’s the only protection you have against someone who has legal or illegal access to the HushMail server. (The current beta—August 99—doesn’t let you change your passphrase, although they promise the feature in the future.)
Another weak link is the Java applet. When you download it, you have no idea if it is the correct applet. Yes, the source code is public, but that doesn’t help when you are at a public Internet terminal trying to encrypt or decrypt private e-mail. A Trojaned Java applet can do all sorts of damage, and there is no way to know. Sure, you use an SSL connection between your computer and the HushMail server, but if you don’t actually check the details of the received certificate, you have no idea who you are connected to. HushMail is considering writing something to verify the applet automatically, but then how do you trust the verifier?
This is actually a major problem. The applet can be signed, but who signed it? Even if you check the certificate, the typical browser permits a dozen different PKI roots by default, and any one of them can issue a forged certificate. This means you have to trust them all. And you have to trust that a Trojan didn’t drop a phony certificate into your browser. Note that a downloaded verifier can never solve this problem; it just turns the “how do I trust the applet” question into “how do I trust the verifier.”
And a third possible weakness is the location of the HushMail servers. Although the company is based in Anguilla, the servers are located in Canada. Presumably Canada is more susceptible to legal attacks. And remember that the security depends on the physical protection of the HushMail server.
All in all, though, HushMail seems like a reasonable implementation of the idea. The company seems clued; they have a reasonably informative Web site, and respond promptly to security questions.
ZipLip <https://www.ziplip.com/zlplus/home.jsp> is different. Both parties do not need an account to communicate. The sender logs onto the ZipLip Web site and, using SSL, sends a message to someone else. ZipLip then sends the recipient a message telling him that your message is waiting. The recipient then logs onto ZipLip to receive the message. Encryption, outside the two SSL connections, is completely optional.
ZipLip won’t identify the encryption algorithm used, which is enough to discount them without further analysis. But they do something even stupider; they allow the sender to create an encryption key and then give the recipient a “hint” so that he can guess it. ZipLip’s own Web site suggests: “The name of the project we’re working on,” or “The restaurant where we had dinner last night.” Maybe there are 100,000 restaurants, so that’s a 17-bit key.
The threats here are serious. Both the sender and receiver need to verify their SSL connections, otherwise there is no security. The ZipLip server is a major attack target, both because many messages will not be encrypted, and because those that are will have keys weakened by the requirement that both parties remember them.
On the plus side, ZipLip claims a policy of deleting all mail 24 hours after delivery, which provides a level of lawyer-proofing that HushMail does not have…if they implement it properly.
YNN-mail <http://www.ynnmail.com> is barely worth this paragraph. They encrypt stored messages with a 40-bit key, and don’t use SSL when you sign up and send them a long-term password. Snake-oil if I’ve ever seen it.
And I just heard of another, ZixMail <http://www.zixmail.com/> [link moved to http://www.zixit.com/]. I didn’t have time to examine it in depth, but the FAQ—look at their wishy-washy comments on encryption—makes it sound like real snake oil, too.
Web-based encrypted e-mail is less secure than PGP-encrypted e-mail (or S/MIME e-mail) for a few reasons. One, the constant interaction between the communicants and the server leaves more opportunity for man-in-the-middle attacks, Trojan horses, etc. Two, SSL-based authentication is more vulnerable to spoofing, since almost no one ever bothers to check the details of received certificates and there is no revocation mechanism in place. And three, there are some very attractive attack targets: servers with large collections of secret e-mail and potential decryption keys. Certainly Web-based encrypted e-mail is better than unencrypted e-mail, but I’d stick with PGP or S/MIME if possible.
This essay was written with input from Fred Wamsley.
Categories: Business of Security, Computer and Information Security