Der eine oder andere wird sich vermutlich schon einmal damit beschäftigt haben, einen Server zu konfigurieren. Vielleicht nur für ein privates Projekt, vielleicht auch für einen Kunden oder eine Community. Wie auch immer, es gibt verschiedene Gründe.
In der Regel gibt es auf einem Server den einen oder anderen Dienst. Ganz je nachdem, was man mit dem Knecht machen möchte.
Ein Dienst davon ist der E-Mailserver.
Postfix ist ein Teil davon. Postfix ist ein Mail Transfer Agent (oder auch MTA genannt). Dieser stellt unter anderem den Dienst „SMTP“ (das könnte der eine oder andere von euch schon mal gelesen oder gehört haben) zur Verfügung.
SMTP ist für die Allermeisten einfach der „Postausgangsserver“ (wie es in Outlook und Thunderbird auch so schön heißt). Er kümmert sich einfach gesagt darum, dass die geschrieben E-Mail mitsamt aller tollen Bilder und Anhänge an die Empfänger zugestellt werden. Soweit gut.
Postfix macht aber noch ein paar Handschläge mehr: Er nimmt auch E-Mails an! Ja genau. Der Dienst SMTP kommuniziert auf aktuellen Systemen über den Port 25. Port 25 ist gelinde gesagt aber nur für die Kommunikation von einem Server zum Empfängerserver möglich. Wenn jemand eine E-Mail über Outlook & Co. an diesen Server zustellt, geschieht das in der Regel über den Port 587 und bestenfalls noch TLS verschlüsselt.
TLS erwähne ich hier an dieser Stelle nicht ohne Grund. TLS ist eine Transportverschlüsselung. Server kommunizieren optimalerweise immer TLS verschlüsselt. Es gibt einige Ausnahmen, die das nicht können (wollen oder machen). Von denen nimmt man dann einfach keine E-Mails an. Fertig. Ja gut, so einfach ist es dann doch nicht. Manchmal lässt man die Server dann auch unverschlüsselt miteinander reden.
Also nochmal: Optimalerweise läuft das ganze verschlüsselt ab. (Die Kommunikation von E-Mailserver zu E-Mailserver).
Soviel zur Einleitung. Nun zur Geschichte selbst:
Vor zirka vier Wochen wechselte ich meinen Server (ich verwalte Ihn selbst und versuche Ihn bestmöglich mit Hilfe verschiedner Dokumentation und Freunden zu konfigurieren), weil mein vorheriger (virtueller Server) für meine Backupstrategie zu wenig Leistung bereithielt. Das Backup dauerte Stunden. Aber gut, das ist heute nicht das Thema. Ich wechselte also den Server, richte Ihn mit viel Fleiß und aktuellen Dokumentationen wieder ein und bekam irgendwann eine Nachricht von einem Freund, dass er Haufenweise Fehlermeldungen per E-Mail bekommt:
TLS connect failed: error14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure; connected to 85.114.134.79. I’m going to try again; this message has been in the queue too long.Gut mein Jung, dachte ich mir. Bei den E-Mails die mir dort zugestellt werden sollte, handelt es sich um E-mails eines befreundeten Lieferservices, welchem ich die Webseite – vor einigen Jahren bereits – eingerichtet habe. Hin und wieder erhalte ich Fehlermeldungen oder Berichte per E-Mail was die Funktion der Webseite selbst betreffen.
Aber was ist das Problem? Schauen wir uns das doch einmal etwas genauer an:
Was hast Du gesagt?
TLS connect failed besagt erstmal soviel wie „Hallo, ich kann mit dir nicht reden“. Im Anschluss daran kommt eine unschöne Art der Fehlernummer, noch ein bisschen Text, bis wiederum der interessante Teil kommt:
SSLv3 alert handshake failure; Was möchte uns die Technik also damit mitteilen? Ich hole mal wieder etwas aus:
SSL hat möglicherweise schon der eine oder andere gehört. Webseiten sollten immer SSL verschlüsselt sein (indem man Sie per https:// aufruft) und wenn ein SSL Fehler angezeigt wird (insbesondere Chrome & Firefox machen das ganz prächtig), dann sollte man abstand von der Webseite nehmen, weil da etwas nicht stimmt.
Unter E-Mailservern ist es nochmal etwas anders. Es gibt hier sogenannte Cipher Suites. (OK die gibt es auch bei eigentlich jeder verschlüsselten Verbindung, aber wir lassen das mal aktuell in dem Kontext stehen). Cipher Suites sind sogenannte Algorithmen wie etwas verschlüsselt wird und wie die Kommunikation abläuft. Stellt es euch als eine Art Sprache vor. Die Server einigen sich auf einen Cipher und darüber wird dann verschlüsselt geredet (Achtung: Nicht zu verwechseln mit privaten Keys oder dergleichen wie man sie eventuell von PGP kennt).
Also, stellt euch vor, wir benennen die Ciphern einfach mal. Wir haben 3 Cipher. Nennen wir sie Einfacherweise einfach mal: Deutsch, Englisch und Russisch.
Mein Server spricht die Cipher Deutsch und Englisch. Jetzt kommt ein anderer E-Mailserver und sagt „Hallo, ich will dir eine E-Mail senden, sag mir doch einmal bitte welche Cipher Du kannst, damit wir uns auf eine einigen können“.
Jetzt sendet mein Server zurück: „Hallo mein Freund. Ich spreche Deutsch und Englisch und Du?“
Jetzt weiß der andere Server: „Oh, toll, ich spreche Englisch und Russisch, daher nehme ich Englisch, das versteht der andere“. Und Schwupp legt er los und sendet mir die Daten für die E-Mail.
Ihr seht also: Die Cipher ist eine gemeinsame Basis auf dem die Server sich einigen um miteinander Daten auszutauschen.
Das ganze wird auch als „Handshake“ bezeichnet. Sie klatschen sich ab und geben sich bei der Gemeinsamkeit einen virtuellen High-Five.
Nun wissen wir also, dass die Fehlermeldung uns sagt, dass der Handshake nicht hinhaut. Vermutlich sprechen die beiden Server einfach keine gemeinsame Sprache. Das ist ärgerlich, denn dann bekomme ich keine E-Mails und mein Freund bekommt regelmäßig den Hinweis „Hey, ich kann die E-Mail nicht zustellen, hier kriegst wieder zurück“.
Also habe ich mich auf die Suche nach dem Problem begeben. Dabei hat mir ein Kollege aus unserer Firma geholfen, die Konfiguration auseinander zu nehmen und wieder in kleinen Häppchen zusammenzusetzen (ich bin stark davon ausgegangen, dass ich einen Fehler bei der vorherigen Konfiguration meines E-Mailservers gemacht habe).
Wodran hat es gelegen?
Das fragt man sich am Ende immer, wodran es gelegen hat.
Ich sag mal so… . Wir wussten eine ganze Zeitlang auch nicht wodran es denn nun gelegen hat. Ich erwähnte ja schon kurz vorhin TLS. TLS gibt es unter anderem auch in mehreren Versionen. Das aktuellste ist TLSv1.3, der eigentlich aktuelle Standart TLSv1.2 (den eigentlich jedes aktuelle Programm sprechen können sollte) und TLSv1.1 und TLSv1 (ohne .0 dahinter).
Die letzteren beiden benutzt man eigentlich nicht mehr. Sie sind veraltet und haben auch Sicherheitslücken (die man übrigens mit dem Abwählen der Ciphern ganz gut abwürgen kann).
Auf meinem Server ist unter TLSv1.2 alles deaktiviert. Brauch keiner mehr und TLSv1.2 sollte dann auch jeder aktuelle Server / Client sprechen können.
Ich traf ja einige Vorkehrungen und Sicherheitseinschränkungen, welche wir nach und nach deaktivierten, änderten und anpassten. In der Hoffnung wir würden finden, warum die beiden Server sich nicht verstehen. Problem war: Egal was wir änderten: Es funktionierte nicht. E-Mails kamen nicht durch.
Wir entdecken zwar noch einige weitere kleine Schönheitsfehler (z.B. ein falsch zugeordnetes Zertifikat *upsi* und ein paar umplausible Einstellungen *upsi2*).
Ich entschloss mich also dem anderen Serveranbieter (übrigens ein recht großer und bekannter Anbieter) eine E-Mail zu schreiben und einfach mal zu Fragen, was sie für eine Cipher und was für ein Protokoll sie voraussetzen.
Kurze Zeit später erhielt ich eine Antwort:
Guten Tag Montgomery Banse,
[…]
Vermutlich versuchenSie hier über sendmail E-Mails über unseren Webserver zu versenden. Dabei werden die E-Mails mit einer TLS 1.0 Verschlüsselung versandt.
[…]
Hah! Haaaah! Hier lag der Hase also im Pfeffer begraben. Sendmail ist eine Möglichkeit E-Mails ohne Anmeldung (SMTP fordert normalerweise eine Anmeldung mit Benutzername und Passwort) über die jeweilige Anwendung auf dem System zum Beispiel über PHP zu versenden (mail()-Funktion, falls das jemanden interessiert).
Auch dabei wird die E-Mail an einen MTA übergeben, der die E-Mail dann an meinen Server weiter gibt. Und genau dieser, redet nur TLSv1.0. Tja, hier sagt mein Server natürlich „Nö, spreche ich nicht mehr“.
Hier stellt sich mir nur die Frage: Warum?
Warum macht man das? Also ich meine, nur weil die E-Mails nicht autorisiert eingeliefert werden, muss man sie doch auch nicht gleich völlig veraltet versenden. TLSv1.2 könnte man ruhig unterstützen.
Okay, aber wie habe ich das Problem nun gelöst? Das hingegen war recht einfach. Ich implementierte auf der Webseite statt den Versand der E-Mails über mail() einfach den Versand über SMTP. Damit meldet sich das Warenkorbsystem am jeweiligen Mailserver an, sendet seine E-Mail über ein anderes System und schwupp kommen die Mails mit der richtigen TLS-Version bei mir an und nutzen eine Sprache (Cipher) die beide verstehen.
Das herauszufinden hat mich übrigens locker vier bis fünf Stunden gekostet. War ein Spaßiges Wochenende.
Kurz und Knapp!
Für alle, die die Lösung gerne sofort sehen möchten ohne eine Lange Geschichte zu lesen. Bittegerne:
Problem:
Ein externer Mailserver konnte meinem Mailserver keine E-Mail mehr senden.
Fehlermeldungen:
TLS connect failed: error14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure; connected to 85.114.134.79. I’m going to try again; this message has been in the queue too long.und
Jun 6 00:05:34 server postfix/smtpd[23675]: connect from s*****.i*********.de [**.***.**.***] Jun 6 00:05:34 server postfix/smtpd[23675]: setting up TLS connection from s*****.i*********.de[**.***.**.***] Jun 6 00:05:34 server postfix/smtpd[23675]: s*****.i*********.de[**.***.**.***]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4 :@STRENGTH:!MD5:!DES:!SEED:!IDEA:!RC2:!DSS:!aNULL:!eNULL:!PSK:!SRP:!CAMELLIA:!ARIA"
Jun 6 00:05:34 server postfix/smtpd[23675]: SSL_accept:before SSL initialization
Jun 6 00:05:34 server postfix/smtpd[23675]: SSL_accept:before SSL initialization
Jun 6 00:05:34 server postfix/smtpd[23675]: SSL3 alert write:fatal:protocol version
Jun 6 00:05:34 server postfix/smtpd[23675]: SSL_accept:error in error
Jun 6 00:05:34 server postfix/smtpd[23675]: SSL_accept error from s*****.i*********.de [**.***.**.***]: -1
Jun 6 00:05:34 server postfix/smtpd[23675]: warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:../ssl/statem/statem_srvr.c:1661: Jun 6 00:05:34 server postfix/smtpd[23675]: lost connection after STARTTLS from s*****.i*********.de[**.***.**.***]
Jun 6 00:05:34 server postfix/smtpd[23675]: disconnect from s*****.i*********.de [**.***.**.***] ehlo=1 starttls=0/1 commands=1/2Lösung:
E-Mails vom Server nicht mittels der PHP Funktion mail() abzusenden, sondern z.B. über via SMTP, zum Beispiel über die PHPMailer-Klasse. Damit der korrekte E-Mailserver für den Versand genutzt wird und kein technischer Abschaum, der es scheinbar nicht wert ist eine korrekte Konfiguration zu erhalten.
Bildquellen
- switch and router: Network switch photo created by victor217 - www.freepik.com | Image by Freepik
0 Kommentare