Um Exchange 2013 via SSL/TLS sinnvoll abzusichern, empfiehlt es sich „Perfect Forward Secrecy“ einzusetzen. Dies ist ein Zusatz zum gängigen SSL/TLS Protokoll, mit welchem sichergestellt wird, dass nicht mit einem abgefangenen SSL Schlüssel die übertragenen Daten nachträglich entschlüsselt werden können.

Exchange 2013 und Perfect Forward Secrecy – was ist das ?

Jeder Admin und so gut wie jeder Benutzer kennt heutzutage die Möglichkeit den Datenverkehr mit SSL zu verschlüsseln. Hierbei werden auf Basis eines Zertifikats und eines ausgehandelten Sitzungs-Schlüssels die übertragenen Daten verschlüsselt. Die ausgehandelten Sitzungs-Schlüssel für eine gesicherte Übertragung werden aufgrund eines Langzeit-Schlüssels erstellt. Sollte ein Angreifer in den Besitz dieses Langzeit-Schlüssels geraten, wäre es ihm möglich die ausgehandelten Sitzungs-Schlüssel bzw den übertragenen und abgefangenen Datenverkehr zu entschlüsseln. Ein mögliches Szenario wäre das Speichern von Datenverkehr und ein Entschlüsseln dieses Verkehrs, nachdem der Langzeit-Schlüssel in den Besitz des Angreifers gekommen ist.

Um dieses Szenario unmöglich zu machen, können Sitzungs-Schlüssel auf Basis des Diffie-Hellman-Schlüsselaustausch ausgehandelt werden. Sollte ein Server diesen verbesserten Schlüsselaustausch beherrschen, spricht man von „Perfect Forward Secrecy“.

Warum ist dies nicht der Standard?

Perfect Forward Secrecy ist eine Einstellung, welche der Betreiber des Mailservers konfigurieren muss. Durch den Einsatz von höheren SSL bzw. TLS Protokollen kann es zu einer Mehrbelastung der Server von bis zu 30% kommen. Diese Last wollen die meisten Betreiber nicht für die sinnvolle Verbesserung in der Sicherheit Ihrer Systeme opfern.

Wie sieht es bei dogado Hosted Exchange 2013 und Perfect Forward Secrecy aus?

Wir haben unsere Hosted Exchange 2013 Server soweit es geht für SSL Übertragungen optimiert. Hierzu gehört neben anderen Techniken wie „HTTP Strict Transport Security“ auch der Einsatz von Perfect Forward Secrecy.

Die beste Möglichkeit eine SSL-fähige Seite auf Schwachstellen zu überprüfen stellt derzeit der SSL-Test von „Qualys SSL Labs“ dar. Unter folgendem Link finden Sie die Testwerte für unsere  Plattform:

Exchange 2013 und Perfect Forward Secrecy - SSL Labs webmail.hex2013.com

Dieser Test spiegelt die Möglichkeiten unserer „Outlook Web App (OWA)“ wider. Falls Sie den Test für die anderen Schnittstellen ausprobieren möchten, können Sie einfach folgende Adressen verwenden: „outlook.hex2013.com“, „mobile.hex2013.com“ und „mac.hex2013.com“

Werden auch Legacy Schnittstellen unterstützt?

Natürlich setzen wir nicht nur bei unseren HTTPS Schnittstellen auf diese Verbesserungen. Auch bei den Legacy Schnittstellen setzen wir auf Perfect Forward Secrecy. Der SSL Cipher „ECDHE-RSA-AES256-SHA“ steht hierbei für einen Perfect Forward Secrecy fähigen Cipher.

POP Schnittstelle:

SSL handshake has read 4023 bytes and written 429 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
 Protocol : TLSv1
 Cipher : ECDHE-RSA-AES256-SHA
 Session-ID: 643D00006E68DC304BE6BB1B74A8D24E758A30B76D4DC9BC5F40FD86864EB998
 Session-ID-ctx:
 Master-Key: 38E6D2AAF5C9C5CC1ABD35EEDC6931B3DED661787FC5EDC3FD0450CC0F32824D (...)
 Key-Arg : None
 Krb5 Principal: None
 PSK identity: None
 PSK identity hint: None
 Start Time: 1392291217
 Timeout : 300 (sec)
 Verify return code: 0 (ok)
---
+OK The Microsoft Exchange POP3 service is ready.

IMAP Schnittstelle:

SSL handshake has read 4023 bytes and written 429 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
 Protocol : TLSv1
 Cipher : ECDHE-RSA-AES256-SHA
 Session-ID: AE3A0000F94E641B0F82EDA0BFDDD0CD6A92591F2960EDD4E530532A8C698EF3
 Session-ID-ctx:
 Master-Key: ADA0B3F5B24D69DDD053E74AE42E892426C4DB5940BA4FDD792C2CD7C64FEEE9 (...)
 Key-Arg : None
 Krb5 Principal: None
 PSK identity: None
 PSK identity hint: None
 Start Time: 1392291178
 Timeout : 300 (sec)
 Verify return code: 0 (ok)
---
* OK The Microsoft Exchange IMAP4 service is ready.

SMTP Client to Server:

SSL handshake has read 4356 bytes and written 464 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
 Protocol : TLSv1
 Cipher : ECDHE-RSA-AES256-SHA
 Session-ID: A5060000DF06839E8AFB1F38BD9A8ABE699806A57226BAFCA1B48A1082FAA513
 Session-ID-ctx:
 Master-Key: 69ABD3F8F4C90AD4130F8DE3FEC392503EB05142A351AC4DCF157085E080B8D2 (...)
 Key-Arg : None
 Krb5 Principal: None
 PSK identity: None
 PSK identity hint: None
 Start Time: 1392291236
 Timeout : 300 (sec)
 Verify return code: 0 (ok)
---
250 CHUNKING

 

Wie sieht die Kommunikation zwischen Mailservern aus?

Natürlich unterstützen wir die gleichen Möglichkeiten auch bei Verbindungen von externen Mailservern eingehend und ausgehend zu unserer Plattform. Da jedoch zur aktuellen Zeit bei weitem nicht alle Mailserver in der Welt die Übertragung via TLS ausführen, müssen wir auch unsichere Transportverbindungen zu externen Systemen noch erlauben. Dennoch bevorzugt unsere Plattform immer die TLS Verschlüsselung vor einer unsicheren Verbindung für den Fall, dass der externe Mailserver ebenfalls beide Möglichkeiten anbietet.

Peter Stutzinger
Follow me

Peter Stutzinger

Enterprise Architect - Messaging bei dogado GmbH
Komplexe Mailserver Architekturen, Automation und Dienstüberwachung etc.
Peter Stutzinger
Follow me