Datenschutz: Wie peinlich T-Online ist

Peinlicher, aber nicht ganz unerwarteter, Fauxpas von T-Online:

2020-02-25 04:55:03 1j69ZJ-0001iL-S3 H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 04:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-38) H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 05:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 06:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 07:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 08:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 09:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 10:55:03 1j69ZJ-0001iL-S3 H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 10:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-38) H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support

angemerkt sein, daß die Server für Kundenmails davon nicht betroffen sind. Das ändert aber nichts daran.

T-Online mit Datenschutzverstoß

Der Verzicht auf TLS stellt meiner Meinung nach, mal einen soliden Verstoß gegen Artikel 32 DSGVO dar, weil man als Mailserverbetreiber ja vorher nicht wissen kann, ob da drüber Personenbezogene Daten transportiert werden sollen oder nicht. Hellsehen, was einem einer jemals schicken wird, kann man ja nicht und daher muß man zwangsläufig vorher die Sicherheit der Datenübertragung aktiviert haben, weil nachträglich Sicherheit herstellen geht in dem Fall nun mal nicht.

Artikel 32
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;

Das kombiniert mit Artikel 4 2. schließt den Transport von Daten mit in den Begriff „Verarbeitung“ ein und erzwingt, weil der Aufwand praktisch nicht vorhanden ist und somit auch keine Kosten entstehen, die Verschlüsselung von Emails beim Transport durch den Einsatz von aktuellen Techniken ( STARTTLS mit TLS 1.2+).

In dem Fall wären es tatsächlich Personenbezogene Daten gewesen, weswegen unser Mailserver so eingestellt ist, daß er das in dem Fall auf keinen Fall über unsichere Leitungen schicken darf.

Die Adresse tosa@rx.t-online.de ist übrigens eine T-Online Adminadresse, falls man mal mit seinem Server gesperrt ist(, weil T-Onlinekunden Spams an ihre echten Adressen einfach ungefiltert an T-Onlineadressen weiterleiten) . Ich gehe mal davon aus, daß wie bei großen Organisationen üblich, Links nicht weiß was Rechts hätte tun sollen.

Die notwendigen Schritte den Verstoß abzustellen, werde ich jetzt anstoßen.

Update: 18:50 Uhr

Es gab Antwort von T-Online… und jetzt schön hinschauen… nicht lachen…

Received: from mailout02.t-online.de ([194.25.134.17])
	by userserver with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	(Exim 4.93)
	(envelope-from <postmaster@rx.t-online.de>)
	id ---
	for unsere@adresse; Tue, 25 Feb 2020 13:26:31 +0100
Received: from fwd37.aul.t-online.de (fwd37.aul.t-online.de [172.20.27.137])
	by mailout02.t-online.de (Postfix) with SMTP id ---
	for <unsere@adresse>; Tue, 25 Feb 2020 13:26:31 +0100 (CET)
Received: from mail.t-online-team.de (SU1DYkZrrhdrbk+8MoWoNLfFvJAGt3hYNV-3h42o51p2-46yGQLhcUQTxiv6TV2wPu@[194.25.187.129]) by fwd37.t-online.de
	with (TLSv1:ECDHE-RSA-AES256-SHA encrypted)
	esmtp id ---; Tue, 25 Feb 2020 13:26:30 +0100
From: Deutsche Telekom E-Mail Engineering ************* <postmaster@rx.t-online.de>
Date: Tue, 25 Feb 2020 13:26:31 +0100
Organization: Deutsche Telekom AG
X-Mailer: Forte Agent 6.00/32.1186
Content-Type: text/plain; charset=ISO-8859-1

Diese Email ist der nächste Verstoß gegen den Datenschutz, weil in der DSGVO steht drin, daß man auch bei internem Datentransport an die Absicherung denken muß.

Wie man sieht nutzt der erste Mailserver (mail.t-online-team.de) auf dem Weg zu unserem Mailserver (oberster Eintrag) TLSv1.0 , ein seit spätestens 2015 final geknacktes Protokoll. Der nächste interne Server  (fwd37.aul.t-online.de) benutzt für den internen Transport zu mailout02.t-online.de gleich gar keine Verschlüsselung mehr. Der letzte Mailserver mailout02.t-online.de macht dann endlich mal was richtig auf dem weg zu uns und benutzt TLSv1.2.

D.b. das „mailout02.t-online.de“ und „fwd37.aul.t-online.de“ können entweder miteinanders kein gemeinsames Protokoll finden, oder haben TLS/SSL gar nicht im Programm. Da aber jeder von denen auf der jeweils anderen Seite der Verbindung irgendwie TLS kann, muß da bei T-Online das Chaos pur herrschen. Ob das absichtlich, unabsichtlich oder fahrlässig so ist, werden die Datenschutzbehörden klären.

„Hallo T-Online, das Jahr 2005 will seinen Uralt-Zeichensatz zurück haben!“

Von dem ISO-8859-1 Fail des Mailprogramms will ich gar nicht erst anfangen, aber wirklich, was für einen uralt Krempel nutzen die da??? de-latin1 und TLSv1 passen historisch natürlich gut zusammen 🙂

Ältere Fälle:

Willkommen im Club der TLS Verweigerer: Apache Foundation!

BSI aktualisiert Mailserver auf TLS 1.2.. ABER

Sächsische Polizei benutzte gebrochene Verschlüsselung

OMG des Tages: Fulldisclosure ML bietet kein TLS an

Nicht das man es brauchen würde, aber in 2019 darf man doch von einer Securityliste erwarten, daß deren Mailserver TLS kann, oder? Nicht so bei NMAP.

seclists.org Mailserver bietet kein TLS an

Gerade wollte ich das Duplicator Pro Advisory an die  FullDisclosure Mailingliste schicken, da mault doch glatt mein Mailserver, daß er die Mail nicht schicken könnte, weil der Empfänger TLS verweigert. Ein OMG war die Folge:

CheckTLS Confidence Factor for „fulldisclosure@seclists.org“: 0

MX ServerPrefAnswerConnectHELOTLSCertSecureFrom
ack.nmap.org
[45.33.49.119:25]
0OK
(69ms)
OK
(151ms)
OK
(68ms)
FAILFAILFAILOK
(357ms)

2019-09-27 21:23:52 1iDvqI-0005NU-Mw == fulldisclosure@seclists.org R=dnslookup T=remote_smtp defer (-38) H=ack.nmap.org [45.33.49.119]: a TLS session is required, but the server did not offer TLS support

Jetzt braucht man natürlich keine Verschlüsslung, wenn eh an eine öffentliche Mailingliste Veröffentlichungen schickt, aber da laufen auch private Mailinglisten drüber z.b. über Bugs in NMAP und die sollten ja wohl verschlüsselt ankommen, oder?

Es kommt mir so bekannt vor…

Besonders prekär für die Admins des NMAP Mailservers ist der Umstand, daß deren Mailserver sehr wohl TLS beim Senden von Emails kann, sonst kämen die Emails nicht bei uns an:

2019-09-26 08:54:08 1iDNfD-00060F-Mj <= fulldisclosure-bounces@seclists.org H=ack.nmap.org [45.33.49.119] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=21878 id=6e00195f-664f-1d1c-0fb6-1333992ad574@sec-consult.com

Die große Ähnlichkeit zum BSI CERT-Bund Mailserver macht es natürlich nicht besser: BSI aktualisiert Mailserver auf TLS 1.2.. ABER .

Ich seh schon, mit dem TLS Gate habe ich noch auf Jahre jede Menge Spaß fürs Blog 😀

Hinweis: Duplicator Pro <= 1.3.14 hat eine fiese IFDC Schwachstelle. Bitte updaten!

BSI aktualisiert Mailserver auf TLS 1.2.. ABER

„Nein! Doch!! OOOHHHH!“ Es ist vollbracht. Das BSI hat den Newsletterserver für das Bürger-CERT nach 13 Monaten endlich auf TLS 1.2 gehievt, also auf den Stand der Technik vom Jahr 2008.  \o/

Delivery-date: Wed, 13 Mar 2019 15:27:52 +0100
Received: from newsletter.bund.de ([77.87.229.56])
	by XXXXXXXXXXXXX.de with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	(Exim 4.90_1)
	(envelope-from <buerger-cert-newsletter@newsletter.bund.de>)
	id 1h44rG-0001dj-FW
	for XXXXXXXXXXXXXXXX.de; Wed, 13 Mar 2019 15:27:52 +0100

Bin mal gespannt, ob der 2030 endlich TLS 1.3 kann 😀

OHHHH NEEEEIIIINN!!!!

KEIN TLS IM SERVER

Das kann jetzt echt nicht wahr sein, aber der gleiche Server, der beim Senden TLS 1.2 nimmt, bietet nicht mal TLS an, wenn er was empfangen soll!

Trying TLS on newsletter.bund.de[77.87.229.56:25] (10):

secondstest stage and result
[000.106]Connected to server
[000.292]<–220 ESMTP
[000.293]We are allowed to connect
[000.293] –>EHLO www6.CheckTLS.com
[000.399]<–250-newsletter.bund.de
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
[000.399]We can use this server
[000.399]TLS is not an option on this server
[000.400] –>MAIL FROM:<test@checktls.com></test@checktls.com>
[000.506]<–250 2.1.0 Ok
[000.506]Sender is OK
[000.506] –>QUIT
[000.612]<–221 2.0.0 Bye

Geht noch mehr FAIL ?

Mehr zu dem Thema : Mailserver – Gebrochenes TLS im Einsatz

Gnu.org im Jahr 1998 stecken geblieben

Ja, ich weiß, Ihr könnt es nicht mehr lesen, der xte Mailserver der keine TLS 1.2 kann, nur leider hat der hier eggs.gnu.org eine wichtige Rolle, der handelt nämlich Emails für gnu.org . Kein TLS 1.2 , keine Emails mehr aus Europa.

„.. und dabei ist FOSS & TLS 1.2 kein Widerspruch.“

Trying TLS on eggs.gnu.org[209.51.188.92:25] (10):

secondstest stage and result
[000.007]Connected to server
[000.167]<–220 eggs.gnu.org ESMTP Exim 4.71 Sat, 09 Feb 2019 11:54:20 -0500
[000.167]We are allowed to connect
[000.167] –>EHLO www6.CheckTLS.com
[000.174]<–250-eggs.gnu.org Hello www6.checktls.com [159.89.187.50]
250-SIZE 52428800
250-PIPELINING
250-STARTTLS
250 HELP
[000.174]We can use this server
[000.175]TLS is an option on this server
[000.175] –>STARTTLS
[000.185]<–220 TLS go ahead
[000.186]STARTTLS command works on this server
[000.275]Connection converted to SSL
SSLVersion in use: TLSv1
Cipher in use: DHE-RSA-AES256-SHA
Certificate 1 of 3 in chain: Cert VALIDATED: ok
Cert Hostname VERIFIED (eggs.gnu.org = eggs.gnu.org | DNS:eggs.gnu.org | DNS:mail.gnu.org)
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=03:f9:06:4d:6c:6d:1e:1c:83:03:50:8a:32:c0:d5:a9:da:99
subject= /CN=eggs.gnu.org
issuer= /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
Certificate 2 of 3 in chain: Cert VALIDATED: ok
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=0a:01:41:42:00:00:01:53:85:73:6a:0b:85:ec:a7:08
subject= /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
Certificate 3 of 3 in chain: Cert VALIDATED: ok
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3

wenn man mal genauer hinsieht mit :  „openssl s_client -connect eggs.gnu.org:25 -starttls smtp -tls1“

Subject=/CN=eggs.gnu.org
….
New, SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
….
250 HELP

sieht dann auch, daß der Cipher noch aus SSLv3 Zeiten stammt, was nicht verwundert, weil TLS 1.0 nur SSLv3 mit SNI Support ist.

Falls jemand von Euch jemand den GNU Leuten Emails schicken will, machts gleich in Klartext 😀

1&1 Mails von Spamhaus geblockt.. was nun ?

Info aus der Spamwelt: 1&1 Mailserver bei Spamhaus auf der Blockliste gelandet, und jetzt ??

1&1 Mailserver von Spamhaus geblockt

Wie wir heute von Kunden meines Arbeitgebers erfahren haben, können diese über 1&1 keine Mails mehr an bestimmte Adressen senden. Da haben wir mal nachgesehen und mußten feststellen, daß Spamhaus die IP’s der Mailserver von  1&1 gesperrt hat:

2019-01-09 10:01:11 H=mout-xforward.kundenserver.de [82.165.159.37] X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F= rejected RCPT <empfänger@unserserver.eu>: found in zen.spamhaus.org</empfänger@unserserver.eu>
2019-01-09 10:02:03 H=mout-xforward.kundenserver.de [82.165.159.43] X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F= rejected RCPT <empfänger@unserserver.eu>: found in zen.spamhaus.org</empfänger@unserserver.eu>

Es handelt sich um ein /30 Subnetz, daß von 1&1 zu einem einzigen Zweck benutzt wird. Interessant wird es,wenn man bei Spamhaus den Grund für die Sperre einsieht:

Blocklist Lookup Results

82.165.159.37 is listed in the SBL, in the following records:

    SBL275659

82.165.159.37 is not listed in the PBL
82.165.159.37 is not listed in the XBL

Der von 1&1 verwendete Netzblock ist bereits seit Anfang 2017 gesperrt, wie man dem Link oben entnehmen kann. Das liegt daran, daß 1&1 diesen Block nur benutzt, wenn die Emails intern bei 1&1 als Spams bewertet wurden. Daher kann auch nur 1&1 helfen.

Ref: SBL275659
82.165.159.36/30 is listed on the Spamhaus Block List – SBL
2017-02-09 23:24:04 GMT | courtesy.spamhaus.org
mout-xforward.kundenserver.de

The IP addresses listed in this SBL are used by 1&1 solely for delivering emails that have been internally (by 1&1) classified as SPAM.

You have been referred to this page for one of the following reasons:

a) Your own legitimate emails have been erroneously classified as SPAM by 1&1’s systems. In this case please contact 1&1 directly using the following link to clear up the matter:

http://postmaster.1und1.de/en/blacklisting/?ip=82.165.159.36&c=sbl

b) You found non-delivery reports „bounces“ in your mailbox for messages other than your own. This indicates that a third party has sent these emails through your mailbox without your consent. Please take the following steps to re-establish the security of your 1&1 mailbox:

i) Check your computer for viruses:
Perform a thorough anti-virus scan on all computers which have been used to access the mailbox.

ii) Choose a new password for the affected mailbox.

Please carefully note that if you contact Spamhaus regarding this SBL listing, you will not receive any answer and the listing will not be removed. Your only resolution path is through 1&1, as indicated above.

 

Jetzt stellt sich natürlich sofort die Frage:

Wieso 1&1 als Spam erkannte EMails überhaupt rausschickt ?

Die Sache ist eigentlich ganz clever:

  1. Kundenemails gehen erstmal raus, ohne daß es eine Fehlermeldung gibt.
  2. Der eigene Mailcluster für „normale“ Emails wird nicht (oder eher seltener) von Blacklistenbetreibern geblockt.
  3. Nutzer von Spamhaus und anderen IP basierten Blacklisten bekommen diese „Spams“ nicht.

Das sieht erstmal wie ein Win – Win aus.. aber eigentlich gewinnt nur 1&1, denn die haben erstmal keinen Supportaufwand ( das habe ich natürlich direkt geändert 😀 ), der landet jetzt erstmal bei dem, bei dem die Email nicht angekommen ist und natürlich dem Absender, der hat den meisten Ärger.

Der Absender muß den Empfänger anrufen, weil mailen geht ja nicht. Der Supporter vom Empfänger muß jetzt losgehen, seine Logs checken und findet den Block von Spamhaus, fragt Spamhaus und gibt dem Absender zurück, daß ist sein Problem, er solle mal 1&1 fragen.  Bumerangmäßig kommt der Aufwand wieder bei 1und1 an.

Ich lehne mich mal ganz weit aus dem Fenster und behaupte..

… das liegt alles an BWL ( Betriebswirtschaftslehre ) und deren Mantra „Kosten, die nicht bei mir anfallen, sind keine Kosten.“ .

Ich denke mir das so: Die Abteilung von 1&1 , welche die Mailserver betreut, hat das eingerichtet, damit die Anfragen, wieso Emails nicht angekommen sind, erstmal beim Allgemeinen Supporttelefon landen. Das dürfte eine andere Abteilung sein. Die filtern erstmal alle weg, die nur mal eine Email zurück bekommen haben.

Bei den ganz harten Fälle haben Andere den Hauptteil der Arbeit schon für die erledigt: Sie wissen woran es lag => Spamklassifizierung von 1&1 . Damit muß der Level 2 des Technischen Supports nicht mehr lange suchen, was Zeit und Geld spart. Die Kosten dafür wurden auf den Kunden und ganz elegant auf die Supportabteilung von einem völlig anderen Unternehmen abgewälzt. Übrig bleibt ein kleiner Rest, der Minimal im Vergleich zum großen Gesamtbetrag ist. Spiel, Satz und Sieg 1&1 🙁

Was wäre wenn..

Allerdings würden alle Anderen gar keine Kosten mehr haben, wenn 1&1 die erkannten Spams gleich zurück an den Absender schickt und klar reinschreibt, daß es Spams waren. Das würde aber Kundenunzufriedenheit fördern und in der Endkonsequenz bedeutet, daß sich Kunden in Foren beschweren, daß man über 1&1 Mailserver keine Mails mehr raussenden könnte. Schlecht fürs Geschäft, insofern ist das für 1&1 natürlich erstmal die bessere Lösung, die Emails rauszusenden und zu schauen was passiert, zumal 1&1 sichergestellt hat, daß der Kunde nicht von Ihnen trotzdem den wahren Grund ( Spam ) erfährt.  Jetzt entlädt sich der Frust darüber, daß ein anderer Mailserver die Emails als Spam zurück gesendet hat, beim Empfänger und nachdem klar ist, was passiert ist, ist dessen Frustlevel schon wieder gesunken, wenn er sich dann beim 1&1 Support meldet.

Ich überlege gerade, im nächsten Meeting eine ähnliche Struktur vorzuschlagen, da man als „Absenderprovider“ damit nur gewinnen kann, während alle anderen verlieren 🙁

Mozillas Bugtracker zu blöd für TLS

Also da könnte man aus der Haut fahren. Wir haben das Jahr 2018. In 2008 wurde TLS 1.2 als Stand der Technik eingeführt und was bekommt man, wenn sich in den Bugtracker von Mozilla einloggen will ??? DAS HIER :

Your account has been disabled

Your Bugzilla account has been disabled due to issues delivering emails to your address.

Your mail server (dsn; a27-61.smtp-out.us-west-2.amazonses.com) said: (failed) smtp; 550-Sender did not use TLS secured connection. Sender benutzte keine TLS 550 gesicherte Verbindung.


If you believe your account should be restored, please send email to bugzilla-admin@mozilla.org explaining why.

 

Klar failed das, weil die Mozilla Admins zu blöd sind um TLS beim Senden in Ihrem Mailserver zu aktivieren! In 2018! Und nächstes Jahr ist TLS 1.3 draußen. Au Backe.. wozu macht die IETF das wohl neu .. zum Spaß wohl kaum!? Und zu allem übel ist die Meldung auch noch falsch, weil das da DEREN MAILSERVER IST! 😀

Jetzt überlegt mal was das heißt, wenn ein Security Bug von weltweiten Ausmaß besprochen wird. Was machen die dann, sich im Nebel unter einer Londoner Brücke treffen ?

Wo wir grade dabei sind :

Der SystemD Bugzilla hatte da wohl ein größeres DATENLECK :

reject.log-20180909:2018-09-04 00:11:32 H=mail.logite.biz.ua [89.163.132.50] F=<amsizcz@logite.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: found in zen.spamhaus.org</systemdbugzilla@
reject.log-20180909:2018-09-05 02:30:21 H=mail.windersale.biz.ua [217.79.182.196] F=<iskohmf@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180909:2018-09-05 18:39:10 H=mail.zimerton.biz.ua [89.163.142.60] F=<exbiclz@zimerton.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180909:2018-09-06 20:00:27 H=mail.axiroks.co.ua [217.79.181.114] F=<ablojmp@axiroks.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-09 22:24:27 H=mail.aquaclean.biz.ua [62.141.32.162] F=<ynmipfy@aquaclean.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-09 22:58:07 H=mail.derosman.co.ua [5.104.110.186] F=<aysixkc@derosman.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-11 02:40:28 H=mail.windersale.biz.ua [217.79.182.196] F=<etkuxnw@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-12 10:29:33 H=mail.alihost.co.ua [213.202.212.238] F=<ivdewmw@alihost.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-13 01:08:28 H=mail.windersale.biz.ua [217.79.182.196] F=<yrxocts@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-14 00:36:32 H=mail.mafines.eu [213.202.212.252] F=<odyizfm@mafines.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-16 22:07:58 H=mail.shophostel.eu [89.163.131.100] F=<iwpekfy@shophostel.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-17 22:24:23 H=mail.kollisar.biz.ua [213.202.212.143] F=<ephorkm@kollisar.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-19 03:44:26 H=mail.axiroks.co.ua [217.79.181.114] F=<ypficrx@axiroks.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-21 02:58:35 H=mail.windersale.biz.ua [217.79.182.196] F=<uvbiczw@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-23 23:52:36 H=mail.alihost.co.ua [213.202.212.238] F=<upyyzdr@alihost.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-25 03:05:04 H=mail.developmnt.eu [62.141.46.214] F=<opvojcx@developmnt.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-25 18:04:27 H=mail.mafines.eu [213.202.212.252] F=<ytvelrs@mafines.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-25 18:10:29 H=mail.gorgyam.eu [5.199.135.188] F=<ympyrmv@gorgyam.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-27 01:50:59 H=mail.axiroks.co.ua [217.79.181.114] F=<alpafcb@axiroks.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@

(Der Editor von WordPress verweigert den Text in seiner Rohform zu zeigen und will unbedingt das nicht existente Tag schliessen. All Fail WordPress! )

SO! muß das aussehen Mozilla!

2018-09-22 00:21:23 1g3Tnc-0005cl-8K <= bugzilla@redhat.com H=mx1-phx2.redhat.com [209.132.183.26] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=3923 id=bug-1599018-321468-Fft8v2y8dX@bugzilla.redhat.com

Damit die Admins bei Mozillapost bekommen, sind sie bei GOOGLE untergekommen :

2018-10-03 10:23:49 1g7cRf-0000Gr-Qb => bugzilla-admin@mozilla.org R=dnslookup T=remote_smtp H=aspmx.l.google.com [74.125.133.27] X=TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256 CV=yes K C=“250 2.0.0 OK l18-v6si623134wre.19 – gsmtp“

Und jetzt steht euch mal den Chiper an : „First Time spotted“ CHACHA20-POLY1305 . „Was ist das denn fürn Exot ?“ werdet Ihr Euch fragen… ja, das ist eine GOOGLE Erfindung. Wie man da lesen kann, nicht mal ein Standard, sondern nur eine Info 😉 Naja, scheint ja von OpenSSL implementiert worden zu sein.

 

VW Mailserver mit falschem TLS Zertifikat

Hallo Volkswagen IT, guggt Ihr mal hier :

Server: smtp.vw-rd.de
Connection converted to SSL
SSLVersion in use: TLSv1_2
Cipher in use: DHE-RSA-AES128-GCM-SHA256
Certificate 1 of 1 in chain: Cert VALIDATION ERROR(S): unable to get local issuer certificate; unable to verify the first certificate
This may help: What Is An Intermediate Certificate
So email is encrypted but the recipient domain is not verified
Cert Hostname DOES NOT VERIFY (smtp.vw-rd.de != L1074104.vt-security.de | DNS:L1074104.vt-security.de)
So email is encrypted but the host is not verified
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=8c:ec:8e:f6:b1:b5:4d:49
subject= /C=de/L=Berlin/O=VOLKSWAGEN Retail/CN=L1074104.vt-security.de
issuer= /C=de/L=Berlin/O=VOLKSWAGEN Retail/CN=VOLKSWAGEN Retail VPN CA

Selbstsignierte Zertifikate auf öffentlichen Mailservern sind sowas von 2010, aber dann nicht mal das richtige Zertifikat benutzen, das geht ja mal gar nicht 😀

Arbeitsanweisung: ASAP beheben Leute!

 

Süddeutsche Zeitung & das TLSv1 Gate

Und wieder einmal schlägt das TLSv1 Problem zu, diesmal bei der Süddeutschen Zeitung. Dankt Fefe für den Tipp 😉

Das Testergebnis

CheckTLS Confidence Factor for „szdm.digitalesdesign@sz.de“: 100

MX ServerPrefAnswerConnectHELOTLSCertSecureFromTo
mshgw-mx01.msh.de
[212.4.227.210]
50OK
(86ms)
OK
(114ms)
OK
(89ms)
OK
(90ms)
OK
(1,094ms)
OK
(93ms)
OK
(94ms)
OK
(120ms)
mshgw-mx01.msh.de
[212.4.227.209]
50OK
(86ms)
OK
(88ms)
OK
(86ms)
OK
(90ms)
OK
(860ms)
OK
(96ms)
OK
(92ms)
OK
(95ms)
mshgw-mx01.msh.de
[212.4.227.208]
50OK
(96ms)
OK
(84ms)
OK
(86ms)
OK
(87ms)
OK
(1,023ms)
OK
(92ms)
OK
(90ms)
OK
(90ms)
mshgw-mx02.msh.de
[212.4.227.212]
50OK
(90ms)
OK
(93ms)
OK
(90ms)
OK
(89ms)
OK
(1,024ms)
OK
(91ms)
OK
(91ms)
OK
(95ms)
mshgw-mx02.msh.de
[212.4.227.211]
50OK
(90ms)
OK
(93ms)
OK
(87ms)
OK
(92ms)
OK
(1,002ms)
OK
(87ms)
OK
(94ms)
OK
(94ms)
mshgw-mx02.msh.de
[212.4.227.213]
50OK
(88ms)
OK
(87ms)
OK
(91ms)
OK
(87ms)
OK
(1,069ms)
OK
(98ms)
OK
(91ms)
OK
(90ms)
Average100%100%100%100%100%100%100%100%

Das Testergebnis via checktls.com ist an sich ganz ok, bis auf den kleinen, aber entscheidenen Hinweis, das die Verbindung nur mit TLS 1.0 abgesichert ist 🙂

Die Verbindung selbst wurde am 14. 3. 2018 um 11:45 Uhr getestet und liefert für alle Server das gleiche Ergebnis:

Trying TLS on mshgw-mx01.msh.de[212.4.227.210] (50):

secondstest stage and result
[000.086]Connected to server
[000.198]<–220 mshgw-mx07.msh.de ESMTP
[000.199]We are allowed to connect
[000.200] –>EHLO checktls.com
[000.287]<–250-mshgw-mx07.msh.de
250-PIPELINING
250-SIZE 62914560
250-ETRN
250-STARTTLS
250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN
250-AUTH=CRAM-MD5 DIGEST-MD5 LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
[000.289]We can use this server
[000.289]TLS is an option on this server
[000.289] –>STARTTLS
[000.378]<–220 2.0.0 Ready to start TLS
[000.379]STARTTLS command works on this server
[000.659]Connection converted to SSL
SSLVersion in use: TLSv1
Cipher in use: DHE-RSA-AES256-SHA
Certificate 1 of 3 in chain: Cert VALIDATED: ok
Cert Hostname VERIFIED (mshgw-mx01.msh.de = *.msh.de | DNS:*.msh.de | DNS:msh.de)

Also ich werde der Süddeutschen Zeitung keine geheimen Daten schicken , ohne die nochmal mit PGP/GPG zu verschlüsseln und am besten gar nicht per Email, sondern gleich per POST mit einem DoubleLayerEncryption USBStick 😀

BSI zu TLSv1.0

Laut der technischen Richtlinie gelten TLS 1.0 und TLS 1.1 als unsicher und 
werden nicht mehr empfohlen.
...
Dieser Mindeststandard referenziert die technische Richtlinie TR-02102-2 und
fordert für die Bundesverwaltung den Einsatz von TLS 1.2 mit PFS.

ums mal ganz klar zu sagen :

Liebe Süddeutsche,

damit Eure Whistleblower auch in Zukunft noch Mail schicken, was sie zwar nicht sollten, aber das ist ein anderes Thema, wechselt doch mal die Mailserverinfrastutur aus, z.B. indem der Anbieter das Update von 2008 auf TLS 1.2 einspielt. Verschlüsselung auf dem Technikstand von 1999 einzusetzen , ist keine Lösung!

Sächsische Polizei benutzte gebrochene Verschlüsselung

Diese Geschichte spielt im September 2016 und handelt davon ..

… das 365 Full-DisclosureTimer abgelaufen sind und ..

… Wie aus einer Maus ein Elefant wird

Im Zuge einer Ermittlung zu SSL Problemen eines Kunden, bin ich über ein SSL Problem der Polizei Sachsen gestolpert. Aufmerksame Leser meines Blogs ist das Thema SSL/TLS bei Mailservern nichts neues. Es reiht sich ein in Probleme wie die des CERT-BUND vom BSI , die sich im Vergleich dazu aber schnell schliessen liessen. Der Versuch, die Sicherheitslücke der zuständigen Abteilung  zu melden, artete regelrecht in einen Instanzenlauf aller „Die Zwölf Aufgaben des Asterix“ aus. Am Ende waren 6 Behörden daran beteiligt.

Was ist eigentlich passiert ?

Wer sein Mailserverlogfiles schonmal genauer angesehen hat, wird darin Angaben wie diese finden : „X=SSLv3:AES256-SHA:256″ . Diese stammen zwar jetzt von Exim, sind so aber auch in anderen Produkten zu finden. Bei dem X= handelt es sich um das Verschlüsselungsprotokoll ( SSLv3 ) und dem genutzten Verschlüsselungsalgorithmus/Cipher ( AES-256 mit Hashalgo SHA256 ) . Am Cipher gibt es nicht viel auszusetzen, klar, es gibt bessere z.B. AES256-GCM-SHA384:256, aber das ist nicht des Pudels Kern, sondern die Version SSLv3.

SSLv3 gilt seit 2 Jahren im Rahmen der POODLE Attacke als geknackt, zudem wurde es im Bereich Email vor über 15 Jahren schon von TLS abgelöst. Seit dem es als geknackt gilt, sollte man es auch nicht mehr einsetzen. Daher haben Internetprovider weltweit SSLv3 aus Ihrem Webservern und Emailservern entfernt. Jetzt wäre es falsch zusagen „Nur die Polizei Sachsen“ nicht, denn das stimmt nicht und wäre eh nur die halbe Wahrheit, denn es gehören immer zwei Server zu einer Übertragung.

Normalerweise läuft das so ab, daß sich sich der sendende und der empfangene Mailserver beim Verbindungsaufbau auf das Protokoll, den Cipher und den SessionKey einigen. Dabei wird erst TLS1.2 , dann TLS1.1 und dann TLS1/SSLv3 ausgewählt. Der Server der Polizei in Sachsen hatte nun SSLv3, also den schlechtesten Algorithmus gewählt, obwohl bessere zur Verfügung standen. Warum er das tat ist (war) noch Ziel einer Untersuchung. Die Kripo in Leipzig hat es auf sich genommen, das an die zuständigen Stellen weiterzuleiten und dafür zu sorgen, daß das zugrunde liegende Problem behoben wird.

Das war die Maus… und jetzt der Elefant

Für die Polizei betreut ein Dienstleister als sogenannter Staatsbetrieb die Netzwerke des Bundeslandes und seiner Behörden, das ist i.d.R. eine privat organisierte Tochter des jeweiligen Bundeslandes. In Sachsen ist das die „Staatsbetrieb Saechsische Informatik Dienste“ in Dresden. Wenn man jetzt glaubt, daß man dies ja nur dieser, für die Netze zuständigen Organisation mitteilen müßte, hat das noch nie probiert 😀

Dort habe ich natürlich zuerst angerufen um rauszubekommen, wer meine Kontaktperson sein wird. Pustekuchen. Die Leute da haben sich das zwar angehört, wollten aber aus externen Input nichts tun. Ich sollte das doch an den Polizeibeamten schicken der die fragliche Email geschickt hatte übermitteln, er würde das schon weiterleiten. Das habe ich gemacht.

und ….. ???

Nix. Gar nichts. Keine Empfangsbestätigung, kein Rückruf. Wie sich heute rausgestellt hat, war die Kripo Leipzig am letzten Freitag, Tag des Maileingangs, total überlastet. Der zuständige Mitarbeiter hat die Mail einfach weggeklickt, weil er den Inhalt auch nicht ganz erfaßt hatte. Zum Glück für die Polizei hat der besorgte ITler keine Ruhe gegeben und sich heute erneut durch die Instanzen gequält bis der zuständige Mitarbeiter sich dann selbstständig bei mir gemeldet hat.

Die nicht an behördenarme Suche soll hier skizzenhaft dargestellt werden:

Polizeidirektion Braunschweig
LKA Niedersachsen
LKA Sachsen
Polizeidirektion Leipzig
Staatskanzlei Sachsen
Bundesamt für Sicherheit in der Informationtechnik

als Optionen wären noch drin gewesen :

Landesdatenschutzbehörde Sachsen
Innenministerium Sachsen
Bundesministerium des Inneren
Verfassungsschutz Sachsen
Staatsschutz

Wenn es nach dem BSI gegangen wäre, wärs gleich beim Bundesministerium des Inneren gelandet, also ganz oben 🙂

Jetzt fragt Ihr Euch vermutlich wie der Verfassungsschutz da ins Spiel kommt. Das ist ganz einfach, das Mailserversystem des Landes mailt ja nicht nur Bürger an, sondern auch andere Behörden. Wenn jetzt also ein Konfigurationsfehler vorliegt, der dafür sorgt, daß der schwächste Algorithmus ausgewählt wird, dann sind auch Behörden- und damit Staatsgeheimnisse betroffen. Und da wir nicht so enden wollen wie die Amis, wo deren Politiker private Mailserver benutzen, sollten unsere Behördennetzte sicher sein. Davon profitieren wir alle, auch ganz direkt, denn Anwälte haben auch viel Emailkontakt mit der Polizei, Staatsanwaltschaften usw. .  Es will sicherlich niemand seine Aussage/Anzeige/ V-Manninfo von irgendwelchen in- und ausländischen Gruppen dekodiert bekommen, oder ?

Hier ein paar Sätze, die sinngemäß in den Gesprächen enthalten waren:

Auf die Frage: „Können Sie nicht einfach auf dem Dienstweg die Information weiterleiten?“

„Da ist eine andere Polizeibehörde, da haben wir keinen Dienstweg.“ ( PD Braunschweig )
„Das ist ein anderes Bundesland, da sind wir nicht weisungsbefugt.“  ( LKA Niedersachsen )
„Ich habe keine Ahnung wovon Sie da reden.“ ( Staatskanzlei Sachsen )

Die Dame in der Staatskanzlei hatte aber die passende Idee und dazugehörige Nummer von der PD Leipzig, so daß ich dort anrufen konnte, was dann über weitere Umwege zur Lösung geführt hat.

Die Behörden in Sachsen sind aus der Sicht der Polizei übrigens IT mäßig von unten nach oben frageberechtig, es kann also keiner von außen oben nachfragen, wie man dem Artikel ja auch entnehmen kann, sondern man muß jemandem am Ende der Kette aka. Mitarbeiter der PD Leipzig, z.B. ein Kripobeamter, die Sache aufnehmen lassen. Der darf dann seinen ITler fragen, was er sich da grade angehört hat und DER darf dann nach oben durchreichen, was zutun ist. Args!

Das skurillste Gespräch fand aber mit dem Netzbetreuer statt, dem Staatsbetrieb Saechsische Informatik Dienste :

„Wie sind Sie an diese Nummer gekommen ?“
„Steht im Whois des IP Bereichs drin.“
„??? Und warum rufen Sie hier an?“  ( Die Formulierung könnte leicht abgewichen sein)
„Weil ich …. entdeckt habe.“ ( die Sache mit dem SSLv3 )
„Was erwarten Sie jetzt von mir ?
„Das Sie das aufnehmen und intern weitergeben, damit es abgestellt wird.“
„Nö.“

Fazit

Dieser „Wir sind aber eine andere Behörde Kram“ ist doch dem Informanten egal und der Schutz von Staatsgeheimnissen sollte doch bitte schön allen Behörden am Herzen liegen. Vor allem wundert es mich ja, das überhaupt etwas Polizeiarbeit bundeslandübergreifend stattfindet, wenn die keinen Dienstweg dafür haben, wie machen die das dann ?!?!?!

Wie sorgt man nun auf seinem eigenen Mailserver dafür, daß SSLv3 nicht mehr geht ?

Also zunächst mal wärs ratsam ein aktuelles Linux zu haben, weil darauf aktuelle OPENSSL und GNUSSL Versionen wären. Je nach dem welche Kryptobibliothek man verwendet, gibt es unterschiedliche Wege.

Für Exim hält man sich am besten an dies hier: https://lists.exim.org/lurker/message/20141017.093614.e5c38176.de.html

Um eine Neukompilierung kommt man wohl nicht drumherum. Für den Anfang reicht es natürlich schon, wenn man SSv3 ans Ende und TLSV1.2 an den Anfang der Protokollverhandlungen stellt. Damit fällt SSLv3 dann praktisch auch weg.

 

Häufigkeit von TLS Ciphern

Ich hatte etwas Zeit für eine kleine Analyse und wollte eigentlich mal nachsehen, ob noch jemand SSLv3 statt TLS für Verbindungen zu unseren Mailservern benutzt. Also habe ich die Logfiles der letzten 4 Wochen nach den Verbindungsparametern gefiltert. Folgende Studie kam dabei heraus:

gezähltCipher
1TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128
1TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256:
1TLSv1.2:ECDHE-RSA-AES128-SHA:128
3TLSv1:DHE-DSS-AES256-SHA:256
5TLSv1.2:DHE-RSA-AES128-SHA256:128
6TLSv1.1:ECDHE-RSA-AES128-SHA:128
6TLSv1.2:EDH-RSA-DES-CBC3-SHA:168
7TLSv1.2:AES128-GCM-SHA256:128
10TLSv1.2:DES-CBC3-SHA:168
11TLSv1.1:AES256-SHA:256
12TLSv1.1:DHE-RSA-AES256-SHA:256
13TLSv1.2:CAMELLIA256-SHA:256
24TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:
40TLSv1.2:DHE-RSA-AES256-SHA256:256
82TLSv1:EDH-RSA-DES-CBC3-SHA:168
83TLSv1:DHE-RSA-AES128-SHA:128
228TLSv1.2:ECDHE-RSA-AES128-SHA256:128
294TLSv1.2:AES256-SHA256:256
316TLSv1:DES-CBC3-SHA:168
386TLSv1:DHE-RSA-CAMELLIA256-SHA:256
455TLSv1.2:DHE-RSA-AES256-SHA:256
461TLSv1.2:AES128-SHA:128
606TLSv1.1:ECDHE-RSA-AES256-SHA:256
745TLSv1.2:AES256-SHA:256
760TLSv1.2:AES128-SHA256:128
2345TLSv1.2:DHE-RSA-AES128-SHA:128
2663TLSv1.2:ECDHE-RSA-AES256-SHA:256
3234TLSv1:AES128-SHA:128
9522TLSv1:DHE-RSA-AES256-SHA:256
9762TLSv1.2:AES256-GCM-SHA384:256
14110TLSv1:ECDHE-RSA-AES128-SHA:128
16894TLSv1.2:ECDHE-RSA-AES256-SHA384:256
18719TLSv1:AES256-SHA:256
36597TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
53900TLSv1:ECDHE-RSA-AES256-SHA:256
89330TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128
175139TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256

Grundlage der Studie sind 436.746 Emails, die unsere Server erreicht haben, also nicht, was gesendet wurde.

Was ich schonmal positiv finde, ist das Fehlen von SSL als Protokoll. Alle transportgesicherten Emails waren mit TLS gesichert. Leider konnten mich die eingesetzten/ausgehandelten Cipher nicht so beglücken z.b. TLSv1:AES256-SHA:256 . TLSv1 ist eigentlich SSLv3, nur leicht modifiziert und bereits erfolgreich gebrochen worden.

Um die Frage, die einigen Lesern auf der Zunge brennt: „Wieso lasst Ihr das zu?“ zu beantworten: Weil sonst keine Emails mehr bei den Kunden ankommen würden. Die Realität sieht nämlich leider so aus, daß die meisten Mailserver nicht auf Stand sind und es diesen Sendern auch egal ist. Die Senden zur Not auch ohne TLS. Heute erst bei der größten Film- und Fernseheproduktionfirma aus Hollywood erlebt.

Transportverschlüsselung wird also von vielen Firmen und Mailserverbetreiber immer noch als „egal, Hauptsache Mail kommt an“ abgetan und solange Ihr als Kunden nicht darauf besteht, daß der benutzte Mailserver A) TLS kann und B) den besten Cipher wählt der verfügbar ist, wird sich auch nichts ändern.

Unsere Server handeln den besten Cipher aus, der verfügbar ist. Versprochen 😉

interessant zu wissen wäre jetzt noch, welche Mailserver hinter den veralteten Ciphern stehen, nur kann ich damit leider nicht dienen.