Mal wieder Freitag und mal wieder ein Problem zum Thema Email. Mails kommen prinzipiell an, aber irgendwie nicht alle. Vermutlich gibt es ein Problem bei der verschlüsselten Übertragung. Das klingt nach einer netten, kleinen Abwechslung. Ich liebe Freitage! Also auf geht es zum ersten Schritt: Informationsbeschaffung. Was geht denn überhaupt nicht? Bei den betroffenen Mails finden sich Hinweise wie dieser hier im syslog des postfix MTAs:

postfix/smtpd[50391] warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:ssl/statem/statem_srvr.c:1686:

Das was hier als „Fehler“ aussieht ist allerdings kein Fehler – sondern lediglich als Hinweis zu verstehen. Deswegen steht da zu Beginn warning und kein error. Auch wenn dieser Hinweis letztendlich dazu geführt hat, dass diese Email nicht angenommen wurde, der Hinweis ist ein wichtiges Indiz: unsupported protocol.

Da steht also bereits die Ursache. Nur wie prüfe ich das bzw. wie kann ich dem Gegenüber einfach erklären was da genau passiert ist? Im Internet gibt es genügend Tools welche das eben mal für einen auswerten können. Hier ein paar Beispiele:

Das mag nett und toll sein, aber eigentlich will ich das selber testen. Ein einfacher, aber verlässlicher Weg ist openssl welches unter Linux oftmals bereits installiert ist. Aber auch Benutzer von anderen Betriebssystemen finden eine passenden openssl Variante. Garantiert 😉

Wie funktioniert das nun? Unsupported protocol, da passt also irgendwas nicht zusammen. Bei TLS  werden beim Verbindungsaufbau unter anderem 2 Dinge verhandelt: Die zu verwendende TLS Version sowie der Cipher, also grob zusammengefasst das „Verschlüsselungsverfahren“. Denkbar ist also, dass beide Parteien keine passende TLS Variante gefunden haben. Oder die passte zwar, aber kein gemeinsamer Cipher ist vorhanden. Eines gleich vorne weg: Letzteres ist die unwahrscheinlichere Variante.

Ein kurzer Einschub zu SSL: Das habe ich schlicht einfach weggelassen. Obige Erklärungen zu TLS gelten sinngemäß ebenso für SSL. Auch wenn moderne Übersetzungen von openssl bereits kein SSL mehr unterstützen lauten die Fehlermeldungen, wie zum Beispiel bei der oben gezeigten, dennoch auf SSL. Auch wenn der Fehler im TLS passiert ist.

Zurück zu openssl und dem testen der Verbindungen: Aus dem Emaillog entnehme ich noch schnell eine weitere Information: Welcher Emailserver kontaktierte mich da gerade? Und schon habe ich beide beteiligten Seiten: Eine davon bin ich selbst, die andere steht im Log. Also los geht es wie folgt:

steffen@belinda:~$ openssl s_client -connect <mein-mail-server>:25 -starttls smtp
CONNECTED(00000003)
depth=0 CN = ....
*snip*
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
*snip*
---
250 HELP

Ich habe die Ausgabe gekürzt, im wesentlichen kann man folgende Informationen daraus mitnehmen: Eine Verbindung wurde erfolgreich aufgebaut, es wird TLSv1.2 verwendet. Ok, jetzt will ich es wissen: Kann der auch TLSv1.3?

steffen@belinda:~$ openssl s_client -connect <mein-mail-server>:25 -starttls smtp -tls1_3
CONNECTED(00000003)
139773854582592:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1543:SSL alert number 70
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 350 bytes and written 277 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Das ist eindeutig, mit TLSv1.3 komme ich nicht weiter. Die weiteren Optionen mit denen man bei openssl angibt welche TLS Variante es sein soll lauten tls1, tls1_1, tls1_2 und tls1_3.

Auf beiden Seiten rasch ausgeführt ergab folgende Tabelle:

           MTA 1     MTA 2
TLSv1.0    Nein      Nein
TLSv1.1    Nein      Nein
TLSv1.2    Ja        Nein
TLSv1.3    Nein      Ja

Die Ursache ist also hübsch verpackt und dargestellt. Unsupported protocol ist gefunden, es gibt keine gemeinsame TLS Variante.

Und jetzt das ganze mal kritisch unter uns betrachtet: Solche Fälle kommen viel öfters vor als man denkt. Ebenso gibt es da draußen noch viele „alte“ Emailserver welche nur bis maximal TLSv1.0 können. Recherchiere einfach mal nach openssl 0.9.x, Du wirst fündig werden. Hier im Blog gefällig? Ein ähnliches Problem: stunnel: noch lange nicht ausgepopt. Man sollte also von seinem hohen Ross herunter kommen und auch ältere Kryptostandards für SMTP anbieten. Damit hat man solche Probleme wunderbar erledigt. Und man braucht sich deswegen auch in keinster Weise schlecht fühlen.

Eine Frage die man sich bei der Verschlüsselung von SMTP stellen sollte lautet einfach wie folgt: „Was will ich denn überhaupt erreichen?“ Naja, die Antwort ist ziemlich einfach. Es ist genau genommen immer die Gleiche wenn es ums Thema Kryptographie geht:

  1. Vertraulichkeit
  2. Integrität
  3. Authentizität
  4. Verbindlichkeit

Nochmals kurz nachlesen? Das ist kurz und nett hier erklärt: https://de.wikipedia.org/wiki/Kryptographie#Ziele_der_Kryptographie.

So, zurück zu SMTP nur mit TLS Verschlüsselung. Werden die Ziele hier ebenfalls erreicht? 1 und 2 sicherlich, das soll ok sein. Aber 3 und 4? Nein, die eben nun mal nicht. Weder die Authentizität noch die Verbindlichkeit einer Email wird dadurch erreicht, dass zwischen zwei SMTP-Servern die Übertragung verschlüsselt stattfindet. Auf dem Rest der Wegstrecke könnte die Email im Klartext übertragen werden, noch ist keine verlässliche Aussage über den Absender möglich eben weil irgendwo auf der Wegstrecke eine verschlüsselte Übertragung stattgefunden hat. So, und was jetzt?

Verschlüsselung ist sinnvoll, darüber brauchen wir nicht zu reden. 1. und 2. ist schnell erledigt. Aber 3. und 4.? Eigentlich liegt die Lösung dafür unmittelbar auf der Hand: Wenn die Verschlüsselung Mitten in der Wegstrecke nichts bringt, dann muss die Verschlüsselung zum Ursprung und dem Ziel einer Email: Der Absender muss die Nachricht verschlüsseln damit der Empfänger diese entschlüsseln kann. Dann funktioniert auch 3. und 4. Das gibt es bereits, nennt sich Ende-zu-Ende-Verschlüsselung (E2EE = end-to-end encryption). Bekannte Verfahren zum Thema Mail sind S/MIME oder PGP.

Wenn ich der Annahme gehe, dass Verfahren X zur Verschlüsselung von Daten „sicher“ und „unknackbar“ ist: Werden die Daten „sicherer“ und „unknackbarer“ wenn ich diese nochmals verschlüssele? Nein, wohl nicht. Zu unendlich 1 dazu addiert ist immer noch unendlich. Daran ändert sich nichts. Und deswegen kann man bei Email, wenn man Ende-zu-Ende-Verschlüsselung einsetzt auf die Verschlüsselung auf dem Versandweg der Email getrost verzichten. Die CPU-Ressourcen und vor allem der verwendete Strom kann gespart werden. Es bringt nichts. Ein Sieg der Vernunft. Da freut sich sogar noch die Umwelt.

Zusammengefasst: Verschlüsselung bei Email ist sinnvoll. Auch wenn es im Sinne der Kryptographie nichts bringt ist zumindest etwas Verschlüsselung allemal besser als keine Verschlüsselung. Nur, und das war die Ausgangslage bei diesem Beitrag: Ein Emailadmin hatte das Problem, dass nicht alle Emails angekommen sind. Um dem Ärger zu entgehen macht man sich das Leben leichter wenn man veraltete oder bald veraltete Verfahren weiterhin anbietet. Es ändert nichts an der Sicherheit wenn man Ende-zu-Ende bereits verwendet, dafür macht es das Adminleben um vieles angenehmer.

Einmal als Admin zurück lehnen und veraltete Software einsetzen. Mit gutem Gewissen. Perverses Gedankenspiel…