E-Mail Made in Germany, NSA scandal, Warning for mail server operators etc etc etc... Encryption is currently on everyone's lips. But it's not enough just to quickly attach a certificate to the Exchange server. If you want to have a secure environment (according to the current definition...), you have to think about a few more things. One consideration should be the certificate itself and the various encryption options. Also PFS (Perfect Forward Secrency) is currently a hot topic. To test its certificates, SSLLabs offers a free test that checks the certificates and their checkpoints.
https://www.ssllabs.com/ssltest/
Here is an example of an Exchange 2013 on Windows Server 2012 R2 that is directly accessible via NAT on the Internet:
Der nächste Screenshot zeigt das Ergebnis mit einem Zertifikat welches SHA2 (SHA256) nutzt, das Zertifikat stammt ebenfalls von einer internen CA, das rote gemeine „T“ bleibt, ist auch völlig OK, aber zumindest ein Fehler weniger:
And now once with a valid certificate from a public CA. I used GeoTrust because GeoTrust issues SHA2 certificates for 30 days for testing purposes
https://www.geotrust.com/de/ssl/free-ssl-certificate/
Here is an example of a server that does not use PFS (and also does a few other things wrong), in this case it is a Server 2008 R2 with a relatively old certificate. The certificate comes from a public CA and is therefore valid, but uses SHA1. The server also offers old SSL versions.
However, the rating can still be improved with a few optimizations, but this will also lock out a few older clients, but everyone else will use PFS:
The rating rises slightly as a result:
It is therefore always a compromise between safety and convenience (or which devices are supported). Here is a description of how an A+ rating can be achieved:
I think an A+ rating in connection with Exchange is hardly enforceable, because most clients will really be locked out.
With a public certificate and reasonably up-to-date clients, however, an A rating including PFS can be achieved without major restrictions, which is accompanied by an increase in security:
As mentioned above, I use a public certificate that uses SHA2 (SHA256) and a key length of 2048 bits
A key length of 4096 bits leads to a significantly higher CPU load, which the Exchange server can easily cope with, but smartphones either no longer manage this or do not support it at all.
However, the certificate alone is not enough: Exchange uses the functions of the operating system for encryption. The operating system (in my case Server 2012 R2) therefore specifies which protocols, cipher suites and key exchange procedures the client can use.
The handshake between client and server determines which cipher suite is used. The client and server try to negotiate the best cipher suite that is supported by both. The cipher suite determines which protocol, which hash algorithm and which key exchange procedure is used.
To force clients to use PFS (Perfect Forward Secrency), the respective operating system can be adapted so that it only offers cipher suites that support PFS. The IIS Crypto tool helps to set the appropriate settings:
https://www.nartac.com/Products/IISCrypto/Default.aspx
Um die Einstellungen für PFS wie im Screenshot oben gezeigt vorzunehmen, wird einmal auf „Best Practices“ geklickt und dann RC4, Triple DES und AES128 als Cipher abgewählt. Zusätzlich werden die letzten 4 Cipher Suiten deaktiviert.
Restart the server and only PFS will be used. This example is of course dependent on the respective environment. For my tests, I simply forwarded port 443 to the Exchange server. If a web application firewall or a reverse proxy is used, the corresponding settings must of course be made there.