Exchange TLS Verschlüsselungsprotokolle – Best Practice

Exchange unterstützt standardmäßig eine breite Palette an verschiedenen Verschlüsselungsprotokollen und Ciphers. Dies gewährleistet grundsätzlich zwar eine hohe Kompatibilität, bildet aber gleichzeitig eine größere Angriffsfläche. Daher ist meiner Meinung nach ein Exchange Hardening gerade bei einem öffentlich zugänglichen Endpunkt, wie es ein Exchange in den meisten Fällen ist, unabdingbar. Die nachfolgenden Schritte sind übrigens nicht nur für Exchange relevant, sondern können auch auf einem reinen IIS angewendet werden.

Vorwort

Das nachträgliche Deaktivieren von bestimmten TLS Versionen und Cipher Suites kann in einer bestehenden Umgebung zu Problemen führen. Gerade dann, wenn es innerhalb der Infrastruktur veraltete Betriebssysteme gibt (bspw. Windows 7) muss eine Deaktivierung gründlich geplant werden. Da ein Exchange in den meisten Fällen öffentlich zugänglich ist und somit für Angreifer ein attraktives Ziel darstellt, sollte diese Evaluierung keinesfalls aufgeschoben werden. Dabei müssen vorab folgende Punkte näher beleuchtet werden:

• Gibt es noch sehr veraltete Clients (W7/W2k8 und älter), die auf den Exchange zugreifen?
• Gibt es ein SSL-Offloading?
• Ist mein Loadbalancer (falls vorhanden) kompatibel?
• Unterstützt mein Mail-Proxy TLS 1.2?
• Gibt es irgendwelche Third-Party Applikationen, die womöglich ausschließlich veraltete Protokolle unterstützen?

TLS Version & Ciphers

TLS 1.0 & TLS 1.1 werden mittlerweile als nicht mehr sicher angesehen. Daher lautet die klare Empfehlung, ausschließlich TLS 1.2 (und neuer) zu verwenden. Das gilt natürlich auch für unseren Exchange.

Um diese Änderung durchzuführen, gibt es verschiedene Vorgehensweisen. So können die am Server verwendeten Protokolle manuell via Registry Key gesetzt werden. Hierzu gibt es seitens Microsoft eine sehr ausführliche Dokumentation.

Damit wir in erster Linie ein besseres Gefühl für die aktivierten Protokolle und Cipher bekommen, greife ich in dieser Anleitung auf das Tool IIS Crypto zurück. Dabei handelt es sich um ein kostenloses Programm, um genau diese Einstellungen grafisch darzustellen und auch bei Bedarf zu konfigurieren. Die Benutzeroberfläche ist sehr einfach und übersichtlich gestaltet:

Im Tab „Schannel“ sehen wir auf einen Blick, welche Protokolle der Windows Server aktuell unterstützt.

Unter „Cipher Suites“ werden alle aktuell unterstützten Ciphers angezeigt:

Als Administrator hätte man nun die Möglichkeit, einzelne Protokolle und Ciphers nach den jeweiligen Bedürfnissen zu konfigurieren. Wer sich allerdings nicht durch die RFCs wühlen und herausfinden möchte, welche Ciphers sicher sind und ohnehin keine genauen Anforderungen hat, kann im Tab „Templates“ die Vorlage „PCI 4.0“ auswählen.

Dabei werden folgende Einstellungen gesetzt:

• TLS 1.0 / TLS 1.1 werden deaktiviert
• Veraltete Cipher werden deaktiviert

Halbwegs aktuelle Betriebssysteme und Browser (ab W2k12 & W8) kommen mit diesen Einstellungen problemlos zurecht. Durch einen Klick auf „Apply“ werden die dafür notwendigen Registry Keys gesetzt. Damit diese auch tatsächlich angewendet werden, ist ein zusätzlicher Neustart des Servers notwendig. Da wir aber vorab noch weitere Hardenings am .NET Framework vornehmen möchten, starten wir den Server erst im nächsten Schritt neu.

.NET Framework

Damit das .NET Framework die zuvor gesetzten Einstellungen vom Windows Server übernimmt und keine eigenständige Konfiguration verwendet, muss die Vererbung der TLS-Standardeinstellungen aktiviert werden. Außerdem wird .NET Framework durch den Registry Key „SchUseStrongCrypto“ angewiesen, ausschließlich sichere Verschlüsselungsprotokolle zu verwenden.

Leider können diese Einstellungen nicht durch den IIS Crypto gesetzt werden. Hierbei reicht allerdings eine als Administrator gestartete PowerShell vollkommen aus:

### .NET Framework 4.X
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWord

### .NET Framework 3.X
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -Type DWord

Wer sich die genaue Bedeutung der Registry-Keys vorab durchlesen möchte, kann auch diesmal wieder auf die Microsoft Dokumentation vertrauen.

Anschließend muss der Host einmal neu gestartet werden. Die oben angeführten Schritte müssen natürlich für jeden Exchange Node durchgeführt werden.

Fazit

Durch das Deaktivieren von veralteten TLS Versionen und Cipher Suites minimieren wir die Angriffsfläche der Exchange Umgebung und schaffen außerdem die Voraussetzung, im nächsten Schritt die Extended Protection zu aktivieren.