Exchange 2013 und Perfect Forward Secrency (PFS)

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:

image

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:

image

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/

image

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.

image

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:

image

Dafür steigt das Rating leicht:

image

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:

Exchange 2013 und Perfect Forward Secrency (PFS)

image

Wie etwas weiter oben bereits erwähnt verwende ich ein öffentliches Zertifikat, welches SHA2 (SHA256) und eine Keylänge von 2048Bit nutzt

image

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

image

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.

image

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.

6 Gedanken zu „Exchange 2013 und Perfect Forward Secrency (PFS)“

  1. Schöner Artikel!

    Eine Anleitung wie ich ein solches SHA2 (256) Zertifikat mit einer normalen Windows Zertifizierungsstelle als selbst signiertes Zertifikat für Exchange 2010 / 2013 erstellen kann wäre super! Mit dem normalen Prozedere bekomme ich immer nur ein SHA1 Zertifikat und habe nirgends die Auswahl …

    Danke und Gruß

    Antworten
  2. Hallo Frank,

    das ist eine wirklich schöne Beschreibung und hab mit deinen Tipps nun auch ein grünes A beim SSL Test. Es funktioniert alles prima.
    Seit dem wird allerdings auf meinem Mail-Server leider das Eventlog mit immer der gleichen Fehlermeldung vollgemüllt und ich hab bis jetzt noch keine Lösung gefunden. Vielleicht hast du einen Tipp für mich?
    Es ist ein Exchange 2010 SP3 mit RU8v2 auf einem Win2008R2 Server. Der Fehler ist ein Schannel-Fehler mit Event-ID 36887 – Es wurde eine schwerwiegende Warnung empfangen: 40.
    Mehr Details gibt es zum Fehler leider nicht, nur das er unregelmäßig alle paar Minuten im Eventlog eingetragen wird.

    Vielen Dank schon mal
    Grüße Matthias

    Antworten
  3. Moin Frank,

    kannst du mal nen Artikel zur einrichtung von DANE samt DNSSEC machen?
    Ein kleines How-To wie und wo man es einrichtet. Das wäre klasse!

    Beste Grüße
    Daniel

    Antworten
  4. Moin Moin,

    sobald ich das „Best Practise“ anwende, bekommt kein Outlook 2016 eines Laptops (W7) / einer RDS (2012R2) Sitzung eine Verbindung in Outlook zum Exchange 2016 mehr zu Stande.
    Muss es denn nicht über TLS 1.1 / 1.2 laufen?

    Beste Grüße
    Jens

    Antworten

Schreibe einen Kommentar