Exploring the SSL modes of Netscape's Messaging and Collabra servers.
Jon Udell
Like many of you, I do a great deal of Internet-enabled work in both locations and elsewhere. The challenge is to find a safe and effective way to extend my work environment beyond the firewall. SSL-enabled (Secure Sockets Layer) applications are one kind of
solution. This month, I've been evaluati
ng the trade-offs involved in running Netscape's mail and news servers in secure mode.
You'd think that secure mail would need no justification. Who wouldn't want to keep personal and business communication private? And yet, although Secure Multipurpose Internet Mail Extensions (S/MIME) technology has been widely available for almost a year and PGP for far longer, I know very few people who routinely encrypt messages using these tools.
Why? It's a hassle. In the case of S/MIME, you have to acquire a personal certificate. Then you have to exchange keys with each correspondent with whom you intend to communicate securely. Then you have to remember to use encryption when sending messages. When some recipients can receive encrypted messages from you but others can't, you have to make complicated adjustments. If you switch from your work browser with a certificate installed to your home browser without one, you have to make more complicated adjustments.
It's no wonder that PGP and S/MI
ME haven't exactly taken the world by storm. The infrastructure that's needed to make using these technologies a no-brainer for most people just isn't here yet.
So Internet mail, which increasingly carries vital business and personal communication that ought to be encrypted, still travels the wires mostly in the clear. It's relayed through a patchwork quilt of intermediate hosts, some of which may have been hacked and may harbor concealed network sniffers that capture mail account names and passwords, or even assemble packets into complete data files.
In the long run, we need to go beyond virtual private networks (VPNs). We must be able to make secure point-to-point network connections to arbitrary locations as easily as phone calls. Applications shouldn't need to know anything about encryption; it should just be a property of the transport layer.
For the next few years, though, we will be stuck with application-specific security protocols. S/MIME is an example of such a protocol, and it's availa
ble now, but it lacks the infrastructure needed for effective deployment. Meanwhile, there's a pressing need for a quick fix. Secure IMAP, though by no means a perfect solution, nevertheless offers some important immediate benefits. So does a closely related technology, secure NNTP.
Netscape's SSL-Enabled IMAP Mail Server
For the past few weeks, I've been trying out Netscape's Messaging Server. Its IMAP capability was what first attracted my interest. I've used POP3 for a few years, but that's a poor solution because I access my mailbox from two or three workstations every day. Since I never know when I'll need a particular message to be in a particular workstation's local message store, I'm in the habit of leaving mail on the server and doing redundant full dumps to each workstation.
It's futile to try to reorganize your local message store under this scenario, since you'd have to repeat all folder-related actions once per client. So I'm a prime candidate for IMAP's server-based folder man
agement.
Netscape's Messaging Server does IMAP with a twist. You can access your mailbox in unencrypted mode on port 143 (comparable to POP3's port 110), or you can fetch and send messages securely on port 993. Secure IMAP is much stronger than APOP, a POP variant that encrypts log-in credentials but not message data.
With secure IMAP, log-in credentials and messages are encrypted. All communication between client and server uses an SSL channel. If your client is Communicator, you'll see the whole-key icon in the message-reading window, just as you do when viewing a secure Web page fetched from an https://URL.
How does secure IMAP compare with S/MIME? They're very different (see the table
"Secure IMAP vs. S/MIME"
). S/MIME's security benefits are far more comprehensive. Once you encrypt a message, it can travel safely over any mailbox-access pathway (POP or IMAP), through any number of relay hosts, to any destination, with no performance degradation.
If every Internet mail
user had a digital ID, and if every user's public key were available in a directory, S/MIME would be unbeatable. Until these conditions prevail, though, secure IMAP can provide a much narrower -- but still valuable -- benefit. It can secure the mailbox-access pathway.
To appreciate the value of secure mailbox access, consider the dilemma faced by a company wishing to deploy Internet mail. How do you set up your mail server? If you put it outside the firewall, the POP and/or IMAP ports are highly vulnerable, as are the log-in credentials and messages traveling across those ports. If you put it inside the firewall, the ports are either left open, creating the same vulnerabilities, or closed, in which case employees can access mail only from their offices. Secure IMAP greatly limits the security risk of outside access to inside mailboxes.
Note that there's no end-to-end encryption with secure IMAP. Employees who communicate with outsiders will still send plaintext messages across the Internet, and those
messages will still be vulnerable to interception. But from a corporate perspective, the communication that most needs protection is communication that occurs within the company. Secure IMAP encrypts these messages far more conveniently than S/MIME can. Users just need to enable the SSL option in the mail client. Administrators likewise just need to turn on SSL in the mail server.
Implementing Secure IMAP
There's a bit more to secure IMAP than just turning it on in the server. As with secure Web connections, the security handshake involves authenticating the server to the client. (The reverse procedure -- client authentication -- is optional; see "Digital IDs," March 1997 BYTE,
http://www.byte.com/art/9703/sec8/art1.htm
.) During server authentication, a secure server presents its d
igital ID to a client.
To enable secure IMAP, therefore, you need to acquire and install a server digital ID. Messaging Server comes with the tools you need to generate a key pair and the document (a certificate signing request, or CSR) that you use to relay your server's public key to a certificate authority (CA) that affixes its digital signature to the key.
For a secure Web server, you typically want to send your CSR to one of the well-known CAs (e.g., VeriSign or Thawte) that browsers are hard-wired to recognize. For secure IMAP (or NNTP), it is not necessary, and arguably not desirable, to use a well-known CA. What's the alternative? You can become your own CA and configure your mail or private news server to use a self-signed certificate.
The advantages of the do-it-yourself CA approach are twofold. First, it can be cheaper, quicker, and easier to stamp out your own server digital ID than to acquire one from a commercial CA. Second, it's somewhat more secure, because only the clients that yo
u configure to recognize your homegrown CA's signature will be able to connect to servers presenting IDs with that signature.
There are trade-offs. Some CA toolkits are free for noncommercial use, notably SSLeay and IAIK-SSL, but RSA Data Security patents prohibit the use of these in the U.S. Shrink-wrapped CA toolkits, such as Netscape's Certificate Server, may or may not prove cost-effective; it will depend on your scale of operations. Then there's the learning curve associated with CA tools.
If you decide to present self-signed certificates to your intranet mail or news users, there's one other hurdle to clear. You have to convince the client software to trust your homegrown CA. If the client is Communicator, there are two ways to do that. Assuming that mycert.cert contains a Privacy-Enhanced Mail (PEM) version of your CA certificate, you can:
Method 1
(server-based): Configure your Web server to map the .cert extension to the MIME type application/x-ca-cert and instruct users to fetch m
ycert.cert into their Web browsers from a URL.
Method 2
(client-based): Configure each browser to map the .cert extension to the MIME type application/x-ca-cert and instruct users to fetch mycert.cert from a URL.
Hybrid SSL/Non-SSL IMAP Service
Once I'd worked through the certificate rigmarole, I fired up Messaging Server, configured Communicator's mail client for secure IMAP, and tried to connect. No joy. The server's log files provided no clue, but eventually I found the answer in a readme file on the Netscape site.
There are actually two mail servers. The normal (unencrypted) one launches from Netscape's server administration interface. However, the SSL-capable SIMAP4-Server must be launched separately from the command line. Why? In Netscape's implementation, you can start a secure mail (or news) server only locally, because at start-up you have to type in your private key's passphrase.
It's a chicken-and-egg problem. You can't start up a secure server remotely, because yo
u can't authenticate over a secure connection until there is a secure connection. As a result, any reconfiguration that requires a server restart can't be done remotely.
When you launch SIMAP4, you're running two servers at once. The unencrypted server listens on port 143, and the secure one on port 993. (Optionally, POP3 service can also be available on port 110.)
This turns out to be an extremely useful configuration. Why? SSL slows things down a lot. Depending on your intranet situation, you may wish to encrypt the mailbox-access pathway internally as well as externally. But if you trust your inside network, it's really handy to be able to give inside users fast unencrypted mailbox access and restrict the performance hit of SSL to just those users who reach in from outside. To enforce this policy, you need to locate your secure mail server on the inside, behind a router or firewall that allows port 993 but denies port 143.
Quite often, of course, an inside user during business hours becomes an
outside user after business hours. The hybrid SSL/non-SSL approach is simple if the user maintains a work machine whose mail client talks to port 143 and a home machine that talks to port 993. In the case of a portable computer, it's a bit more complicated. The user must now redirect the mail client once per boundary crossing. Is there a way to automate this procedure? If someone knows how, please let me know.
Implementing Secure News
Secure NNTP closely resembles secure IMAP. For private staff newsgroups, we are running Collabra Server on the secure news port (563) rather than the default port (119). The certificate procedures are identical, and you can in fact use the same server certificate for Collabra Server as for Messaging Server.
Unfortunately, the hybrid SSL/non-SSL solution is
more elusive
for NNTP than for IMAP, because Collabra Server cannot simultaneously listen on secure and insecure ports. For us, the non-SSL option is a high priority. Most of our privat
e newsgroup usage occurs on a trusted internal network, and the slowdown caused by SSL is quite noticeable.
SSL creates another problem, too. We're avid users of Collabra's HTML features. One of these features, the ability to post messages that refer to external Web content, fails with SSL turned on, because the client refuses to display insecure content (e.g., from a normal Xt URL) in the context of a secure message.
The only solution is to run two Collabra servers, one secure and one not, and replicate between them. Collabra can do this, though, not surprisingly, the setup is even trickier than for a pair of conventional port-119 NNTP servers, which is in itself a notoriously tricky thing to make work. To do SSL/non-SSL replication, you have to tell the two servers about each other's SSL status (see the figure
"Configuring SSL/Non-SSL NNTP Replication"
).
If you're using a commercial server certificate on the secure server, this setup should suffice. But if you add a self-si
gned certificate, as I have been doing, there's another puzzle piece to deal with.
When I turned on replication in both servers, it worked in only one direction. To achieve bidirectional replication, you have to convince
innxmit
, the replication agent on the insecure server, to trust the signature on the server certificate presented by the secure server. After appealing to Netscape for advice, I finally solved this problem by copying the certificate database from the secure server to the insecure one and naming that database in the insecure server's nsnews.conf file.
Whew! This all sounds like a lot of configuration hassle, and indeed it is. Partly that's because IMAP and NNTP are overlapping but fundamentally different collaboration protocols that probably, at this point, should merge. And partly it's because SSL is just plain complex. There's no doubting the benefit of secure mail and news. But I'll grant that not many administrators will be willing or able to jump through all the hoops I'v
e described. Let's hope it gets easier soon.
TOOLWATCH
CookiePal....................$15
Kookaburra Software
San Jose, CA
Internet:
http://www.kburra.com/
This handy utility empowers you to set a cookie policy that's more finely granular than what the major browsers support. CookiePal can accept or reject cookies on a per-site basis.
BOOKNOTE
Web Security: A Step-by-Step Reference Guide
............$29.95
by Lincoln D. Stein
Addison-Wesley Longman
ISBN 0-201-63489-9
Comprehensive analysis and advice from the author of the popular World Wide Web Security FAQ.
| Secure IMAP vs. S/MIME
|
|---|
| Secure IMAP is a narrow solution that can help extend the corporate firewall to encompass remote work locations. S/MIME offers wide-ranging security benefits, but it requires more infrastructure and user training.
|
| Secure IMAP
| S/MIME
|
|---|
| End-to-end encryption
| No
| Yes
|
| CPU overhead
| High
| Low
|
| Administrative overhead
| Low
| High
|
| User-training overhead
| Low
| High
|
| Netscape Messenger vs. Netscape Collabra
|
|---|
| IMAP and NNTP implementations overlap significantly, but not completely. Maybe it's time to merge th
e two into a unified collaboration protocol.
|
| Messenger (IMAP)
| Collabra (NNTP)
|
| HTML/JavaScript content
| Yes
| Yes
|
| Off-line client capability
| Yes
| Yes
|
| Authentication by name/password or client digital ID
| Yes
| Yes
|
| Group-accessible folders
| No
| Yes
|
| Full-text-searchable message base
| No
| Yes
|
| User-reorganizable folders
| Yes
| No
|
| Server-based read/unread message tracking
| Yes
| No
|
| Can run on SSL channel?
| Yes
| Yes
|
| Hybrid SSL/non-SSL
| Easy; single server provides SSL and non-SSL listeners
| Hard; requires replicating SSL and non-SSL servers
|
illustration_link (30 Kbytes)
photo_link (50 Kbytes)
Jon Udell (
jon.udell@byte.com
) is BYTE's executive editor for new media.
Securing Mail and News
