Checking security protocols and ciphers on your Exchange servers

Microsoft states that Exchange 2010 and 2013 are secure out of the box. With this they mean that every traffic coming in and out of Exchange is one way or another encrypted. Whether this is web traffic or specific for SMTP. Even IMAP and POP are enabled with mandatory encryption (although the services are disabled by default).

However the past few months we’ve had reports that specific encryption protocols and ciphers (algorithms used for encryption and decryption) used aren’t considered safe due to bug or progress in the field of decryption (by brute force). Remember FREAK, Heartbleed, POODLE, Logjam and in somewhat related form the recent IIS exploit which could BSOD an IIS server etc.. This is why it is very prudent to verify your Exchange servers whether they use safe protocols and ciphers.

So, how can you check your servers? There are websites that can check your webserver like those from Qualys SSL Labs or DigiCert. But these only check HTTP traffic and only of published servers. If you have a reverse proxy (TMG, WAP or other) or a Load Balancer/Application Delivery Controller, you will only test those endpoints. The actual Exchange servers and protocols like SMTP aren’t checked.

Luckily there are some free available online tools that can do this kind of testing as well. Running on Windows we have SSLScan and Win32 OpenSSL.

Running SSLScan is easy. Install it on a Windows server inside your network and use:

sslscan webmail.contoso.com

Or if you do not want to see protocols and ciphers that fail, use

sslscan --no-failed webmail.contoso.com

If you have multiple namespaces (for instance per Exchange Protocol such as AutoDiscover, Exchange Web Services etc..) or multiple virtual directories for a specific protocol (OWA or Exchange Control Panel). I would check every internal and external URL separately, even thought the protocols and cipher configuration is used serverwide.

The section “Supported Server Chiper(s)” shows all ciphers and protocols that are usable. The section “Preferred Server Cipher(s)” shows the first protocol and cipher that will be used in the negotiation. If the client supports this protocol/cipher it will be used, otherwise during negotiation other ciphers (less strong) will be tried.

For separate Exchange servers you will have to use the FQDN. Luckily this will not result in a certificate mismatch error and the tool will still check the server. You will have to check each server separately. And do not forget to check any proxy/firewall/load balancer, basically anything that does something with the SSL session, as well. Depending on the configuration it will decrypt incoming traffic and encrypt it again towards the Exchange servers (SSL bridging) or not (SSL Offloading). Either way, the whole chain from the initial client entry point up to the Exchange Servers needs to be checked.

Why even Exchange servers, even if the secure sessions from clients will not directly connect to Exchange? I like to have a consistent security policy through the whole chain, furthermore it’s possible for some protocols the route from client to Exchange is different (i.e. internal applications communicating with Exchange servers directly). Best to be thorough IMHO.

All client-server protocols in Exchange use the Secure Channel (or schannel) as a security support provider, this is at the Windows OS level and is not Exchange specific. Exchange uses IIS for HTTPS, and that in turn uses schannel. For SMTP, IMAP and POP Exchange now has it’s own protocols, but those also use the schannel configuration. This means that your supported protocols and ciphers list from HTTP traffic is also used by SMTP, IMAP and POP.

However, those protocols could have another certificate bound to it or as stated earlier, have a different client-server route. So, it’s best to check them out as well, from a internet published FQDNs but also per server FQDNs.

This is also possible with SSLSCAN, however where HTTPS traffic is implicit (the secure connection is always setup without explicit commands sent by client), SMTP, IMAP and POP can be explicit and thus require the use of STARTTLS commands.

SMTP on port 25 but especially the client submission SMTP on port 587 require STARTTLS before a secure connection is set. You can do this by adding the -STARTTLS parameter in SSLSCAN and adding the port to the server address.

In my lab case this resulted in this output show in Figure 2. Note that the protocol and ciphers are identical as those from HTTPS. However, looking at the Signature Algorithm and Subject Alternative Name it becomes clear this is another certificate, using SHA1 and it’s self-signed.

Note: if you explicitly want to see which protocols and ciphers are tested and not supported by your server, ommit the –no-failed parameter. I’ve added this parameter in these examples in order to keep the screenshots more readable. If omitted, you will see it also tests SSLv2 and SSLv3, but only TLS1 in general (and not explicitly TLS11 and TLS12).

Testing IMAP/POP is obviously only required when the services are enabled and in use. Unfortunately SSLSCAN cannot test IMAP or POP. Luckily OpenSSL can, unfortunatly it’s syntax is a bit more complex (SSLSCAN actually uses OpenSSL bit, and is sort of a frontend for it).

Checking Secure IMAP (explicit) on port 143:

openssl s_client -connect webmail.contoso.com:143 -starttls imap

Checking Secure IMAP (implicit) on port 993:

openssl s_client -connect webmail.contoso.com:993

Checking Secure POP (explicit) on port 110:

openssl s_client -connect webmail.contoso.com:110 -starttls pop3

Checking Secure POP (implicit) on port 995:

openssl s_client -connect webmail.contoso.com:995

Note that even thought the recommendation for both IMAP and POP is to use the explicit form, both types are active on you Exchange servers when you enable the corresponding services.

The output for explicit Secure IMAP is show in Figure 3.

Figure 3. OpenSSL output for Explicit STARTTLS IMAP on port 143

With the current syntax, you only see the protocol and cipher that is actually used, not an overview like SSLSCAN. But it is clear that IMAP is currently using TLS (and not SSLv3) and the preferred cipher as found with SSLSCAN.

You can also check explicitly whether SSL3, TLS10, TLS11 or TLS12 are availble by adding the parameter -ssl3, -tls1, -tls1_1 or -tls1_2 to the OpenSSL syntax.

Figure 4. Example of an GPO disabling SSLv3 and rearranging cipher order and ommiting unsafe ciphers.

If you encounter unsafe protocols and/or ciphers on your Exchange servers, there are several ways to mitigate this. You can use the IIS Crypto tool. As you might have more Exchange servers or other servers with IIS, you could consider using an GPO in order to distribute those settings via the SSL Cipher Suite order and/or regkeys disabling SCHANNEL protocols. See figure 4 for an example. The cipher order shown was derived from Qualys SSL Labs best practices dated december 2014 and was used in all examples in this post. They are probably out-dated (this is pre-LogJam).

Do consider that older clients that will not be updated (Windows XP, Android devices etc..) could be excluded from connecting to Exchange if you set the level of security to high for those older systems. Take this into consideration when upping your security levels.

2 comments

Depends on what you consider security, it has many aspects (prevention of data loss or leakage, availability to name a few).
Obviously protection from malware and spam is important, a good filter is crucial whether it’s cloud based, appliance or a application integrated in Exchange. Spoofing is another issue, that can be limited by using DMARC (and DKIM altough Exchange doesn’t support that natively) and a correct SPF record.
If you have a specific concern, just let me know and I’ll see if I can find usefull resources or write a post myself.