Mails kommen mit aktiviertem TLS nicht an bei einem Empfänger

[Michi777]

Liebe Community!

Exchange 2010\SBS2011 das System.

wir haben einen Partner, welcher unsere Mails nicht bekommt wenn TLS aktiviert ist.
Wenn es deaktiviert ist gehen die Mails durch - unlogisch da ja meist ein sensibel eingestellter Zielserver ältere TLS Versionen nicht annimmt.
Ich habe fast keine Erfahrung mit TLS, es war voreingestellt vom Jahr 2013 und Exchange ist eines der fordernsten Themen für mich.

Fragen:
1)Was könnte es da haben und wie komme ich zu einer Lösung?
2)Kann ich TLS nur generell ein\ausschalten oder kann ich je Empfängerdomäne etwas festlegen d.h. für diesen Partner deaktivieren?

...in nächsten Monaten wird eh auf neue Serverlandschaft umgestellt, aber eine schnelle Lösung muss dazwischen her für das Problem.

Vielen Dank!

 

[Grimba]

TLS, also Transport Layer Security, ist nur das Protokoll. Welcher Verschlüsselungsalgorithmus verwendet wird, wird bei der Verbindung ausgehandelt. Dabei tauschen sich beide Seiten über die nutzbaren Algorithmen und Schlüsselstärken aus.

Dabei werden ggf. auch bestimmte Versionen bzw. Schlüsselstärken von einem der beiden Kommunikationspartner vorausgesetzt. D.h. unterstützt der sendende Teilnehmer nicht die Mindestanforderungen an die Verschlüsselung des Empfängers, kommt die Verbindung nicht zu Stande.

Habt ihr diesbzgl. den Exchange 2010er aktuell gehalten? Ggf. erwartet der Server eures Partners Verfahren, die euer Server nicht kann. Oder umgekehrt, eurem Server ist der eures Partners zu unsicher.

Ggf. sind auch TLS Versionen unzulässigerweise zu unterschiedlich. Es gibt ja 1.0 bis 1.3, und wünschenswert ist natürlich immer nur die neueste Variante, bzw. kann das auch bei einem Server so voreingestellt sein, dass erst Verbindungen ab einer gewissen Protokollversion zugelassen werden.

Btw. wenn TLS deaktiviert ist, wird es schlicht nicht benutzt, und der Zielserver akzeptiert offenbar solche Verbindungen. Das ist gar nicht so unlogisch.

Eigentlich müsste Info über sowas in irgendwelchen Error-Logs auftauchen bzgl. des Mailversands.

Zertifikate aktuell und noch gültig?

 

[leipziger1979]

Was sagen denn die Logs/Fehlermeldungen?
Gehen die Mail wirklich überhaupt nicht raus oder werden sie von der Gegenstelle abgewiesen?
Gibt es denn beim versenden an andere Empfänger Probleme oder nur bei dem einem?

 

[Michi777]

Ich habe hier ein paar Screenshots für euch und sensible daten davor entfernt.
Weil TLS 1.2 auf no steht bei dem Test bin ich mir nun nicht sicher ob der kollege den befehl für temporäres deaktivieren reingetan hat - ich habe versucht unter Exchange - Sendeconnector nachzusehen jedoch habe ich noch nicht den Bereich gefunden wo ich sehe welche TLS Version und ob aktiv, ebenso nicht welche logs und wo die liegen - bitte um Hilfestellung dazu, bin da zu unerfahren.

Diese Befehle verwendete mein Kollege um temporäre Lösung zu bringen (je ein oder aus).
Set-Sendconnector -IgnoreSTARTTLS $true
Identity: SMTP MX

Set-Sendconnector -IgnoreSTARTTLS $false
Identity: SMTP MX


Empfänger sagt er bekommt von allen Anderen Firmen die Mails korrekt und wir senden\empfangen auch von allen anderen Partnern die Mails korrekt

 

[Grimba]

Also das zweite Bild zeigt in der Summary links diverse Beschwerden über alte und/oder schwache Verschlüsselungsalgorithmen und zu alte unterstützte Protokolle. Letzteres muss kein Problem sein, sofern auch die aktuelleren Unterstützt werden. Aber offenbar ist das nur eingeschränkt der Fall, mit TLS1.0. Das kann und sollte sogar schonmal abgelehnt werden.

Offenbar unterschreitet ihr wirklich eine Mindestanforderung beim Empfänger. Was bei diesem katastrophalen Rating eures Servers auch nicht verwundert.

 

[Michi777]

@Grimba:
Das komische sobald TLS deaktiviert kommt es dort an, aber bei sensiblen Empfängern wie Banken wieder nicht.
Mhm, unlogisch das Ganze und die Antwort der fehlgeschlagenen Mail dauert so 4h nach Senden bis man Bescheid weiss.

 

[Grimba]

Das ist nicht unlogisch.

Euer Partner akzeptiert halt einfach auch unverschlüsselte Verbindungen. Eigentlich sagt euch der Server eures Partners damit:"Wenn ihr das Verschlüsselung nennt, schickt's gleich unverschlüsselt, verarschen kann ich mich selber" Spaß beiseite. Ist halt die Entscheidung eures Partners, was den Server angeht.

Was die Dauer angeht, keinen Plan.

Banken akzeptieren hingegen vermutlich generell keine unverschlüsselten Verbindungen. Dennoch ist es selbstverständlich fragwürdig, bis zu welcher Protokollebene runter man dort noch Verbindungen akzeptiert. Aber das ist ein anderes Thema.

Bei dem Server finde ich es eher unlogisch, dass ihr nur so wenige Probleme habt.

 

[Michi777]

Kann ich nun um das Problem zu lösen mit IIS Crypto 3.0 einfach TLS 1.2 anhaken und Reboot?
...klingt irgendwie zu einfach bzgl. neuer Verschlüsselung implementieren.

Sollte ich noch weitere Felder anhaken?

 

[Grimba]

Keine Ahnung, probiers.

Ggf. solltest du dich auch dringend mal erkundigen, was man für Cipher Suites (und Protokolle) besser abschaltet, im ureigensten Interesse. RC4 z.B. ist sowas von tot.

Du kannst natürlich jetzt erstmal alles anschalten an Protokollen und Cipher Suites, und dann schauen, ob die Mails durchkommen.

Bedenke aber: Dann geht euer Server aber auch so ziemlich jede noch so unsichere verschlüsselte Verbindung ein. Man muss sich halt immer überlegen: Je strikter man ist, desto eher läuft man Gefahr, nicht mehr mit Servern sprechen zu können, die nicht so aktuell sind, sofern man das muss.

Umgekehrt kann man bei einem Server, der jedes noch so alte und gebrochene Verschlüsselungsverfahren akzeptiert wohl kaum von einer sicheren Verbindung sprechen.

Hier sollte man schon regelmäßig mal nachjustieren, und sich vor allem auch regelmäßig informieren, welche Verfahren und Protokolle man noch unterstützen sollte und welche nicht.

Wo, wie was? Keine Ahnung, ich bin kein Admin. Da du den Server wartest, vermutlich du schon.

TLS 1.2 wäre auf jeden Fall ein Anfang.

 

[cloudman]

Schau mal hier

Exchange Team Blog:

https://techcommunity.microsoft.com...dance-Part-2-Enabling-TLS-1-2-and/ba-p/607761

 

[Michi777]

Ja also ich werde mich nun darum bemühen dieses einzelne Problem (einzelner Empfänger kriegt Mails nicht) annehmen.
Tiefere Konfigurationen am alten Exchange nicht mehr machen, weil die neue Serverlandschaft (DL380 g10 + Server 2019 + Exchange 2016 on HyperV) bald umgesetzt wird und dort ist dann alles bestens konfiguriert.

 

[Michi777]

Konnte nun erfolgreich an den betroffenen Empfänger senden und ebenso zu einem sicherheitssensiblen Empfänger (TLS 1.2 vorausgesetzt).
Das Tool IIS Crypto ist wirklich toll.

 

[Evil E-Lex]

Ich kann zusätzlich noch das PowerShell-Script von dieser Seite empfhlen:
Setup Microsoft Windows or IIS for SSL Perfect Forward Secrecy and TLS 1.2
Sollte aus dem "F" bei SSLLabs ein "A" machen. Damit würde ich keinesfalls warten, bis der Server ausgetauscht wird. Das hätte schon vor Jahren passieren müssen. Aber wie immer gilt: Vorher verstehen und testen.

 

[Grimba]

Wenn ich mir den Zustand des aktuellen Servers anschaue und dann diese Quintessenz ...

dieses einzelne Problem (einzelner Empfänger kriegt Mails nicht)

... nach allen gegebenen Anregungen lese, die mich doch etwas daran zweifeln lässt, dass hier verstanden worden ist, dass es hier eben nicht nur um die "mechanische Komponente" (1 Empfänger kriegt Mails nicht) geht, so kann ich dem hier ...

Damit würde ich keinesfalls warten, bis der Server ausgetauscht wird. Das hätte schon vor Jahren passieren müssen. Aber wie immer gilt: Vorher verstehen und testen.

... nur vollständig und nachdrücklich beipflichten. Denn ...

die neue Serverlandschaft (DL380 g10 + Server 2019 + Exchange 2016 on HyperV)

... ist nämlich kein Allheilmittel, auf das man dann in Zukunft kein Auge mehr haben braucht, bis der nächste Server in 5 Jahren die Mails verweigert und man dann ggf. mal nachbessern muss. So schön sich die Buzzwords auch in Reihe packen lassen, das Thema Verschlüsselung lässt sich nicht auf ein an/aus-Häkchen reduzieren!

 

[ayngush]

Genau das ist einer der Gründe, warum man seinen Exchange nicht direkt mit der Außenwelt kommunizieren lässt, sondern das Ganze Giraffel über einen Smarthost (auch SMTP-Relay-Server genannt) sendet und empfängt, der dafür vom Hersteller vorgesehen ist. Viele E-Mail-Security- / -Archive-Appliances können das alles richtig von Haus aus. Der Exchange spricht dann intern nur noch mit der der Appliance und die erledigt den Rest. Oftmals sind dadurch auch Mandatory-TLS Verbindungen usw. viel einfacher zu konfigurieren.