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 FREAKHeartbleed, 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.

Anyway, the result will look like the depiction in Figure 1:

SSLScan2

Figure 1. SSLSCAN result of a lab environment running Exchange 2010 SP3RU9 running on Windows Server 2008 R2

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.

On a side note, under Signature Algorithm you can check whether the certificate chain is still using SHA1 (which will not be accepted after 1 january 2017 if your Windows devices are up-to-date). Obviously the RSA Public Key shows the bit length used (at least 1024, as lower bit lengths are no longer accepted by fully updated Windows devices. Having said that, the current best practice is to go for at least 2048).

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.

Checking SMTP with STARTTLS:

sslscan --no-failed --starttls webmail.contoso.com:25

Checking Client Submission SMTP with STARTLS:

sslscan --no-failed --starttls webmail.contoso.com:587
SSLScanSMTP2

Figure 2. SSLSCAN output after checking SMTP Client Submission on port 587 with STARTTLS

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 110

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.

Please note that SMTP only supported TLSv1.0 until Exchange 2010 SP3 RU9 and Exchange 2013 CU8, after these updates TLSv1.1 and TLSv1.2 should also be supported.

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

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.

 

UPDATE 28th july 2015: Yesterday the Exchange Team posted a blog post that covers the SSL/TLS best practices regarding Exchange Server. So, that blog and this one complement each other perfectly 🙂

2 comments

  • Shambhu Sharma

    What else can we include in security checking for exchange servers?

    Reply
    • Dave Stork

      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.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *