Overview of How to Secure Messages

There are several ways to solve the problems mentioned previously. Let's take a rather high-level look at some of these solutions:

• Non-SMTP system connections: Use GroupWise-to-GroupWise or GroupWisetoforeign systems connections, effectively removing the need to use the SMTP protocol. Chapter 15, "Administering Multiple GroupWise Systems," and Chapter 34, "Creating a GroupWise-to-GroupWise Communication Solution Across the Internet," explain how to accomplish this task.

• Secure SMTP: Use Secure SMTP to set up a SSL-ized SMTP session between two SMTP servers, thereby creating a secure SMTP channel without any user intervention.

• Web-based systems: The sender's message is captured by an appliance, and a secured HTML link is sent instead to the recipient. An example of such a product is Message Protect from IntelliReach (www.intellireach.com).

• Securing individual messages: Use specialized additions to SMTP such as PGP or S/MIME to secure individual messages, which requires end-user participation.

These are just some of the solutions; there may well be others.

Non-SMTP System Connections

A GroupWise environment is internally secure from day one after setup. Security has always been one of the most important features of GroupWise, and there is really no way a normal end user or even a big-time hacker could simply access items in the message stream or the message store. Every bit of information in the message store is encrypted, and messages sent between post offices via domains are encrypted with a proprietary 40-bit encryption. And as described in Chapter 27, "Securing Your GroupWise System via SSL," GroupWise offers the capability to enhance this security by using 128-bit SSL encryption between all GroupWise components. Figure 30.3 shows how two GroupWise systems can speak securely to one another over the Internet.

Figure 30.3. GroupWise-to-GroupWise connections via the Internet can be secure with SSL

Predefined GroupWise-to-GroupWise Connections

If both the sending and the receiving environments are GroupWise systems, you can easily configure a foreign domain connection, enabling these environments to transfer messages directly via MTA-to-MTA connection. The advantage of a predefined link is that you can also exchange address book information automatically. Setting up such a link is fairly simple and is described in Chapter 15, "Administering Multiple GroupWise Systems."

Auto-Detected GroupWise-to-GroupWise Connections

Even without a predefined connection, an MTA-to-MTA connection can be established automatically, because with version 5.x, Novell can use Dynamic Internet Link to detect the possibility of connecting to a foreign MTA. If you put the right information in the DNS, your MTA will be able to connect to a foreign MTA and exchange native GroupWise messages, which are of course encrypted by default. You can find more information in Chapter 34.

Predefined GroupWisetoForeign Systems

Another alternative for delivering secure and identity-checked emails is to use a high-level gateway between the two disparate systems, for example, from the GroupWise Gateway to Exchange or Domino. Although the tools are there and are relatively easy to set up, this will require diligent research and information exchange with the email administrators at the other side and might therefore be too difficult to implement.

Reality Check

It's not a GroupWise-only world yet! Because so many organizations haven't made the decision yet to implement GroupWise as the best messaging system ever, it's important to cover other ways to solve the secure messaging problem. This chapter focuses mainly on the use of the S/MIME standard, but there are other options as well, such as PGP.

Note

In earlier versions of this book, we also discussed PGP. However, PGP no longer creates solutions specific to third-party clients. Instead, PGP makes an API available for third parties to use if they so desire. At the time this book was written, Novell has not written to the PGP API.

Although these non-SMTP high-level system connections solve the second problem by setting up a secure connection between the systems, not all of them completely solve the first problemmaking sure that the sender's identity is checked. This can really be solved only with the predefined connections, all the while trusting each other's environments to be secured against this kind of fraud.

Securing the SMTP Channel

Theoretically, it would be rather simple to encrypt the complete SMTP session in between two SMTP servers. And the good news is that GroupWise 6.5 and 7 already support this functionality.

The ESMTP, or Enhanced Simple Mail Transfer Protocol, has some options to exchange information regarding capabilities of the two connecting ESMTP servers during the initial handshake. Based on the capabilities of both SMTP servers, the GWIA will refuse to accept SMTP sessions that try to transfer messages of invalid recipients and/or messages above a specified size. The two ESMTP servers can also detect if they both support SSL-ized SMTP sessions and will try to establish an SSL connection to transfer the SMTP message via this secure SSL channel. This protocol is also referred to as StartTLS. Figure 30.4 illustrates how StartTLS is incorporated into SMTP mail.

Figure 30.4. Securing messages via ESMTP and StartTLS

In a perfect world, this approach would indeed solve at least the second problem, by encrypting the complete SMTP session and thus the email within that session. However, only a very small percentage of the current SMTP servers around the world can support this mechanism or are configured correctly to use it. And even so, you still haven't solved the second problem, because you can't ensure that no one within the sender's environment hijacked a sender's identity (imagine a big university with lots of students mimicking their professors' identity, raising their grades by simply sending some relevant messages).

Enhanced SMTP Can Offer Secure Messaging with StartTLS

With the advent of Enhanced SMTP (ESMTP), we now have the capability of securing Internet mail connections by using SSL or Transport Layer Security (TLS). Our GWIA supports SSL and TLS, and the setup is just as simple as it is for the other agents, as described in Chapter 27. The only issue here is that you have control over only your end of the SMTP transaction. Both ESMTP servers (yours and the one at the other end) must support TLS for messages to get encrypted. After it's set up, your GWIA will send all messages using TLS if the other host supports the protocol; otherwise, the message will be sent using plain SMTP.

Setting Up Secure Messaging with TLS

Well, this is an easy one. In Chapter 27 we explained what you need in order to set up your SSL environment for GroupWise. To make this really work well, there is one thing you need to make sure of: The certificate being used by the GWIA needs to include the hostname as seen from the Internet. Also, the certificate should preferably be signed by an official (external) certificate authority so that the other side can check the validity of the certificate by looking at the trusted root of your certificate. You can find more about how to get such a certificate in Chapter 27. Let's just assume that you have a valid certificate; here are the steps to set it up:

1.	Create a CERT directory off of the Domain\WPGATE\GWIA GATEWAY DIRECTORY.
2.	Store both the *.B64 and the *.KEY file in this directory.
3.	From ConsoleOne, bring up the properties of GWIA, and from the GroupWise tab select SSL Settings.
4.	Complete the fields, specifying the certificate file and key file. (See Figure 30.5.) Figure 30.5. Specifying the certificate and the key file
5.	Click on Set Password and enter the case-sensitive password. Click Apply to save the GWIA properties.
6.	From the GroupWise tab for GWIA, select Network Address. Select Enabled under SSL for SMTP. (See Figure 30.6.) Click OK to save the changes and exit the GWIA properties screen. Figure 30.6. Enabling SSL on the SMTP sessions
7.	Restart GWIA.

You have now successfully set up secure messaging with TLS.

Test Secure Messaging with TLS

To test for TLS support, use any telnet client you have to verify that your GWIA or any other SMTP host supports TLS. These steps use the Windows 2000 standard telnet client:

1.	Start the telnet client from a DOS command prompt window and issue the command telnet.
2.	From the Microsoft Telnet> prompt, type OPEN Hostname GWIA server 25 (replace Hostname GWIA server with the registered hostname of the SMTP server), and press Enter.
3.	After a few seconds, you should get a response with the identity of the host. Then issue the command EHLO. Depending on your telnet settings, the command you type may not be visible on the screen. If you get the response message 250-STARTTLS, the host supports TLS.

Whenever your GWIA connects to another ESMTP supporting TLS, the ESMTP will be protected by SSL.

Working with Web-Based Systems

When looking at Web-based secure messaging systems, you have to remember that market share is still small. Most solutions are single-vendor solutions. For example, http://www.hushmail.com is a great PGP Web-based solution, but many organizations want to control such Web-based systems within the boundaries of their own IT environments and quite often don't want to host it externally. When you're looking at GroupWise environments, an enhancement of GroupWise WebAccess with PGP capabilities would be far more suitable than such external Web-based solutions.

Note

A few nonmainstream Web mail services offer secure messaging, for example, Hushmail (www.hushmail.com) and Safe-Mail (www.safe-mail.net). Hushmail uses a Java applet to create PGP encrypted email. Safe-Mail offers S/MIME web-based services, including POP support.

Securing Individual Messages

You can see now that most of the other methods don't solve all of your problems. It looks as though you have to involve the users and give them some tools. First, let's take a closer look at the two problems. This section first discusses some details of secure mail solutions.

Encrypted Messages

A message can be encrypted using various techniques; for example, both S/MIME and PGP use private and public keys. The private key is stored in the sender's workstation environment and used to encrypt the message. The recipient can decrypt the message by using the sender's public key, to which she somehow needs to have access. This can be via a kind of lookup mechanism, for example based on LDAP, or by simply exchanging public keys and storing them in the recipient's environment.

A message is encrypted via an algorithm that generates a session key that is combined with the recipient's public key, transferred via the Internet, and decrypted by using the recipient's private key and the session key. This effectively means that as long as the keys aren't compromised, nobody in between the sender and the recipient can have access to the content of the message.

And now you have an interesting problem: Really nobody or nothing, no processes at all, can touch this message, not even the corporate virus or content scanner! These messages will reside within your message store and travel through your message-flow like real untouchables. Both the sender and the receiver will have to rely on desktop virus scanning to process the unencrypted messages whenever the recipient or the sender opens such a message.

The big differences between S/MIME and PGP lie in how keys are generated, how these keys are validated, and where they are stored. We will show more details on how S/MIME handles keys in the upcoming sections.

Digital Signatures

If you want to make sure that the users are who they say they are, you can do some basic checking on receipt of every SMTP message. Because most SMTP servers don't even do a basic reverse address lookup check (as described in Chapter 16, "Internet Addressing"), they really don't have any idea who the originator of a certain message is. Research has shown that most SMTP servers (estimated at 95%) don't even use this simple check. And, yes, if you turn it on in your own environment, you will reject emails from badly configured sender environments, so even if you're aware of the problem you might not be able to use this important feature.

Really, for the intents and purposes here, this check isn't good enough, because although it will make sure that you're connecting to the right SMTP server, you still don't know whether the people on the other end are the lawful owners of the mailbox or whether they are mimicking somebody else at the sending site.

Digital signatures can take away a lot of this discomfort and, if implemented and used properly, can give you an almost 100% certain guarantee that the sender (and the receiver) is genuine. The idea is based on the exchange of public keys and a method to check the validity of these keys against a certificate authority (CA, used by S/MIME and PGP) or a Web-of-Trust (used by PGP). When an email is sent, the digital signature is added on request or automatically, and the receiving email client can use this information to verify the validity of the signature and thus the identity of the sender.

Of course, you should realize that encrypted or digitally signed email cannot be handled by just any email client. For example, Gartner (www.gartner.com) mentions in its whitepaper "Email Encryption: Multiple Strategies Needed" that almost 65% of the business recipients use email software that could be configured to handle S/MIME messages. We will cover this aspect in more detail later.

Three Important Procedures

From an administrative viewpoint, there are actually three important tasks associated with the setup and maintenance of a secure messaging environment. You will have to manage your keys and certificates. These are the tasks you must take care of:

• Create: Each user should somehow be able to get a copy of his private and public key. These keys are generated either centrally within a directory service in what is called a PKI (Public Key Infrastructure) in S/MIME or individually (PGP).

• Distribute: After the keys are created, the user must be able to store them in some kind of secret store. S/MIME most often uses the locally installed certificate, for example, the Windows Certificate Store that is an integral part of Internet Explorer and/or Windows 2000/XP. With PGP, this is a so-called PGP key ring.

• Revoke: It's very important that keys be able to be revoked, either because they're compromised or because they become invalid for other reasons. For example, when users leave the organization, they should not be able to send digitally signed emails on behalf of the organization. Within S/MIME this can be handled by mechanisms like the CRL (Certificate Revocation List) and the newer OCSP (Online Certificate Status Protocol), which are briefly covered later, whereas PGP has some other mechanisms to handle revocation.

With all of these differences and similarities between S/MIME and PGP, it's not so strange that larger organizations implement secure messaging based on S/MIME.