Exchange 2003 Mails von GMX kommen nicht an (TLS)

[CoolBlue 10]

Hallo,

 

wir haben seit einiger Zeit das Problem das Mails von GMX bei aktiviertem STARTTLS im Exchange 2003 nicht ankommen. Werfe ich das Zertifikat raus, dann kommen sie unverschlüsselt problemlos rein. Wodran könnte das liegen?

 

Im Log steht folgendes:

2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 EHLO - +mout.gmx.net 250 0 345 17 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 STARTTLS - - 220 0 0 8 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 STARTTLS - - 220 0 29 8 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 EHLO - +mout.gmx.net 250 0 355 17 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 MAIL - +FROM:<xxx@gmx.de> 250 0 73 37 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 RCPT - +TO:<K.Henkel@xxx.de> 250 0 0 44 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 QUIT - mout.gmx.net 240 156 0 44 0 SMTP - - - -

 

Ich vermute auch das noch andere Absender betroffen sind die mit STARTTLS Mails an den Exchange senden. Genau verfizieren konnte ich aber noch nicht ob die vermisst werden. Aber ich weiß das es bei einem anderen Firma mal eine Beschwerde gab. Die Firma hat dann aber für unsere Versandrichtung TLS deaktiviert, weil wir beide dachten es liegt an denen. Aber anscheinend ist unser Exchange Server das Problem.

 

Als SMTP Zertifikat wird ein Thawte SSL123 Zertifikat verwendet, gültig bis 2016. Für OWA ist es auch aktiv und da gibs keine Probleme mit.

 

Wenn ich mit "openssl s_client -connect mail.beba-energie.de:25 -crlf -starttls smtp" die Verbindung teste, dann kommt die Mail interessanterweise an!

 

Da die GMX Server versuchen die Mails wiederholt zuzustellen gehe ich davon aus, das die Zustellung sichtbar nicht geklappt hat. Aber wieso? Manuell via OpenSSL gehts doch!

 

Irgendjemand eine Idee?

Habe gerade nochmal von einem anderen Exchange Server an den betroffenen Exchange 2003 Server eine Mail gesendet. Auch dieser baut eine STARTTLS Verbindung auf. Jedoch kommt diese Mail an!

 

Die Logs sehen leider identisch aus.. b***d das man nichts "sehen" kann...

2013-08-15 10:51:28 213.131.229.10 cp01.it-lange.net SMTPSVC1 EXBEBA 192.168.0.12 0 EHLO - +cp01.it-lange.net 250 0 346 22 0 SMTP - - - -
2013-08-15 10:51:28 213.131.229.10 cp01.it-lange.net SMTPSVC1 EXBEBA 192.168.0.12 0 STARTTLS - - 220 0 0 8 0 SMTP - - - -
2013-08-15 10:51:28 213.131.229.10 cp01.it-lange.net SMTPSVC1 EXBEBA 192.168.0.12 0 STARTTLS - - 220 0 29 8 0 SMTP - - - -
2013-08-15 10:51:28 213.131.229.10 cp01.it-lange.net SMTPSVC1 EXBEBA 192.168.0.12 0 EHLO - +cp01.it-lange.net 250 0 344 22 0 SMTP - - - -
2013-08-15 10:51:28 213.131.229.10 cp01.it-lange.net SMTPSVC1 EXBEBA 192.168.0.12 0 MAIL - +FROM:<Jan.Lange@itlange.de> 250 0 66 42 0 SMTP - - - -
2013-08-15 10:51:28 213.131.229.10 cp01.it-lange.net SMTPSVC1 EXBEBA 192.168.0.12 0 RCPT - +TO:<K.Henkel@xxx.de> 250 0 0 44 0 SMTP - - - -
2013-08-15 10:51:28 213.131.229.10 cp01.it-lange.net SMTPSVC1 EXBEBA 192.168.0.12 0 QUIT - cp01.it-lange.net 240 250 90 4 0 SMTP - - - -

[zahni 521]

Hier findest Du einen ausführlichen Online-Test:

 

http://www.checktls.com/index.html

 

Allerdings kommt bei Dir kein erkennbarer Fehler...

[CoolBlue 10]

Den Test kenn ich. Der Macht ein Verbindungsaufbau.. sendet Mail TO und RCPT TO, aber schickt dann keine Mail (DATA).. Bis dahin kommt GMX ja auch, laut Exchange Log recht eindeutig sichtbar.

So habe den Fall GMX geschickt. Vielleicht können dir mir Tracelogs schicken.

[viragomann 10]

Hallo!

 

Haben hier genau dasselbe Problem und hab mir eben erst die Logs dazu angesehen:

 

Exchange 2003

Thawte SSL 123

STARTTLS aktiviert

GMX Mails kommen nicht an

 

GMX meldet dem Versender irreführend "A message that you sent could not be delivered to one or more of
its recipients. This is a permanent error. The following address
failed: <user>@gmx.at"

 

Auf die Idee, dass dieses Problem mit dem Zertifikat zusammenhängen würde, wäre ich wohl nicht so schnell gekommen. Andere Server, darunter Banken und Versicherungen, die für restriktive Sicherheitseinstellungen bekannt sind, haben damit aber kein Problem.

GMX hat seine Server laut den Logs am 5. 8. nacheinander auf TLS umgestellt. Seitdem kommen die Mails nicht mehr an.

 

Habe auch nach einem Service-Kontakt bei GMX gesucht, wo ich das melden könnte, aber nur kostenpflichtige Telefonnummern gefunden. Dann bin ich auf diesen Thread gestoßen.

Bin gespannt, was dir GMX antwortet.

 

Grüße

[CoolBlue 10]

Wow, danke für die Bestätigung und Analyse.

 

Mittlerweile haben wir das Problem auch für web.de festgestellt. Ist aber logisch. Gleicher Provider, gleicher IP Adressenraum, hohe Wahrscheinlichkeit das es die gleichen MTAs sind.

 

Ja den Fehler von GMX bekomme ich nach ein paar Tagen ebenfalls.

 

Ich denke nicht das es ein Zertifikatsproblem ist. Deine Schilderung mit dem TLS klingt irgendwie logischer. Exchange 2003 wäre demnach also zu alt?

Moment! Jetzt bin ich verwirrt. TLS ist doch Transport Layer Security die auf dem selben Port statt findet wie die unverschlüsselte Verbindung. Sprich Port 25. Laut Google supportet Exchange 2003 also TLS.

 

Kann es vielleicht eine neuere Version dessen sein? Allerdings wäre das auch merkwürdig, da MAIL TO und RCPT TO ankommen. Beide Befehle kommen erst nach Aushandlung der Verschlüsselung.

 

Andererseits hat hier auch ein Exim User Probleme mit GMX und WEB.de (Vor 4 Tagen gepostet)

http://blog.windfluechter.net/content/blog/2013/08/15/1652-exim4-and-tls-gmxwebde

 

Irgendeine idee wie man das weiter analysieren könnte?

[zahni 521]

Eventuell hat es was mit der TLS-Version zu tun. Welche TLS-Version unterstützt denn der alte Exchange 2003 ?

 

Vielleicht schließt  GMX TLS 1.0 aus.  Eventuell kann man mittels Netmon das SSL-Handshake verfolgen.

So, jetzt vielleicht:  Bitte prüfen, ob  http://support.microsoft.com/kb/948963  installiert ist.

 

GMX scheint AES256-SHA zu benutzen. Der Server vom TO kann nur RC4-MD5 , was unsicher  ist.  Die NSA soll ja nicht mitlesen ;)

[CoolBlue 10]

Oh man für was es alles Patches gibt.. Direkt mal einspielen :-)

Bei mir ist schon der Patch http://support.microsoft.com/kb/2655992/de installiert, der eine höhere Versionsnummer von Schannel.dll enthält als der von dir empfohlene Patch, daher weigert sich der Patch auch zu installieren.

 

Sind da wohl schon die neuen Ciphers enthalten aus Patch 948963?

Interessant ist jedoch das in der Registrierung keine modernen Chipers sind.

 

(Sind kleine Bildanhänge nicht mehr erlaubt? Jegliches Hochladen verweigert mir das Board.. hmpf)

[sconsulting 0]

Wir haben mit unserem Exchange 2003 genau das gleiche Problem.  Leider verwenden viele unserer Kunden GMX als E-Mailanbieter, aufgrund dessen wir auf eine schnelle Lösung angewiesen sind.  War schon jemand von euch in Kontakt mit GMX?

[CoolBlue 10]

Bei uns eilt es auch.. allerdings stehe ich auf dem Standpunkt das geschäftlich relevaten E-Mails bei GMX und WEB.de nix zu suchen haben.

Update: Das Hotfix KB2655992 war bei uns defekt. Habe es neu installiert. Nun ließ sich auch das KB948963 installieren. Server startet gerade neu. Bin gespannt.

----

Also in der Registrierung unter SecurityProviders sind nun die neuen Verschlüsselungsmethoden (AES) usw. aufgeführt. E-Mails von GMX werden vom SMTP Dienst aber dennoch nicht angenommen.

 

Muss für den SMTP Connector irgendwo in der Registry diese Chipsers vill freigeschaltet werden?

[sconsulting 0]

Ja ich bin auch ganz Deiner Meinung, aber leider kann ich dies unseren Kunden nicht vorschreiben :-)  Ok bin gespannt auf das Resultat!

[zahni 521]

@Coolblue,

 

prüfe, welche Dateiversion/-Datum die rsaenh.dll  hat. Die wird durch den Hotfix 2655992 nicht mit ausgetauscht. Ansonsten zuerst 948963 dann 2655992 installieren.

 

PS: Nun wird  es wohl  Zeit für eine neue Exchange-Version...

bearbeitet 19. August 2013 von zahni

[CoolBlue 10]

Sagt euch das was mit

- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted

??

 

mein gnutls-cli test zeigt jedoch das seit dem Patch nun auch AES zur Verfügung steht. Immerhin einen guten Schritt nach vorn.

(Sowohl 128 als auch 256)

 

|<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[0x25ca9c0]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x25ca9c0]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x25ca9c0]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x25ca9c0]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x25ca9c0]: SERVER HELLO DONE was received [4 bytes]
|<2>| ASSERT: gnutls_handshake.c:1286
|<3>| HSK[0x25ca9c0]: CLIENT KEY EXCHANGE was sent [262 bytes]
|<3>| REC[0x25ca9c0]: Sent ChangeCipherSpec
|<3>| HSK[0x25ca9c0]: Cipher Suite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x25ca9c0]: Initializing internal [write] cipher sessions
|<3>| HSK[0x25ca9c0]: FINISHED was sent [16 bytes]
|<3>| HSK[0x25ca9c0]: Cipher Suite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x25ca9c0]: Initializing internal [read] cipher sessions
|<3>| HSK[0x25ca9c0]: FINISHED was received [16 bytes]
|<2>| ASSERT: ext_server_name.c:262
- Certificate type: X.509
 - Got a certificate list of 2 certificates.
 - Certificate[0] info:
  - subject `OU=Go to https://www.thawte.com/repository/index.html,OU=Thawte SSL123 certificate,OU=Domain Validated,CN=mail.beba-energie.de', issuer `C=US,O=Thawte\, Inc.,OU=Domain Validated SSL,CN=Thawte DV SSL CA', RSA key 2048 bits, signed using RSA-SHA, activated `2013-01-22 00:00:00 UTC', expires `2016-02-21 23:59:59 UTC', SHA-1 fingerprint `6c6ad5d769c0901a475283136dfb76a71753c09d'
 - Certificate[1] info:
  - subject `C=US,O=Thawte\, Inc.,OU=Domain Validated SSL,CN=Thawte DV SSL CA', issuer `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', RSA key 2048 bits, signed using RSA-SHA, activated `2010-02-18 00:00:00 UTC', expires `2020-02-17 23:59:59 UTC', SHA-1 fingerprint `3ca958f3e7d6837e1c1acf8b0f6a2e6d487d6762'
- The hostname in the certificate matches 'mail.beba-energie.de'.
|<2>| ASSERT: dn.c:1210
|<2>| ASSERT: verify.c:281
|<2>| ASSERT: verify.c:474
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL

@Coolblue,

 

prüfe, welche Dateiversion/-Datum die rsaenh.dll  hat. Die wird durch den Hotfix 2655992 nicht mit ausgetauscht. Ansonsten zuerst 948963 dann 2655992 installieren.

 

PS: Nun wird  es wohl  Zeit für eine neue Exchange-Version...

 

Dateiversion passt. Patch wurde also angenommen. Beweißt ja auch mein gnutls trace.

 

Hmm Exchange Update ist zwar in Planung aber so Adhoc nicht möglich. Leider

[zahni 521]

Vermutlich vertraut Dein Test-Tools der  CA  nicht. würde  ich zunächst mal ignorieren. Kritischer finde ich TLS 1.0 . K.A. ob der  EX 2003  überhaupt 1.1 oder 1.2 kann.

[CoolBlue 10]

So ich hab neues Futter!

 

Nach googles Recherchen unterstützen nur Windows 7 und Windows 2008 R2 TLS 1.1 und TLS 1.2. Hinzu kommt das beide Protokolle dort standardmäßig deaktiviert sind und in der Registry erst aktiviert werden müssen.

 

Ich hab dies gerade mal verfiziert mit einem Exchange 2010 auf Windows 2008 R2 Server. Eine TLS 1.0 verbindung geht. Eine TLS 1.1/1.2 Verbindung wird abgelehnt

 

*** Fatal error: A record packet with illegal version was received.
*** Handshake has failed
random usage: poolsize=600 mixed=7 polls=25/2 added=37/3360
              outmix=2 getlvl1=2/9 getlvl2=0/0

GMX E-Mails werden jedoch auf Exchange 2010 einwandfrei empfangen!

 

Was sagt ihr nun?

Das klingt für micht nicht nach einem TLS 1.1/1.2 Problem! Ich denke das Protokoll ist auch aus Sicht von GMX/WEB.de noch zu neu um es pauschal für alle Welt zu forcieren. Ebenfalls kann TLS 1.0 die neusten Alghoritmen (AES 256 CBC SHA1). Was 1.0 nicht kann ist SHA256.. aber auch das ist brandneu und zu früh um es zu forcieren.

 

Das Problem liegt woanders.. Andere Tipps?

---

Haben wir vielleicht kein gemeinsames Problem und bei mir könnte es vill. ein TCP/IP Offloading Problem sein? Wobei dann sicherlich nicht nur GMX und WEB.de betroffen wären.. hmmm

[zahni 521]

Da kann ich Dir  auch nicht  helfen. Vielleicht  meldet sich ein echter Exchange-Kenner in dem Thread. 

 

Vielleicht macht Du  aber  auch  einen  Support-Case bei MS auf ?