The Importance of SSL for Exchange Servers
Written by Paul Cunningham on February 18, 2010
There have been many times in the past when I have started a project for a new customer and discovered that they are not using SSL for their email servers. Usually after a brief discussion they agree to implement SSL in the new system we are installing for them.
Occasionally they agree but insist on doing it in a less than ideal manner. And sometimes, although rarely, they decline our advice and continue without SSL.
What is SSL?
SSL stands for Secure Socket Layer and is an encryption protocol that secures communications between two parties over insecure networks such as the internet. Although still commonly referred to as SSL its new name is actually TLS (Transport Layer Security) which more accurately describes its role of securing communications at the Transport layer of the OSI model (eg, the TCP protocol).
In an SSL/TLS secured communication the two parties (e.g. a web server and a web browser) agree on how to secure the connection they are establishing.The server sends the client its public encryption key (sometimes known as an SSL certificate) which the client then verifies against its own list of trusted certification authorities. Once it has verified the key the client will generate a random number, encrypt it with the server’s public key, and send it to the server. The public key encryption ensures that only the server can read the random number.
Contrary to popular assumption it is not the server’s public key (or SSL certificate) that is used for the encrypted connection, rather it is only used to secure the initial exchange of the random number. The random number is then used to encrypt and decrypt the actual connection traffic.
Why is SSL important for Exchange Servers?
Exchange servers come with useful remote access features such as Outlook Web Access, Outlook Anywhere, and ActiveSync. These features allow your users to access their email from any location with an internet connection by using a web browser, their laptop, or a mobile device such as a smartphone.
This convenience carries with it some security risks, the most obvious being the risk of password credentials being compromised.
Operating any of these remote access services without SSL means that the connection, including password credentials, occurs over an unsecured HTTP connection. HTTP is the protocol that most websites use. It is fast, stable, and works through just about any firewall. But HTTP has no built in security. Every bit of data sent over HTTP is unencrypted, so when passwords are sent over HTTP they are sent “in the clear”, vulnerable to network sniffers.
Because so much of this remote access occurs from untrusted locations such as free wireless hotspots, it is critical that SSL be used to protect this traffic.
Recommendations for using SSL
Here are some recommendations for using SSL to secure your Exchange server’s remote access features.
- Make it mandatory, not optional. If you enable SSL but also still allow unencrypted HTTP you make it possible for an unwitting user to connect over the insecure method.
- Use it internally as well as externally. It is tempting to allow non-SSL connections from locations within your own corporate network but this is still risky. Some security professionals consider all network segments to be untrusted.
- Use a commercial Certificate Authority instead of a private one. You may be tempted to save money on SSL certificates by installing a private CA and issuing your own, but this causes more headaches than it is worth. Your private CA will not be trusted by devices such as smartphones or non-corporate computers, and will result in SSL warning messages that confuse users and can make some applications refuse to connect at all. Because the SSL warning messages are also often found with phishing sites like fake banking sites it is not a good idea to get your users used to ignoring them.
Posted in Exchange server | 2 Comments »



March 1st, 2010 at 6:13 pm
Good advice – we specify SSL Certificates for all our Exchange setups.
I was interested in your “Use it internally as well as externally” – how do you achieve this? Using a multi-name SSL Certificate (Internal and External) or a DNS technique perhaps?
March 3rd, 2010 at 1:37 pm
Hi Richard, yes you can use multi-name SSL certs. The term is Subject Alternative Names or SAN for short.