Fälschlicherweise keine Shared Cipher gefunden

[meisterkeks]

Hallo zusammen,

ich bin heute auf folgendes Problem gestoßen: Mails eines anderen Servers an Keyhelp kommen nicht durch. In den Logs finden sich dazu passend folgende Zeilen:

Code: Select all

Nov 23 16:40:54 SERVERNAME postfix/smtpd[1489383]: connect from ABSENDERDOMAIN.de[123.456.789.123]
Nov 23 16:40:54 SERVERNAME postfix/smtpd[1489383]: SSL_accept error from ABSENDERDOMAIN.de[123.456.789.123]: -1
Nov 23 16:40:54 SERVERNAME postfix/smtpd[1489383]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2283:
Nov 23 16:40:54 SERVERNAME postfix/smtpd[1489383]: lost connection after STARTTLS from ABSENDERDOMAIN.de[123.456.789.123]
Nov 23 16:40:54 SERVERNAME postfix/smtpd[1489383]: disconnect from ABSENDERDOMAIN.de[123.456.789.123] ehlo=1 starttls=0/1 commands=1/2

Ausschlaggebend scheint ja no shared cipher zu sein. Bis hierhin dachte ich noch, der Absenderserver wäre halt veraltet. Also zusätzlich noch kurz bei Qualys SSLLabs die Cipher Suites gecheckt und siehe da: eigentlich haben beide Server eine passende Teilmenge an Cipher Suites für TLS 1.2:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA)
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA)
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits

Warum kommt die Verbindung also nicht zustande?

Anbei noch ein paar grundsätzliche Infos zu der KH-Instanz:

• Ubuntu 20.04
• KeyHelp 21.2 (Build 2302)
• VPS

[space2place]

Moin,
Ich habe jetzt auch mal etwas nach dem Fehler gesucht.. Und man kommt immer wieder auf Beiträge die von einem älteren System reden.
Wie hast Du denn Deinen Server mit TLS eingestellt?
Bei uns stellen wir alle Server auf TLSv1.2 mit den von der BSI empfohlenen Ciphers ein:
viewtopic.php?t=10442

Dann gibt auch keine Diskussionen mit den Kunden..

[meisterkeks]

Wie hast Du denn Deinen Server mit TLS eingestellt?

Es ist die Standard-Konfiguration in Keyhelp ausgewählt. Also TLS 1.2 mit folgenden Ciphers:

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES256-GCM-SHA384

Danke für die Empfehlung des BSI, vielleicht stelle ich das in Zukunft um.

Das Problem ist jetzt aber, dass obwohl beide Server eigentlich mehrere gemeinsame Ciphers haben no shared cipher als Grund für die nicht zustande gekommen Verbindung genannt wird.

[Speedy]

Ich weiß, dass der Thread schon etwas älter ist. Hatte die Fehlermeldung aber nun auch und habe alle Systeme bzgl. der Ciphers etc. gecheckt. Am Ende lag es am sendenden Exchange Server. Dort war der Sendeconnector auf Port 25 eingestellt.
Nach änderung auf Port 587 wurden die Mails dann auch beim keyhelp Postfix zugestellt.

In der Shell könnt ihr am Exchange mit "Get-SendConnector "EuerConnectorName"|fl Port" den genutzten Port checken und mit "Set-SendConnector -Identity "EuerConnectorName" -Port 587" auf den 587 Port umstellen. Danach noch den Exchange Transport Dienst neustarten.

[Tobi]

Speedy, danke, genau das muss ich morgen meinem Kunden mitteilen und wenn das klappt hast du mir stundenlange Internetrecherche erspart

[meisterkeks]

Danke für die Rückmeldung Speedy. Ich habe das Problem jetzt zwar schon eine Weile nicht mehr beobachten können, aber beim nächsten Mal weiß ich wonach ich suchen muss.

[Tobi]

Leider hat der Windows-Konsolen-Hack bei mir / meinem Kunden nicht funktioniert.

Daraufhin habe ich dem Systemhaus Zugangsdaten unseres alternativen E-Mail-Anbieters gesandt und es hat auf Anhieb funktioniert.

@Alex
Könntest du mal bitte prüfen warum der Exchange-Konnektor nicht mit den KeyHelp-Standard-Einstellungen zurecht kommt?

[Alexander]

@Alex
Könntest du mal bitte prüfen warum der Exchange-Konnektor nicht mit den KeyHelp-Standard-Einstellungen zurecht kommt?

Ich hab leider keinen Exchange zur Hand, bei dem ich aktuell Testen könnte. Vielleicht kann sich das Florian ab nächster Woche nochmal anschauen.

[Blackmoon]

Daraufhin habe ich dem Systemhaus Zugangsdaten unseres alternativen E-Mail-Anbieters gesandt und es hat auf Anhieb funktioniert.

Das hängt nicht vom Exchange Server, sondern es hängt von eingesetzten Betriebssystem ab. Die meisten Microsoft Produkte greifen in der Regel auf die Implementierung für TLS/SSL vom Windows Server zurück. Hierzu gibt es zwei Möglichkeiten: WinHTTP und Schannel.

Daher vergleiche ich mit Hilfe von OpenSSL immer die verfügbaren Protokolle und Cipher Suites des Exchange- und KeyHelp-Servers.

Die Ports von Standard Connectoren bei Exchange zu verbiegen, ist grundsätzlich keine Gute Idee. Das holt ein früher oder später ein. Denn es gibt bei neuen Versionen des Exchange-Servers natürlich auch einen Connector mit TLS auf Port 587. Ich lege in der Regel für die anzubindende Applikation einen dedizierten Connector an. Um einfach den Überblick zu haben und jederzeit einen sauberen Rückbau machen zu können.

Gruß,
Daniel

[Speedy]

Wo liegt das Problem einen simplen Sendeconnector anzupassen? Den kann man zur Not auch wieder löschen. In meinem Fall war es ein Server 2016 mit einem Exchange Server 2016 - also nichts altes. Da sollte man schon erwarten, dass die Kommunikation mit dem Keyhelp funktioniert. Auch die ciphers habe ich überprüft und die waren auch im Keyhelp hinterlegt.
Vielleicht kannst Du ja noch weitergehende Informationen geben, wie genau ein detailliertere Prüfung in diesem Fehlerfall aussehen sollte.

[Blackmoon]

Wo liegt das Problem einen simplen Sendeconnector anzupassen?

Es ist eigentlich in der Microsoft Welt eine goldene Regel. Denn die Updates (auch im Exchange) unberechenbar. Gerade wenn es Custom Configurations geht, welche nach Updates eigentlich immer überschrieben werden. Zudem ist es sinnvoll bei einer Fehlersuche auf die Original Konnektoren (unabhängig von Typ und Art) zurückgreifen zu können. Um so eine Referenz auch gegenüber den Microsoft Support zu haben.

In meinem Fall war es ein Server 2016 mit einem Exchange Server 2016 - also nichts altes. Da sollte man schon erwarten, dass die Kommunikation mit dem Keyhelp funktioniert.

In der Regel liegt es nicht an KeyHelp bzw. Linux, sondern an Windows Server. Microsoft aktualisiert die TLS Protokolle und dazugehörigen Cipher Suites immer nur mit einem Versionswechsel (2016 -> 2019 -> 2022). Damit verbunden hat man zwangsläufig immer das Problem, dass die Microsoft Welt den aktuellen Standards hinterherläuft. Wenn man das Thema "härten" ernst nimmt und konsequent ist. Von den Diffie-Hellman Parametern möchte ich noch gar nicht reden.

Vielleicht kannst Du ja noch weitergehende Informationen geben, wie genau ein detailliertere Prüfung in diesem Fehlerfall aussehen sollte.

Das sprengt den Rahmen eines Forums. In erster Linie sollte man Quell- und Zielsystem auf die verfügbaren TLS Protokolle, Cihper Suites und DH Param überprüfen. Und damit verbunden natürlich welche Übereinstimmungen es (nicht) gibt. Dann gibt es natürlich diverse Tools, um eine TLS Verbindung mit Hilfe von Parametern zu initialisieren, um zu sehen ob die gefundenen Übereinstimmungen auf funktionieren würden.