• Academy
  • Website & Hosting
  • Marketing
  • Domains & E-Mails
  • Online Shops
  • Server
  • Digitales Büro
  • Managed Cloud
  • Academy

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.

Inhalts­ver­zeichnis

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:

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)

MAP 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.

Bewertung des Beitrages: Ø4,0

Danke für deine Bewertung

Der Beitrag hat dir gefallen? Teile ihn doch mit deinen Freunden & Arbeits­kol­legen

Facebook Twitter LinkedIn WhatsApp