Aus der Rubrik SSL-Fail haben wir heute die Domain „kabelmail.de“. Jetzt fragt Ihr Euch natürlich, was Vodafone damit zu tun hat, oder?

Vodafone: falsche SSL-Cipher behindern Mailserver

Der Teil ist weniger spannend als man vermuten könnte:

# dig +short mx kabelmail.de
100 mx01.xworks.net.

Die Domain xworks.net gehört zu Vodafone. Das Problem selbst ist der Windowswelt weiter verbreitet, da es nicht der erste Fall eines Großunternehmens ist, daß seine Mailserver nicht unter Kontrolle hat 😉 Jetzt schauen wir uns aber erst einmal an, was überhaupt los ist.

Der nachfolgende Auszug ist stark auf das Wesentliche verkürzt, gebt den Befehl einfach selbst ein, wenn Ihr alles sehen möchtet:

# openssl s_client -connect mx01.xworks.net:25 -starttls smtp
CONNECTED(00000003)
…
Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits
—
SSL handshake has read 5195 bytes and written 513 bytes
Verification: OK
—
New, SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-SHA
…

Jetzt muß man wissen, das Cipher immer Kinder ihrer Zeit sind, meint, die kann man einer Protokollgeneration zuordnen. „DHE-RSA-AES256-SHA“ ist ein SSLv3/TLS1 Cipher, weswegen OpenSSL hier auch SSLv3 anzeigt, obwohl TLS1.2 gesprochen werden soll.

Hat man jetzt einen Server, der kein SSLv3, TLS1.0 TLS1.1 mehr erlaubt, weil das komplett gebrochen ist und de facto kein „Stand der Technik“ mehr ist, kann man sich leicht ausmalen, was mit einer SSLv3 Verbindung passiert, die eigentlich TLS 1.2 sein müßte 🙂 Genau, sie kommt nicht zu Stande:

2021-01-09 11:22:10 1kxoMm-0002bp-LI == XXXXXXXXXXXXXXXXXXXXx@kabelmail.de <XXXXXXXXXXXXX@kabelmail.de> R=dnslookup T=remote_smtp defer (-37) H=mx01.xworks.net [31.25.48.11]: TLS session: (SSL_connect): error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

Den TLS Handshake einer Verbindung kann man sich so vorstellen:

Client: Hallo Server, ich würde gern TLS mit Dir sprechen, hier sind meine möglichen Cipher…..
Server: Hallo Client, nett, ich könnte das hier anbieten: Cipherliste des Servers
Client: Klasse, dann nehmen wir den ersten aus Deiner Liste, den ich auch kann.. Wie wärs mit .. „ECDHE-RSA-AES256-GCM-SHA384:256“

„ECDHE-RSA-AES256-GCM-SHA384:256“ gehört zur TLS 1.2 Ära ist also was halbwegs aktuelles.

Die Cipherliste ist so definiert, daß der „beste“ aka. „highest“ Cipher vorn als erstes steht. Das machen Client und Server beide so, der erste gemeinsame Cipher der Reihenfolge von „bester“ -> „schlechtester“ Cipher  wird dann benutzt.

Die Ursache

Ursache des SSLv3 Problems bei Windows Mailservern ist jetzt genau die selten gepflegte Cipherliste, die bei der Installation anno 1995 auf die Platte gemeisselt und seitdem kaum aktualisiert wurde. Ich seh hier natürlich Microsoft in der Pflicht, aber hey, ein Mailserveradmin sollte das wissen und checken. Die Ursache ist also bekannt, die Lösung trivial: einfach diese Liste aktualisieren und gut.

Die Ursache ist also bekannt, wieso jetzt den Artikel? 🙂

Ja, wieso eigentlich, beim Großunternehmen ENBW hat es damals doch auch sofort geklappt, eine Email und ein erstaunter „Was zum Geier ist das?“ Rückruf später, konnte man dem ENBW Mailserver wieder Emails senden 🙂

Am 9.1. wurde der Vodafone Support :

TECHNIK: Falsche Cipher Reihenfolge beim Mailserver von kabelmail.de

Moin,

Wenn man DSGVO konform Emails an Kunden von Ihnen schicken möchte, funktioniert dies nicht,
da der SMTP-Server von kabelmail.de => mx01.xworks.net die falsche Reihenfolge der SSL-Cipher konfiguriert hat.

Das kann man selbst ganz einfach mit openssl feststellen:
… die Openssl Anweisung von oben…
Wie man leicht erkennen kann, wird ein SSLv3 Cipher ausgehandelt, weil Ihr Server den als „besten“ Cipher im Cipheroffer anbietet.

Keine Panik, das passiert vielen M$ Kunden und läßt sich ganz einfach lösen:

Drehen Sie die Reihenfolge der Cipher in der Mailserverconfig einfach um und packen Sie die TLS 1.3 und 1.2 Cipher nach vorn in der Liste.

Eine automatische Antwort vom Ticketsystem war auch umgehend da. Am 12.1. kam dann diese Email von Support von Vodafone:

Lieber Vodafone-Kunde,

wir haben Ihre Nachricht an unsere Experten für Ihr Anliegen weitergeleitet.

Die Kollegen antworten Ihnen in Kürze oder rufen Sie zurück. Haben Sie bitte noch ein klein wenig Geduld – vielen Dank.

Hatten Sie mehr als ein Anliegen, antworten wir Ihnen separat.

Freundliche Grüße
Ihr Vodafone-Team

Am 14.1. kam dann diese Email von einer anderen Abteilung des Supports:

Sehr geehrte Damen und Herren,

damit wir Ihnen schnell helfen können, brauchen wir noch Infos von Ihnen:

– Ihre Kundennummer
– Was funktioniert nicht?
– Seit wann funktioniert es nicht?

Rufen Sie uns am besten an. Oder antworten Sie auf diese E-Mail.

Freundliche Grüße
Ihr Vodafone-Team

meine Antwort:

Sehr geehrte Damen und Herren,

damit wir Ihnen schnell helfen können, brauchen wir noch Infos von Ihnen:
– Ihre Kundennummer
Keine Kundenbeziehung.

– Was funktioniert nicht?

Siehe Ticket: Man kann Euch DSGVO Konform keine Emails senden, weil der SSLv3 Cipher benutzt wird, statt dem TLS1.2+ .

– Seit wann funktioniert es nicht?

Seit Jahren, mir gehts nur langsam so auf den Senkel, daß ich Sie informiert habe.

Die alte Leier, man hälts ne Zeitlang aus, merkt dann, daß der andere nie was ändern wird und tritt ihm dann in den Hintern 😉 Irgendwie hatte ich mich aber undeutlich ausgedrückt, denn es kam eine weitere Email:

Sehr geehrte Damen und Herren,

damit wir Ihnen schnell helfen können, brauchen wir noch Infos von Ihnen:

– Ihre Kundennummer

Rufen Sie uns am besten an. Oder antworten Sie auf diese E-Mail.

Freundliche Grüße
Ihr Vodafone-Team

meine Antwort:

Sehr geehrte Damen und Herren,

wir haben keine Kundenbeziehung und nicht Sie helfen mir, sondern ich helfe gerade Ihnen.

Alles was Sie wissen müssen, steht bereits im Original Ticket drin, Sie müssen es nur an die zuständigen Admins weiterleiten.

Seitdem herrscht Schweigen im Walde und auch das Problem wurde noch nicht behoben. 14 Tage sind eigentlich genug Zeit um eine Liste von Ciphern zu aktualisieren, also kommt Ihr jetzt schon in den Genuss der Story 🙂 Die ich Euch natürlich nur deswegen ins Blog stelle, weil die Ursache klein, die Wirkung groß und die Lösung trivial ist 😀 und natürlich weil es Vodafone ist 😉

Unter Linux braucht man sich da im Normalfall eigentlich keine Gedanken machen, da OpenSSL so eine Cipherliste bereitstellt, die mit jedem Update automatisch aktualisiert wird. Man kann es natürlich auch selbst im Mailserver eintragen, wenn man da noch härter sein will, ist aber eigentlich nicht nötig. Man könnte ja auch mal auf ältere Mailserver stoßen, die nicht den aller neusten Cipher bereit haben.

Falls jemand von Vodafone zufällig diesen Artikel findet, Sie suchen das hier: „6618829#5df0179#“ 😉