E-Mail Made in Germany, NSA-Skandal, Abmahnung für Mail Server Betreiber usw usw usw… Verschlüsslung ist zur Zeit in aller Munde. Aber es ist nicht damit getan nur schnell irgendein Zertifikat an den Exchange Server zu hängen. Wer eine sichere Umgebung (nach der aktuellen Definition…) haben möchte, muss sich ein paar mehr Gedanken machen. Ein Gedanke dabei sollte das Zertifikat selbst und die verschiedenen Verschlüsselungsmöglichkeiten sein. Auch PFS (Perfect Forward Secrency) ist aktuell ein Thema. Um seine Zertifikate zu testen, bietet SSLLabs einen kostenlosen Test an, der die Zertifikate und deren Schachstellen abklopft.
https://www.ssllabs.com/ssltest/
Hier ein Beispiel von einem Exchange 2013 auf Windows Server 2012 R2 der direkt via NAT im Internet erreichbar ist:
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:
Und jetzt einmal mit einem gültigen Zertifikat einer öffentlichen CA. Ich habe GeoTrust verwendet, da GeoTrust SHA2 Zertifikate zum Testen für 30 Tage ausstellt
https://www.geotrust.com/de/ssl/free-ssl-certificate/
Hier mal ein Beispiel für einen Server der kein PFS nutzt (und auch ein paar andere Dinge falsch macht), in diesem Fall ist es ein Server 2008 R2 mit einem relativ altem Zertifikat. Das Zertifikat stammt zwar von einer öffentlichen CA und ist somit gültig, nutzt aber SHA1. Der Server bietet zusätzlich alte SSL Versionen an.
Wie dem auch sei, mit ein paar Optimierungen kann das Rating noch verbessert werden, allerdings werden damit auch ein paar ältere Clients ausgesperrt, dafür nutzen aber alle anderen PFS:
Dafür steigt das Rating leicht:
Es ist also immer ein Kompromiss aus Sicherheit und Komfort (bzw. welche Geräte werden unterstützt). Hier steht beschrieben wie ein A+ Rating erreicht werden kann:
Ich denke ein A+ Rating in Verbindung mit Exchange ist kaum durchsetzbar, denn so werden wirklich die meisten Clients ausgesperrt.
Mit einem öffentlichem Zertifikat und halbwegs aktuellen Clients lässt sich aber ohne große Einschränkungen auf ein A-Rating inkl. PFS kommen, was mit einem Sicherheitsgewinn einhergeht:
Wie etwas weiter oben bereits erwähnt verwende ich ein öffentliches Zertifikat, welches SHA2 (SHA256) und eine Keylänge von 2048Bit nutzt
Eine Keylänge von 4096Bit führt zu deutlich mehr CPU-Last, das mag der Exchange Server noch locker verkraften, Smartphones allerdings schaffen das entweder nicht mehr, oder unterstützen es erst gar nicht.
Nur mit dem Zertifikat ist es aber nicht getan: Zur Verschlüsselung greift Exchange auf die Funktionen des Betriebssystems zurück. Das Betriebssystem (in meinem Fall Server 2012 R2) gibt also vor, welche Protokolle, Cipher Suiten und Key Exchange Verfahren der Client nutzen kann.
Der Handshake zwischen Client und Server bestimmt dabei, welche Cipher Suite zum Einsatz kommt. Client und Server versuchen dabei die beste Cipher Suite auszuhandeln, die von beiden unterstützt wird. Die Cipher Suite bestimmt welches Protokoll, welcher Hash-Algorithmus und welches Key Exchange Verfahren zum Einsatz kommt.
Damit Clients gezwungen werden PFS (Perfect Forward Secrency) zu nutzen, kann das jeweilige Betriebssystem so angepasst werden, dass es nur noch Cipher Suites anbietet, die PFS unterstützen. Das Tool IIS Crypto hilft dabei die entsprechenden Einstellungen zu setzen:
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.
Server neustarten und schon wird nur noch PFS genutzt. Dieses Beispiel ist natürlich von der jeweiligen Umgebung abhängig. Ich habe für meine Tests einfach Port 443 auf den Exchange Server weitergeleitet. Wenn eine Web Aplication Firewall oder ein Reverse Proxy genutzt wird, muss die entsprechenden Einstellungen natürlich dort vornehmen.