Category Archives: Secure the Web

Datenschutz – TLS Zwang beim Transport von Emails

Posted on by

Aus gegeben Anlass, daß Juristen, Manager und Admins die titelgebende Aussage verneinen, hier eine kleine, aber belastbare Zusammenfassung der Lage. All das hier gilt nur für Unternehmen oder Organisationen die zum Datenschutz verpflichtet sind, also bis auf Privatpersonen alle!

Datenschutz – TLS Zwang beim Transport von Emails

Es war 2018 als die Datenschutz Grundverordnung final in Kraft trat, als der Landesdatenschutz NRW folgendes Dokument verfasste:

LDI-NRW-E-Mail-Verschluesselung-BSI-TR-03108-1-2018-03-26

Darin war erstmal erwähnt, daß der Einsatz von Verschlüsselung für Datenschutzverantwortliche auch beim Transport von Email gilt. Geglaubt hat es leider kaum jemand 🙁

2018 hatte ich auch Kontakt zum Bundesdatenschutz und indirekt zur Deutschen Datenschutzkonferenz ( DDSK ), denen ich Auswertungen zum Einsatz von TLS geben konnte,  die die DDSK überzeugte, daß „Nicht-Verschlüsseln“ nicht mehr geht, weil das schon so viele können. (75% aller Verbindungen waren damals verschlüsselt.)

Seitdem habe ich immer wieder von Leuten gehört, daß mit der TLS Verschlüsselungspflicht wäre Blödsinn. Das muß anderen auch so gegangen sein, weil die DDSK 2021 eine Orientierungshilfe dazu verfasst hat, die eindeutiger nicht sein könnte:  Orientierungshilfe E-Mail-Verschluesselung.pdf

Wer das PDF nicht mag, der LDI NRW hat die aktuelle Fassung (2021) zusammengefasst:

https://www.ldi.nrw.de/technische-anforderungen-technische-und-organisatorische-massnahmen-beim-e-mail-versand

Stichwort: Obligatorische Verschlüsselung ( Seite 7 5.1. ) als Basisschutz ist Pflicht.

Wer wissen will woher das kommt

Die Pflicht zur Verschlüsselung leitet sich wie folgt her:

Artikel 32 DSGVO
Sicherheit der Verarbeitung
(1) Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der
Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des
Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter
geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu
gewährleisten; diese Maßnahmen schließen unter anderem Folgendes ein:
a) die Pseudonymisierung und Verschlüsselung personenbezogener Daten;

Bezogen auf Emails ist der Stand der Technik in 2024 : TLS 1.3

Die Implementierungkosten sind IMHO gerundet 0 €, weil das jede aktuelle Mailserversoftware direkt können sollte.
( Wenn nicht kann die Software auch gleich gelöscht werden, weil Schrott.)

Daraus ergibt sich dann, das a) fraglos anzuwenden ist, weil die anderen Gründe nicht als zusätzlich „Hürden“ greifen,
denn 0 € Kosten ist das Killerargument schlechthin.

Das BDSG hat das etwas besser formuliert:

Bundesdatenschutzgesetz §64 Abs. 3 Ziff. 1-14

Anforderungen an die Sicherheit der Datenverarbeitung
(3) 2. Verhinderung des unbefugten Lesens, Kopierens,
Veränderns oder Löschens von Datenträgern
(Datenträgerkontrolle),
(3) 8. Gewährleistung, dass bei der Übermittlung
personenbezogener Daten sowie beim Transport von Datenträgern
die Vertraulichkeit und Integrität der Daten geschützt werden
(Transportkontrolle),

Dies reicht eigentlich schon aus, aber wer Zweifel hatte, wie „Verarbeitung“ ist so definiert wurde:

Artikel 4 DSGVO

2. „Verarbeitung“ jeden mit oder ohne Hilfe automatisierter
Verfahren ausgeführten Vorgang oder jede solche
Vorgangsreihe im Zusammenhang mit personenbezogenen Daten
wie das Erheben, das Erfassen, die Organisation,
das Ordnen, die Speicherung, die Anpassung oder Veränderung,
das Auslesen, das Abfragen, die Verwendung, die
Offenlegung durch Übermittlung, Verbreitung oder eine andere
Form der Bereitstellung, den Abgleich oder die
Verknüpfung, die Einschränkung, das Löschen oder die
Vernichtung;

Jetzt der nötige LOGIK Teil:

Man muß nur Emails verschlüsseln, die Personenbezogenen Daten enthalten.

Da man nie vorher wissen kann, wann einem jemand Personenbezogene Daten schickt,
ergibt sich aus der Pflicht, diese zu verschlüsseln, der Umstand,
immer zu verschlüsseln, weil nachträgliche Verschlüsselung einer bereits durchgeführten
Übermittlung logisch und praktisch nicht  möglich ist. QED.

Das Jahr 2024

Ich habe erst letzte Woche die eine BUNDESBEHÖRDE angeschrieben, weil die auch Emails in Klartext annehmen. Dazu heißt es in der Orientierungshilfe von der DDSK:

Seite 7  5.1. obligatorische Transportverschlüsselung

Bei dem letztgenannten Verfahren (STARTTLS) kann die obligatorische Transportver-
schlüsselung durch entsprechende Konfiguration des sendenden MTA (Mail Transfer
Agent) erreicht werden die entsprechenden Konfigurationseinstellungen werden
(En)Forced TLS, Mandatory TLS o. ä. genannt. Unterstützt die Gegenstelle kein TLS,
dann wird der Verbindungsaufbau abgebrochen. Einige MTA ermöglichen eine domä-
nenspezifische oder regelbasierte Spezifizierung dieses Verhaltens.

Bitte beachten Sie: „Unterstützt die Gegenstelle kein TLS, dann wird der Verbindungsaufbau abgebrochen.“ d.h. Klartextemaileinlieferungen sind zu unterbinden.

Das ist genau der Modus Operandi, den wir unseren Kunden seit 2015 anbieten und empfehlen.

Der TLS Zwang ist also nicht weg zu diskutieren, sondern im Gegenteil mehr als real!

Wie testet man sowas?

Linuxuser sind natürlich wie immer im Vorteil, weil Ihr das direkt am Heimischen PC testen könnt:

Die IP und Emailadresse werden hier mal unterdrückt, weil der Fall noch nicht abgeschlossen ist:

[root@s113 ~]# nc a.b.c.d 25
220 mx1.<DOMAIN>.de ESMTP Smtpd; Tue, 27 Feb 2024 20:21:48 +0100
HELO s113.resellerdesktop.de
250 mx1.<DOMAIN>.de Hello s113.resellerdesktop.de [83.246.80.131], pleased to meet you
MAIL FROM: <info@cloud-foo.de>
250 2.1.0 <info@cloud-foo.de>… Sender ok
RCPT TO: <email>
451 4.3.2 Please try again later
QUIT
221 2.0.0 mx1.<DOMAIN>.de closing connection

Diese Ablehnung  war „Greylisting“ vom <DOMAIN> Server, der wollte, das wir später nochmal kommen:

[root@s113 ~]# nc a.b.c.d 25
220 mx1.<DOMAIN>.de ESMTP Smtpd; Tue, 27 Feb 2024 20:31:30 +0100
HELO s113.resellerdesktop.de
250 mx1.<DOMAIN>.de Hello s113.resellerdesktop.de [83.246.80.131], pleased to meet you
MAIL FROM: <info@cloud-foo.de>
250 2.1.0 <info@cloud-foo.de>… Sender ok
RCPT TO: <email>
250 2.1.5 <email>… Recipient ok
DATA
354 Enter mail, end with „.“ on a line by itself
FROM: <info@cloud-foo.de>
TO: <email>
Subject: TEST EMAIL AUF SMTP SECURITY
Date: Tue, 27 Feb 2024 20:21:05 +0100

TEST EMAIL, KANN GELÖSCHT WERDEN

SECURITY TEAM Cloud-Foo.de
.
250 2.0.0 41RJVUwi012500-41RJVUwj012500 Message accepted for delivery

Ich empfehle einen Server in einem öffentlichen Netz zu nehmen, da der einen validen PTR Record haben wird. Was passiert, wenn Ihr keinen habt, erfahrt Ihr bei LINUX-AM-DIENSTAG.de am 5.März um 19 Uhr ! Popkorn mitbringen!!!

Also, obiger Mailserver nahm die Email unverschlüsselt an, was, wenn er sich hätte sicher sein können, daß keine Personenbezogenen Daten drin sind, auch ok gewesen wäre, aber das konnte er nicht. Dazu hätte es mehr als nur etwas KI gebraucht, nämlich Echte Intelligenz 😉

Hinweis: Wer obiges Beispiel nachspielen will, sollte seinen Hostnamen und seine Emailadresse eingeben, weil die Email sonst als SPAM erkannt wird 😀

Update: Vodafone reagierte doch … irgendwann

Posted on by

Was lange währt, währt endlich gut? Diesmal stimmts 🙂

Update: Vodafone reagierte doch … irgendwann

Kennt Ihr den noch?:

Vodafone: falsche SSL-Cipher behindern Mailserver

Das war 2021 und ich dachte mir so „och, schauen wir doch mal nach.“:)

Da kam das raus:

# openssl s_client -connect mx01.xworks.net:25 -starttls smtp |grep Cipher
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let’s Encrypt, CN = R3
verify return:1
depth=0 CN = *.xworks.net
verify return:1
250 HELP
New, SSLv3, Cipher is DHE-RSA-AES256-SHA

also der gleich Cipher wie das letzte mal. Da dachte ich schon, das Vodafone nichts gelernt hätte, aber, wie sich zeigt, hat nur xworks.net nichts dazugelernt. Vodafone hat sich einen neuen Mailserver zugelegt:

# dig +short mx kabelmail.de
10 mx5.vodafonemail.de.

wies aussieht, daß Vodafone den Mailserverpartner gewechselt. Der ist zwar langsam wie eine Teergrube, aber …

# openssl s_client -connect mx5.vodafonemail.de:25 -starttls smtp |grep Cipher
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = smtp.vodafone.de
verify return:1
250 CHUNKING
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

Da hat sich das Warten also gelohnt 😉 Op Success!

SMTP: pphosted.com trifft auf moderne SSL-Technik

Posted on by

pphosted … pphosted … woran erinnert mich das nur? Nach ja, wenn man eigene Mailserver betreibt und deren Logs liest, dann stolpert mal ab und zu mal über irgendwas.irgendwasanderes.pphosted.com . Normalerweise bemerkt man das nicht, aber letzte Woche mußte ich so tief in die Kryptoabgründe blicken, daß ich Euch das nicht ersparen kann 😀

SMTP: pphosted.com trifft auf moderne SSL-Technik

DISCLAIMER: Diese Geschichte ist wahr und kann jederzeit bewiesen werden. Sie erhebt aber keinen Anspruch auf Vollständigkeit. Teile der betroffenen Infrastruktur könnten auch anders ausgestattet sein. 

Ok, nach dem das gesagt wurde… Hammertime! 😀

Frage: Was passiert, wenn ein Mailserver von *****************.pphosted.com auf einen OpenSSL 3 Mailserver im Jahre 2024 trifft?
Antwort: Eine Weile lang kommen verschlüsselte Emails, dann nur noch Klartextmails 😀

Ihr wisst ja, daß ich bei einem Hoster arbeite und deswegen viel mit Emails und Mailservern zu tun habe. Letzte Woche bekommen wir von einem Kunden ein Ticket rein, er bekäme keine Emails mehr von einem wichtigen Partner. Dieser Partner würde jetzt immer eine Meldung bekommen, daß er nicht verschlüsseln würde.

Die Fehlermeldung gibt unser Mailserver aus, wenn der Empfänger die DSGVO Pflicht aktiviert hat, aber eine Klartextemail von 1980 reinkommt. Sprich: die TLS Verschlüsselung war aus. Das verhindert auf SMTP Ebene die Übertragung der Email selbst, so daß der verschlüsselte Transport nach DSGVO Artikel 32 (1) a  garantiert wird. So weit, so klar.

Keine Updates am Mailserver

Jetzt hatte aber im Dezember noch alles geklappt. Seit Anfang Dezember hatte weder OpenSSL, noch unser Mailserver Exim, ein Update bekommen. Da lag es nahe, daß die Ursache auf der anderen Seite zu suchen ist. Was wir noch nicht wußten war das hier:

TLS error on connection from mx07-00181c02.pphosted.com [185.132.180.43] (SSL_accept): error:0A0000C1:SSL routines::no shared cipher

d.b. der andere Server hat erst probiert eine TLS Verbindung aufzubauen, konnte aber nicht (mehr). Deswegen ist er auf Klartext zurückgefallen, was natürlich ein Konfigurationsfehler ist, weil wenn man in 2024 eine Emails nicht verschlüsselt schicken kann, dann schickt man die gar nicht, sondern meldet den Fehler dem Absender. DSGVO Konform halt. Da unser Server für den Kunden keine Klartextmails annimmt, kam es zu der korrekten Fehlermeldung.

Das was hätten wir geklärt, aber das wieso fehlt noch

Und jetzt wird es richtig gruselig. Über unseren Kunden hatten wir Kontakt zum Support des Partners, der uns nach einigem Hin-und-Her dann in einer Email geschrieben hat, daß wir doch einen der folgenden Cipher ( das sind die eigentlichen Verschlüsselungsalgorithmen ) benutzen sollten ( und das ja nicht würden):

Natürlich findet Ihr hier keine IPs/Namen des betroffenen Kunden oder dessen Partners.

Erstmal die Werbung für Ihren Anbieter 🙂

„We always use TLS and millions of email pass through our email gateways and no one reported the similar issue, it appears that issue at the other end only.

Hence we have opened a case with Proofpoint support to share more details on this incident .

Regards,
********* ***
„

Dann diese Email:

„As checked with Proofpoint (************’s email hygiene solution), it appears that there is no common cipher from recipient end during TLS negotiation.

Below are Proofpoint supported cipher list which recipient needs to ensure that they have one of them listed in their cipher list:

O CipherList=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:RC4-SHA:DES-CBC3-SHA

Hence, kindly share the same to recipient IT team and ensure that they support one of the ciphers from the list.

Note: We always use TLS and millions of email pass through our email gateways and no one reported the similar issue.

As no action is pending at Takeda’s end, hence we are proceeding to archive this incident.„

Daher kannte ich „PPhosted“ => Proofe Point Hosted 🙂 Die verkaufen den Leuten Appliances, die die in Ihre Serverschränke stecken können, oder wie hier, hosten die Software individuell für den Kunden. So etwas wie Microsoft mit Office 365 auch macht. Software als Service, Ihr kennt das bestimmt.

Die Cipherliste

Werfen wir mal einen Blick in die Liste der „validen“ Cipher die uns in der Email gegeben wurde:

ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:RC4-SHA:DES-CBC3-SHA

Wer von Euch passendes Kryptovorwissen hat, der hat schon längst angefangen zu lächeln, zurecht ;). z.B. ist der „DES-CBC3-SHA“ Cipher schon bei TLS 1.0 aka SSLv3 dabei gewesen, also sagen wir mal, dieser Retner ist sehr rüstig 😉

Mehr Infos zu Ciphersecurity gibt hier: ciphersuite.info

Aber „ECDHE-RSA-AES256-GCM-SHA384“ ist ein ganz gängiger TLS 1.2 Cipher, gegen den nichts zu sagen ist. Was fällt uns noch auf? Dazu müßt Ihr erstmal wissen, wie so ein Ciphername aufgebaut ist: (mehr Info)

{KEX}-{AUTH}-{SESSIONCIPHER}-{TYPE}-{HASHALGO}-{HASHSIZE}

In unserem Fall:

KEX = KeyExchange => ECDHE => EllipticCurve Diffie-Hellmann
AUTH = Authentication Algorithm in Handshake => RSA
SESSIONCIPHER = der eigentliche Algo => AES256

Der Rest ist für das Problem egal. Wenn Ihr mal die Liste oben durchseht, dann sind das alles RSA basierte Cipher. Jetzt wißt Ihr vielleicht noch nicht, daß RSA auf dem absteigenden Ast ist, was Krypto betrifft, weil  der Algo ist 1970 entworfen worden und braucht heute Keylängen von 16k um „sicher“ zu sein ( abhängig von Anwendungfeld ). Die Länge ist blöd, der Energieeinsatz ist groß, und die Berechnungen dauern länger, als wenn man EllipticCurves benutzen würde.  u.a. hat Fedora RSA aus der OpenSSH Defauleinstellung verbannt, vermutlich weil OpenSSH das gemacht hat. OpenSSL wirds ähnlich handhaben und sogar Lets Encrypt hat RSA als Default Type für die ausgestellten Zertifikate umgestellt.

Kurzfassung: RSA ist tod.

Jetzt gibt es genug Leute die noch auf RSA setzen, aber wie das so mit Untoten ist, die nerven ne Weile 😉

Um es zu verstehen, ist wichtig, wie Exim (mit Fedora) funktioniert. Die Verschlüsselung der Verbindung wird von OpenSSL durchgeführt, Exim fungiert hier nur als Vermittler. Deswegen kommen OpenSSL Fehlermeldungen direkt durch. Der logische erste Schritt ist dann, sich mal anzusehen ob OpenSSL die Cipher aus der Liste noch anbietet:

$ openssl ciphers liefert:
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES256-CCM:AES128-GCM-SHA256:AES128-CCM:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-CCM:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-CCM:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM:PSK-AES128-GCM-SHA256:PSK-AES128-CCM:PSK-AES256-CBC-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA:DHE-PSK-AES256-GCM-SHA384:DHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM:DHE-PSK-AES256-CBC-SHA:DHE-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA:ECDHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-AES256-CBC-SHA:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:RSA-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:RSA-PSK-AES128-GCM-SHA256:RSA-PSK-AES256-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA

ok, also unser OpenSSL arbeitet noch mit dem Cipher, auch wenn RSA nicht mehr die erste Wahl ist. Ist auch ok, man muß ja nehmen, was andere anbieten.Das war es also nicht die Ursache. Ich nehme Euch mal durch 4 Stunden Debuggen mit.

Erstmal testen, ob der Cipher überhaupt noch geht:

$ openssl s_client -connect HOSTNAME:25 -starttls smtp -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384
CONNECTED(00000003)
000E2F7FCA7F0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1586:SSL alert number 40

Oh Scheisse, der Cipher geht tatsächlich nicht mehr. (Wieso steht da übrigens nicht.)

$ openssl s_client -connect HOSTNAME:25 -starttls smtp -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
CONNECTED(00000003)
…
New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384

„HMM… EllipticCurve geht also, aber RSA geht nicht mehr, was aber vorher ging.???“

Also habe ich unseren Cluster gescannt und alle, außer diesem Host klappten mit RSA, nur der nicht.  Daraufhin habe ich mir einen Testserver gesucht und alles verglichen, was an konfigs und software so da war.

Vielleicht haben wir ja Einstellungen in Exim die RSA ausschließen? Nein, weil ging ja im Dezember noch und OpenSSL und Exim hatte keine Updates.

Gab es Änderungen in der Systemkonfiguration über andere Pakete, z.b. GNUTLS? Nein, keine Updates.

Hat sich die systemweite Crypto-Policy vielleicht umgestellt, weil ein Timer abgelaufen ist und RSA deaktiviert wurde (siehe OpenSSH Änderung).  Auch nichts, und das zu durchsuchen und zu verstehen, wie das wie zusammenhängt, hat den Großteil der Zeit gekostet. Langsam wurde es eng.

Ok, Testserver mal neustarten, vielleicht gibt es da einen Hinweis? Nein…….oh Scheisse, jetzt geht der Testserver auch nicht mehr. Also mit STRACE nachgesehen was der an Files, Libs usw. lädt bzw. nicht mehr lädt. Sehr viele spannende Infos könnte ich auch da geben, aber dann schreibe ich übermorgen noch dran 😉

Der Funken vor dem Licht am Endes des Tunnels

Am Ende habe ich einen Hilferuf an die Eximmailingliste geschickt, und da kam dann der berühmte Funken der ersten Erkenntnis als Frage: „Hast Du eigentlich RSA oder EC Zertifikate im Einsatz?“

Ich hatte die ganze Zeit so einen Verdacht… der Server war am 29.12. einmal neugestartet worden. Dabei zieht sich der Exim die Zertifikate rein und solange der läuft, lädt er die nicht nach. Das Zert war aber schon einige Tage vorher verlängert worden, und danach hat es nachweislich noch funktioniert… weil der Server sich das Zert nicht neu eingelesen hat… weswegen man irrtümlich davon ausgehen mußte, daß keine Kausalität bestand. Die wurde erst mit dem Neustart hergestellt 🙁

Das erklärt aber noch nicht, wieso andere uns weiter Emails schicken können und nur pphostet nicht mehr!

Um das zu klären, muß man grob wissen wie der Schlüsselaustausch bei TLS funktioniert:

Jeder Server gibt die Liste Ciphern bekannt, die er unterstützt, vom Stärksten zum Schwächsten akzeptierten Cipher. Dann wird abgeglichen, welcher Cipher bei beiden der stärkste ist und der wird genommen, außer, und das war mir nicht bewußt, das Schlüsselmaterial hat was dagegen.

EC vs RSA

Wenn man ein EC Zertifikat hat, kann man damit keinen RSA Cipher verwenden. Nun bietet unser Server EC und RSA Cipher an, weil er das kann, die andere Seite kann aber keine EC Cipher und deswegen kommt keine Verbindung zu Stande, wenn man ein EC Zert hat….. oh yes.. Let’s Encrypt hat uns ein EC Zert gebaut, weil wir, wieso auch, nicht auf RSA bestanden hatten.

Das ist aber in 2024 nicht wild, da kann jede Kryptosuite und jeder Mailserver EC.. oh nein!!!

PPHOSTED ist im Jahr 2015 gefangen

Hier eine Liste (Zufällig ausgewählt) mit Ciphern die mit pphosted Servern ausgetauscht wurden:

remote_smtp H=mx07-0019ad02.pphosted.com [91.207.212.232] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx07-003d6e01.pphosted.com [185.132.181.218] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx08-003d6e01.pphosted.com [185.183.29.223] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx0a-0021cb01.pphosted.com [148.163.148.203] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx0a-0023b801.pphosted.com [148.163.149.109] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx0b-001dcc01.pphosted.com [148.163.159.10] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250
remote_smtp H=mx0b-0021cb01.pphosted.com [148.163.152.203] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C=“250

Alles RSA Cipher und jetzt testen wir die Server mal, ob die vor oder nach 2018 leben mit:

openssl s_client -connect $serverip:25 -starttls smtp -tls1_3

Ergebnis: (irrelevante Daten entfernt)

servername 91.207.212.232
CONNECTED(00000003)
New, (NONE), Cipher is (NONE)
Compression: NONE
Expansion: NONE
servername 185.132.181.218
CONNECTED(00000003)
New, (NONE), Cipher is (NONE)
Compression: NONE
Expansion: NONE
servername 185.183.29.223
CONNECTED(00000003)
New, (NONE), Cipher is (NONE)
Compression: NONE
Expansion: NONE
servername 148.163.148.203
CONNECTED(00000003)
New, (NONE), Cipher is (NONE)
Compression: NONE
Expansion: NONE

Fazit: Die leben alle vor 2018!!

Was habe ich gemacht?

Ich habe geprüft, ob die Server mit TLS 1.3 eine Verbindung aufbauen können. Können Sie das nicht, sind die auf einem technischen Stand von vor 2018, als TLS 1.3 eingeführt wurde. Das kann durch eine veraltete Konfiguration so sein, oder weil jemand vergessen hat, die Verschlüsselungssoftware auf den neuesten Stand zu bringen.

Jetzt rechnet mal, wie lange ist 2018 her? 🙂

Machen wir den Test doch mal bei uns mit OPENSSL V3 2024 im Rücken :

$ openssl s_client -connect s113:25 -starttls smtp -tls1_3
CONNECTED(00000003)
…
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit

So muß das aussehen 🙂

Fazit

Wir stellen fest:

– pphosted Server können kein TLS 1.3
– pphostet Server können keine TLS 1.2 ECDSA Cipher (siehe Liste aus der Email oben)
+ Sie können aber schon ECDHE Keyexchanges

Das zusammen nordet den technischen Stand ungefär 2015, 2016 ein, eher 2015. 2008 als TLS 1.2 auf den Markt kam, gabs EC noch nicht, deswegen müssen da seitdem ein paar Updates gemacht worden sein. EC wurde erst im Februar 2011 in RFC 6090 definiert.

Ich hab hier übrigens eine Liste mit 366 pphosted Servern, alle das gleiche Ergebnis. Das sind sicherlich nicht alle, aber die Stichprobenmenge erlaubt einen wahrscheinlichen Schluß: Mit aktueller Verschlüsselung haben die es nicht so 😀

„Was macht Proofe Point eigentlich so beruflich?“ werdet Ihr fragen:

„Protect your people from advanced email attacks and identity-based threats. Defend sensitive data from theft, loss and insider threats.

Proofpoint Named a Leader in The Forrester Wave™: Enterprise Email Security, Q2 2023
“ Quelle: https://www.proofpoint.com/us  | 2024-01-09-13:00:00

Ich überlasse es Euch zu urteilen 😉

WIe haben wir eigentlich deren Out-Dated-Mailserver wieder bediehnt? Da kommen die Untoten wieder ins Spiel. Noch ist RSA  mit großen Schlüssellängen nicht gebrochen worden, auch nicht vom GoogleQuantencomputer, also vagabundiert RSA jetzt ein Jahr lang als Legacy auf unserem Mailserverzertifikat rum, nur auf dem. Man kann Lets Encrypt glücklicherweise sagen, daß es RSA ausstellen soll. Aber länger als ein weiteres Jahr, wird es die hoffentlich nicht geben. Vielleicht beendet ja LE den Support und dann gehts auch notgedrungen schneller.

Wenn die bei Proofe Point nichts ändern, werden die danach 50% Ihrer Kunden nichts mehr mailen können 😀 Der Tag kann gar nicht früh genug kommen, wenn Ihr mich fragt. Die ziehen da den Leuten Geld aus der Tasche und dann so etwas.