Auftrag erfüllt! Die Migration der Exchange-Umgebung eines Kunden weg von der 2003er-Version wurde erfolgreich abgeschlossen - migriert wurde auf Exchange 2010.
Outlook funktioniert. Der Mailflow ist OK. Webaccess ist OK - natürlich mit einem ordentlichen SSL-Zertifikat abgesichert. Der alte Exchange-Server ist deinstalliert und aus. Der Microsoft Connectivity Analyzer findet, dass alles in Ordnung ist. Projekt beendet und auf geht's zum Rechnung schreiben.
Auftrag erfüllt? Nicht, wenn man es genau nimmt!
EIN SSL-ZERTIFIKAT MACHT NOCH KEINE SICHERHEIT
Ein SSL-Zertifikat bedeutet nämlich noch lange nicht, dass die Kommunikation mit dem Exchange-Server wirklich ordentlich abgesichert ist. Es bedeutet zunächst einmal nur, dass der Browser, mit dem man OWA oder Outlook, das Outlook Anywhere benutzt, einsetzt, jenes Zertifikat nicht beanstandet, welches im IIS installiert ist. Mehr aber auch nicht.
Während die Voreinstellungen mit Windows 2012R2 und IIS 8.5 weitaus besser gewählt sind, so ist der IIS 7.5 unter Windows 2008R2 (der in oben genanntem Setup zum Einsatz kam), was das Thema TLS angeht, eine ziemliche Katastrophe. Hier merkt man sehr deutlich, dass dieses Produkt ein wenig in die Jahre gekommen ist.
Eine kurze Analyse der oben genannten Installation durch den SSL-Server-Test von SSL Labs bringt dieses erschütternde Ergebnis ans Licht:
Protocol Support 0 Punkte und ein Rating F ist hier natürlich erst einmal der wichtigste Punkt, der ins Auge sticht. Was um alles in der Welt ist hier nur los?
Etwas weiter auf der Seite wird das Geheimnis gelüftet:
Der IIS benutzt per Standard-Setup nicht die moderneren TLS 1.2 und 1.1 Verschlüsselungsverfahren. Noch schlimmer: SSL2, das schon seit langem als unsicher gilt, und SSL3, das nun seit kurzem durch die POODLE-Sicherheitslücke ebenfalls als unsicher einzustufen ist, sind beide aktiviert.
EIN KANAL IN DIE VERGANGENHEIT
Dies hat historische Gründe: Als der Windows 2008R2-Server das Licht der Welt erblickte, musste man sich noch um einen gewissen Internet Explorer 6/8 unter Windows XP kümmern. Die alten Protokolle sind nur deshalb noch aktiv, um abwärtskompatibel zu sein. TLS 1.2 kam erst später hinzu und ist per Default nicht aktiviert. Deaktivieren wir also zunächst die unsicheren Protokolle und aktivieren TLS 1.1 und 1.2. Dieser Vorgang ist ausführlich im Microsoft Knowledge Base Eintrag 245030 beschrieben, so dass ich hier nur einen Screenshot der finalen Konfiguration zeige.
Protokoll auf dem Server aktivieren:
Sobald wir mit den Einträgen fertig waren (Sie sehen im Enabled DWORD-Wert für die Servereinstellung des Protokoll Enabled 0 oder 0xffffffff - je nachdem ob man die Protokolle aktivieren möchte oder nicht, sowie und DisabledByDefault auf 0), hat sich das Rating zu unseren Gunsten hin verändert: SSL-Labs vergibt nun ein A-Rating.
Bemängelt wird nur noch, dass unser Server keine Forward Secrecy eingeschaltet hat. Was genau dahinter steckt, sprengt sicherlich den Umfang dieses Artikels; wer hierzu mehr erfahren möchte, der möge sich den sehr guten Wikipedia-Artikel zum Thema PFS anschauen.
Um es einfach auszudrücken: PFS hilft dabei, sogenannte Man-in-the-middle-Attacken zu verhindern, ebenso wie abgehörte Kommunikation nachträglich mit einem gekaperten Schlüssel zu entschlüsseln. Immer wieder wird von Sicherheitsexperten angemahnt, diesen Protokollzusatz zu aktivieren - wie hier vor kurzem von Heise Security.
Das PFS nicht aktiviert ist, liegt an den Verschlüsselungsverfahren, die der IIS mit den oben aktivierten Protokollen standardmäßig nutzt. Der Windows-Server arbeitet bei der Verbindung mit einem Client eine Liste der möglichen Verfahren ab, bis der erste gemeinsame Nenner gefunden wird. Es gilt also diese in eine möglichst effektive Reihenfolge zu bringen; vor allem Chipper mit PFS sollten oben in der Liste stehen, damit sie mit so vielen Clients wie möglich genutzt werden. Hierzu muss in der Registry eine mit Komma getrennte Liste der gewünschten Chipper eingetragen werden. Dies macht man am einfachsten per Powershell mit dem Befehl:
mit dem unter HKLM:SoftwarePoliciesMicrosoftCryphtographyConfigurationSSL0010002 ein Liste der Chipper Reihenfolge erstellt wird. Die PFS Chipper stehen nun ganz am Anfang, damit sich möglichst schnell Server und Client auf einen einigen.
Nach einem Neustart liefert SSL Labs dieses Ergebnis:
Wer nun auf den Geschmack gekommen, ist das Ergebnis weiter zu verbessern, kann zusätzliche Anpassungen durchführen: HASH-Verfahren priorisieren etc. Auch findet sich sicherlich immer jemand, der eine noch bessere Chipper-Liste in petto hat.
Außer Acht zu lassen ist hierbei nicht, dass man immer noch mit den gängigen Browsern und Clients kompatibel zu bleiben hat. Unser Vorschlag beansprucht diese ebenfalls nicht. Allerdings sind uns keine weiteren Probleme mit Clients bekannt.
Da wir uns hier auf einem Exchange-Server befinden, möchte ich zum Abschluss noch hinzufügen, dass nun auch SMTP-Verbindungen, IMAPs etc. mit besseren Chippern und PFS aufgebaut werden. Also mit denselben Mechanismen mit denen große E-Mail-Provider zurzeit als „E-Mail Made in Germany“ werben – mehr steckt nämlich nicht dahinter - als das man endlich PFS und Verschlüsselung entdeckt hat.
Wichtig: Auch Administratoren von Windows-Server 2012R2 sollten über die Registry das SSL3 Protokoll deaktivieren, das der IIS 8.5 per Default noch aktiviert hat.
Über weitere Fragen, Kommentare und Hinweise freuen wir uns selbstverständlich immer.
Ihr Steffen Becker
Quelle und Verweise:
http://support.microsoft.com/kb/245030/en
http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx
http://de.wikipedia.org/wiki/Perfect_Forward_Secrecy
http://tools.ietf.org/html/draft-sheffer-tls-bcp-00
http://heise.de/-2429414
http://www.e-mail-made-in-germany.de/
https://www.ssllabs.com/ssltest/
