Page 99 - Mercury Manual.book

Using SSL to secure connections 94
SSL Overview

Using SSL to secure connections

SSL Overview

Mercury uses Peter Gut- Mercury/32 has comprehensive support for secure connections using the Internet SSL/TLS
mann’s high-security protocols. "SSL" (Secure Sockets Layer) and "TLS" (Transport Layer Security) are standards
cryptlib library for all its
cryptographic support, in- for transferring data across Internet connections in an encrypted format to ensure security.
cluding SSL.
Mercury supports both SSL and TLS so from this point on we'll use the term "SSL" to mean
both. The way these protocols are implemented means that a client and a server can negotiate
an encrypted transaction in a way that prevents the data from being intercepted in transit even
if the intruder can see the entire session.
In Mercury/32, the MercuryS STMP server module, MercuryP POP3 server module and the
MercuryI IMAP4 server module all have support for SSL, and it is configured the same way
in each case. The instructions in this section apply to all these modules. The MercuryC and
MercuryD client modules also support SSL connections, but require only a single configura-
tion switch to enable SSL – see the specific sections for each module in this manual for more
information.

Enabling SSL support

There are three steps to enabling support for SSL in a Mercury/32 server protocol module:

Step 1: Enable advertising of the protocol

Step 2: Install a certificate the server can offer to clients connecting via SSL

Step 3: [Optional] Decide whether you will allow users to login without using SSL.

Step 1 is easy: in the configuration dialog for the protocol module, switch to the page called
"SSL" and check the control labelled Enable support for SSL/TLS secure connections. This
tells Mercury that it can advertise the availability of SSL services to clients when they con-
nect to it. If you do not enable this control then the protocol module will neither advertise the
availability of SSL services, nor will it accept attempts to establish SSL connections.

Step 2 is also easy in Mercury, but it needs a little explanation. When an SSL connection is
established, the server is required to supply a certificate to the client: a certificate is a special-
ly formatted piece of data that is intended to prove that the server is in fact who it claims to
be: the server is required to provide a certificate even if the proof of identity is not particularly
important. You can obtain certificates from a Certification Authority, such as Thawte or Ver-
isign, but the process is complicated and expensive: what's more, for SSL connections to mail
servers, the proof of identity that a Certification Authority Certificate provides is typically
not as important as encrypting the data in transit. For this reason, Mercury also allows you to
create a special type of certificate called a self-signed certificate.

A self-signed certificate basically says to the client "This is my name, and you can trust me";
now, you don't have to think about this for very long to realize that this isn't very secure, but
there's another aspect of certificates that compensates for this: every certificate, even a self-
signed one, has a unique attribute represented by a calculation called a fingerprint which is,
in practical terms, impossible to forge. As a result, you can get excellent security even when
using a self-signed certificate by comparing the certificate's fingerprint with the fingerprint