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!

gebrochene Verschlüsselung: internet-sicherheit.de

Aus der Kategorie „Sachen zum Lachen“:

HEUTE

Das if(is) – Institut für Internet-Sicherheit,Westfälische Hochschule, Gelsenkirchen“

in

„Das if(is) gibt zusammen mit dem Bundesministerium für
Wirtschaft und Energie (BMWi) einen IT-Verschlüsselungs Kompass heraus“

Das ist passiert:

Das If(is) ( ob das mit den Klammern so gewollt war ??? ) hat zusammen mit dem BMWi und einer Consulting Firma einen Ratgeber für den „Mittelstand“ zum Thema „Einsatz von Verschlüsselung“ herausgegeben. Klang erstmal gut, weil das Thema recht komplex sein kann. Bei genaueren Hinsehen, und wenn ich das mit Hinweis hierauf : Mailserver – Gebrochenes TLS im Einsatz noch mal betonen darf, „genau hinsehen ist eine so dumme Idee“, aber leider kann ich diese schlechte Angewohnheit nicht ablegen, entblößt sich dieser Kompass weniger als Kompass, denn mehr als Nadel ohne magnetischen Inhalt 😀

Glücklicherweise gibt der Kompass selbst dieses Motto über sich aus :

Dieses Dokument soll Unternehmen als Orientierung dienen, an welchen Stellen eine Verschlüsselung
sinnvoll ist und welche Möglichkeiten der Umsetzung zur Verfügung stehen.“ ( Seite 6 )

Dieser Eigenbeschreibung wird das Dokument gerecht, aber so ganz ergeben einige Tabellen keinen Sinn. Aber damit wollen wir uns nicht weiter belasten 🙂

Auf Seite 7 heißt es dort „Eine versendete E-Mail erfüllt somit keine IT-Sicherheitseigenschaften zum Schutz vor Einbli-
cken durch Dritte.“ und „81 Prozent der Unternehmen sind lt. BVDW in Deutschland bereits jetzt der Meinung, dass die Sicherheit der E-Mail-Kommunikation stark verbesserungswürdig ist.“ (BVDW könnte wohl Bundesverband der deutschen Wirtschaft lauten)

Ja, an sich könnte man dem zustimmen. Solange es Leute wie das if(is) gibt, die 10 Jahre alte Verschlüsselungstechniken einsetzen, ist das Medium auch wirklich unsicher. Wie jetzt, Ihr glaubt nicht, daß ein Zitat(http://www.internet-sicherheit.de) :

„Institut für Internet-Sicherheit

für mehr Vertrauenswürdigkeit und IT-Sicherheit“

unsichere Verschlüsselung einsetzt ??? .. ok, das können wir ändern… Büdde schön … der Beweis*:

Checking a@internet-sicherheit.de:looking up MX hosts on domain „internet-sicherheit.de“

  1. smtp.internet-sicherheit.de (preference:10)

Trying TLS on smtp.internet-sicherheit.de[194.94.127.56] (10):

secondstest stage and result
[000.093]Connected to server
[000.325]<–220 smtp.internet-sicherheit.de ESMTP
[000.325]We are allowed to connect
[000.325] –>EHLO checktls.com
[000.419]<–250-smtp.internet-sicherheit.de
250-PIPELINING
250-SIZE 104857600
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
[000.419]We can use this server
[000.420]TLS is an option on this server
[000.420] –>STARTTLS
[000.512]<–220 2.0.0 Ready to start TLS
[000.512]STARTTLS command works on this server
[000.809]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 (smtp.internet-sicherheit.de = smtp.internet-sicherheit.de | DNS:smtp.internet-sicherheit.de | DNS:smtp2.internet-sicherheit.de)
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=03:af:98:64:78:06:6f:ae:36:a9:04:e1:d8:9f:65:8f:d8:14
subject= /CN=smtp.internet-sicherheit.de
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
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
[001.254] ~~>EHLO checktls.com
[001.350]<~~250-smtp.internet-sicherheit.de
250-PIPELINING
250-SIZE 104857600
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
[001.351]TLS successfully started on this server
[001.351] ~~>MAIL FROM:
[001.460]<~~250 2.1.0 Ok
[001.461]Sender is OK
[004.645] ~~>QUIT
[004.738]<~~221 2.0.0 Bye

*) Getestet am 27.2.2018 um 11:30 Uhr

Der Bericht ist leicht gekürzt. Wer den in Gänze sehen will, kann es bei checktls.com selbst prüfen.

Das ist fast schon peinlicher als beim BSI. Naja, eigentlich nicht, ist der gleiche Level.

Interessanterweise, kann der Mailserver der Westfälischen Hochschule, die das Angebot vom if(is) technisch laut Whois betreut, TLS 1.2 . Da fragt man sich, wie das wohl passiert ist 🙂

Trying TLS on mail1.w-hs.de[194.95.250.90] (10):

secondstest stage and result
[000.110]Connected to server
[000.679]<–220 mail1.w-hs.de ESMTP
[000.680]We are allowed to connect
[000.680] –>EHLO checktls.com
[000.790]<–250-mail1.w-hs.de
250-8BITMIME
250-SIZE 41943040
250 STARTTLS
[000.791]We can use this server
[000.791]TLS is an option on this server
[000.791] –>STARTTLS
[000.900]<–220 Go ahead with TLS
[000.900]STARTTLS command works on this server
[001.260]Connection converted to SSL
SSLVersion in use: TLSv1_2
Cipher in use: DHE-RSA-AES128-GCM-SHA256

Natürlich haben wir versucht, die Westfälische Hochschule, genauer die ZIM-IT zu erreichen, aber „Aufgrund von technischen Störungen“ war eine Kontaktaufnahme nicht möglich. Bei mehreren Leuten aus der Abteilung wurde es auch telefonisch versucht, aber alle ausgeflogen.

Da bleibt leider nur der Weg, es mal über die gebrochene TLS Strecke zu versuchen. Welch Ironie 😀

Der Gegentest

Der Gegentest war eigentlich nicht nötig, aber falls noch Zweifel bestanden :

2018-02-27 12:13:59 => information@internet-sicherheit.de R=dnslookup T=remote_smtp H=smtp.internet-sicherheit.de [194.94.127.56] X=TLSv1:AES256-SHA:256

Der Cipher ist jetzt auch nicht wirklich brauchbar, um genau zu sein, daß ist wohl so ziemlich der simpelste Cipher der möglich ist. Nur AES-128-SHA:256 wäre noch schlechter 😀 Gibt es eigentlich einen AES-128-MD5 ??? 😀

Trotz des groben Schnitzers mit dem TLS, kann man den Kompass zur „leichten Orientierung“ an bislang unbelastete Unternehmer weitergeben. Der Inhalt ist nicht an sich schlecht. In Teilen ist er aber noch verbesserungswürdig. bspw. die Tabelle auf Seite 14 macht erst nach dem dritten oder vierten mal Sinn. Der Inhalt paßt aber nicht zur Beschreibung.

Auch die Empfehlung, daß kleine Unternehmen mehr oder minder aufwendige Prozeduren manueller Art machen sollen, statt sich einfach für 7,99 € im Monat einen Emailanbieter wie „uns“ zu mieten, der Auto GPG und Keymanagement inkl. anbietet(und TSL 1.2 kann 😉 ), erschließt sich mir jetzt nicht direkt. Da sind wohl Annahmen im Spiel, die einfach falsch sind.

Vielleicht schreibe ich ja dazu nochmal was.

Mailserver – Gebrochenes TLS im Einsatz

Wer erinnert sich noch an diesen Beitrag BSI versendet Emails ohne TLS Verschlüsselung oder den hier : Sächsische Polizei benutzte gebrochene Verschlüsselung? Ja, genau, es geht wieder um Transportverschlüsselung von Mailservern. Ich habe mal wieder hingesehen 🙂 Von den angekündigten „Args“ habe ich aber wegen der Lesbarkeit Abstand genommen 😉 Einige Gespräche mit IT Abteilungen sind auch merkwürdig verlaufen und finden daher hier keinen Einzug.

Etwas TLS Kontext

Ich habe auf unserer Serverfarm letzte Woche eine Umfrage gemacht, welche TLS Versionen im Einsatz sind und eine entsprechende Domainliste mit veralteter TLS 1.0 oder TLS 1.1 Versionen erstellt. Die Liste ist 884 Domains lang und natürlich nur ein Bruchteil aller weltweit betroffenen Server. Man muß auch dazu sagen, daß es nicht immer die Mailserver einer Domain selbst sind, sondern auch veraltete und schlecht gewartete Mailprogramme, z.b. Outlook und AppleMail.

Was ich nicht erwartet hatte war, daß die jeweiligen PCs auf dem aktuellen Stand sind und trotzdem mit TLSv1 Kontakt aufnehmen. Der untersuchte Apple Mac hatte alle Securityupdates eingespielt und sendet, genau wie ein Win7 + Outlook PC, trotzdem nur mit TLSv1(.0). Ob das Absicht ist ?

Die zweite Meinung vom BSI

Um eine zweite Meinung zum Thema „Einsatz von TLS 1.0 und 1.1 im Unternehmerischen Umfeld“ zu bekommen, habe ich mich an das Bundesamt für Sicherheit in der Informationstechnik und deren Sicherheitsberatung gewendet. Folgende Antwort auf die Frage, ob man TLS 1.0 und 1.1 noch einsetzen kann, kam bei mir an:

Sehr geehrte Damen und Herren,

vielen Dank für Ihre Anfrage nach der Sicherheit beim Einsatz von Transport
Layer Security (TLS).

Das BSI hat für den Einsatz von TLS eine technische Richtlinie erstellt,
"Technische Richtlinie TR-02102-2 Kryptographische Verfahren: Empfehlungen und 
Schlüssellängen Teil 2 – Verwendung von Transport Layer Security (TLS)":
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf
https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html

Laut der technischen Richtlinie gelten TLS 1.0 und TLS 1.1 als unsicher und 
werden nicht mehr empfohlen.

Für die Bundesverwaltung hat das BSI einen Mindeststandard zum Einsatz von
TLS entwickelt, der für die Stellen des Bundes verbindlich umzusetzen ist:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Mindeststandards/Mindeststandard_BSI_TLS_1_2_Version_1_0.pdf 
https://www.bsi.bund.de/DE/Themen/StandardsKriterien/Mindeststandards/SSL-TLS-Protokoll/SSL-TLS-Protokoll_node.html

Dieser Mindeststandard referenziert die technische Richtlinie TR-02102-2 und
fordert für die Bundesverwaltung den Einsatz von TLS 1.2 mit PFS.

Wir hoffen, Ihnen mit diesen Informationen gute Argumente für die Stärkung
der Informationssicherheit in Ihrem Unternehmen geliefert zu haben.

Mit freundlichen Grüßen
das Team Sicherheitsberatung

Also ganz wichtig diese Passage :

Dieser Mindeststandard referenziert die technische Richtlinie TR-02102-2 und fordert für die Bundesverwaltung den Einsatz von TLS 1.2 mit PFS.

Mit anderen Worten, überspitzt, es darf nur noch TLSv1.2 mit PFS eingesetzt werden, weil 1.0 und 1.1 als gebrochen gelten, alles andere wäre ja fahrlässig. Oder liest da jetzt jemand was anderes raus 😉 ? Dazu später noch mehr.

Die Liste

Bevor ich Euch hier die Liste der Domains präsentiere, muß ich noch mal auf den Kontext hinweisen. Die Liste ist stark gekürzt und nach bestem Wissen von Fehlern durch Endgeräte bereinigt. Auch könnten SPAMMER im Namen einer Domain Mails geschickt haben, das konnte nicht bereinigt werden. Wer sich auch immer auf dieser Liste wiederfindet, sollte das zum Anlass nehmen, mal seine Mailinfrastruktur zu prüfen.
amazon.de
aol.de
apaed.tu-darmstadt.de
appelmann.de
architekten-stade.de
bistum-dresden-meissen.de
blog.magento-agentur-muenchen.de
bounce.academia-mail.com
bounce.crm.glamour.de
bounce.info.bonprix.de
bounce.kommunikation.wuv.de
bounce.kundenservice.dpv.de
bounce.mailing.adac.de
bounce.mail.verivox.de
bounce.news.ing-diba.de
bounce.newspromo.de
bounce.reedexpo-email.com
bounces.amazon.de
bounces.audible.de
burggymnasium.de
cornelsen.borekmedia.de
deutschepost.de
dgs.de
dhl.de
flyeralarm.de
heidelberger-coaching.de
kundenservice.vodafone.com
lists.tu-darmstadt.de
login.power-nic.de
mail.edeka.de
mail.paypal.de
news.experten.de
news.haendlerbund.de
news.hagebaumarkt.de
news.hamburg-messe.de
news.heide-park.de
newsletter.bund.de
newsletter.sparkasse-koelnbonn.de
newsletter.spkhb.de
nomail.hrz.tu-darmstadt.de
paypal.de
postbank.de
postpay.de
service.de.jura.com
service.hsv.de
service.meine-verbraucherzentrale.de
sternfreunde-braunschweig.de
sw.mail.edeka.de
tigersoft.de
tu-braunschweig.de
uk-koeln.de
unitymedia.de
uni.leuphana.de
wiso.uni-hamburg.de
facebookmail.com
support.facebook.com
mail.paypal.de
paypal.at
paypal.com

Bei diesen Domainnamen handelt es sich um die Domains der Sender, nicht der Mailserver selbst. Beispiel: nomail.hrz.tu-darmstadt.de.

Die Rückmeldungen

Von einigen habe ich natürlich schon Rückmeldung bekommen. Ohne Namen zu nennen, waren einige lahm, andere ausweichend:

Es steht auch bereits ein neues Mailsystem zur Verfügung. Aufgrund interner Umstrukturierungen bei *** verzögert sich dessen Verwendung jedoch noch etwas.

WAS ? 10 JAHRE!!!

Nach zehn Jahren kommt es dann auf ein, zwei zusätzliche Jahre auch nicht mehr an 😉 Was 10 Jahre schon? Ja, laut der Liste bei Wikipedia, erschien TLS1.2 2008 auf der Bühne. Da wir 2018 haben, sind das jetzt sportliche 10 Jahre 🙂

SSL 3.1 bzw. TLS 1.01999
TLS 1.12006
TLS 1.22008

Nein, ich möchte dazu keinen zitierfähigen Kommentar abgeben.

Wesentlich besser war diese Antwort:

„...danke für den Hinweis. Da war das letzte Software Update weniger schlau als wir dachten 😐
Unsere 3 Server sollten jetzt mit der korrekten TLS Version senden.“ (Rechtschreibfehler behoben)

PayPal hat sich jedes Kommentars verweigert. Da PayPal auch Finanzinformationen per Mail verschicken könnte, wurde die BaFin eingeschaltet. Tja, ich war ja schon froh, daß nicht wieder die Polizei oder ein Bundesland .. ups.. glatt übersehen :

landkreis-helmstedt.de

Ich habe natürlich mit dem zuständigen Herrn telefoniert und er hat sofort verstanden worum es ging und wird es umgehend beheben. Dafür Daumen rauf ! Das war bislang der produktivste Kontakt aller kontaktierten Problemfälle.

Das CERT-BUND, auch betreut vom BSI, hat geschrieben:

vielen Dank für den Hinweis auf die TLS 1.0 Verwendung beim Newsletter-Versand über "newsletter.bund.de". Der IT-Dienstleister prüft, ob kurzfristig eine Umstellung auf TLS 1.2 möglich ist.

Mittelfristig ist geplant, dass der Newsletter-Versand über "mx.bund.de" erfolgt.

Mit freundlichen Grüßen
das Team CERT-Bund

geht doch 😀

Eine gängige Antwort war: „Schicken Sie mir das per EMail“ oder „Was erwarten Sie jetzt von mir?“ . Letzterer Satz kommt mir so bekannt vor ;D

Die Krönung

Aber wollt Ihr wissen, wer wirklich den Vogel abgeschossen hat ? Das war das BSI selbst 😀

2018-02-19 13:13:17 1enkJl-0007Vh-Ox <= sicherheitsberatung@bsi.bund.de H=m2-bn.bund.de [77.87.228.74] P=esmtps X=TLSv1:ECDHE-RSA-AES256-SHA:256 CV=no S=4513

Ich hatte ein zitierfähiges Statement fürs Blog angefordert, aber zur Zeit schweigt sich das BSI aus 🙂

Wer wissen will, was der Bund so alles über unsichere Mailverbindungen rausschickt :

2018-02-14 15:07:11 1elxiH-0003H1-Bi <= buerger-cert-newsletter_pgp@newsletter.bund.de H=newsletter.bund.de [77.87.229.56] P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256 CV=no S=12118
2018-02-14 15:22:28 1elxx4-0008OP-2j <= buerger-cert-newsletter@newsletter.bund.de H=newsletter.bund.de [77.87.229.56] P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256 CV=no S=5631
2018-02-16 13:27:45 1emf79-0005ne-Hd <= BGH-Pressemitteilungen@newsletter.bund.de H=newsletter.bund.de [77.87.229.56] P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256 CV=no S=4497

Und so muß das eigentlich immer aussehen :

2018-02-19 13:18:37 1enkOw-0008B0-OH <= 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=3920

Der Kommentar

Ich glaube ja jetzt nicht, daß über die Newsletter vertrauliche Kommunikation läuft, aber gerade noch empfiehlt das BSI dem Bund nur TLSv1.2 einzusetzen und dann patzt der eigene BULK-Mailserver bei genau diesem Thema, das geht doch nicht Leute. Ihr habt eine Vorbildfunktion. Wenn Ihr das falsch macht, wer soll den Leuten das sonst zeigen?

Immerhin reagierte das BSI beim letzten mal binnen 24h auf das Problem, noch ist Zeit das zu unterbieten 😉 Aber es wird knapp …. und verloren .. Zeit ist um 😀 Die Stellungnahme hat zu lange gedauert (s.o.) .

Empfohlene Tools

Es gibt eine nette Seite, die für einen den TLS Check macht :

https://www.checktls.com/perl/live/TestReceiver.pl

Eine Beispielausgabe für Bloggt-in-braunschweig.de habe ich hier mal für euch:

Trying TLS on s120.resellerdesktop.de[83.246.80.133] (10):

secondstest stage and result
[000.100]Connected to server
[000.206]<–220 localhost.localdomain ESMTP Exim 4.89 Tue, 20 Feb 2018 10:55:04 +0100
[000.207]We are allowed to connect
[000.207] –>EHLO checktls.com
[000.307]<–250-localhost.localdomain Hello www6.checktls.com [159.89.187.50]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250-STARTTLS
250 HELP
[000.307]We can use this server
[000.308]TLS is an option on this server
[000.308] –>STARTTLS
[000.411]<–220 TLS go ahead
[000.411]STARTTLS command works on this server
[000.656]Connection converted to SSL
SSLVersion in use: TLSv1_2
Cipher in use: ECDHE-RSA-AES128-GCM-SHA256
Certificate 1 of 3 in chain: Cert VALIDATED: ok
Cert Hostname VERIFIED (s120.resellerdesktop.de = s120.resellerdesktop.de | DNS:pma.s120.resellerdesktop.de | DNS:s120.resellerdesktop.de | DNS:webmail.s120.resellerdesktop.de | DNS:www.s120.resellerdesktop.de)
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=03:be:8f:cc:06:04:d3:6c:18:2a:45:87:b2:11:be:b4:dc:22
subject= /CN=s120.resellerdesktop.de
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
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
[001.048] ~~>EHLO checktls.com
[001.148]<~~250-localhost.localdomain Hello www6.checktls.com [159.89.187.50]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250 HELP
[001.148]TLS successfully started on this server
[001.149] ~~>MAIL FROM:
[001.249]<~~250 OK
[001.249]Sender is OK
Hier war eine TEST EMAILADRESSE von uns drin.
[001.350]Note: This does not affect the CheckTLS Confidence Factor
[001.351] ~~>QUIT
[001.452]<~~221 localhost.localdomain closing connection

So (oben) muß das aussehen, aber auf keinen fall so (unten) :

secondstest stage and result
[000.117]Connected to server
[000.720]<–220 mailer.faller.de ESMTP mailgw ready.
[000.720]We are allowed to connect
[000.721] –>EHLO checktls.com
[000.830]<–250-mailer.faller.de checktls.com [www6.checktls.com] pleased to meet you.
250 DSN
[000.831]We can use this server
[000.831]TLS is not an option on this server
[000.831] –>MAIL FROM:
[000.955]<–250 OK
[000.955]Sender is OK
[000.956] –>RCPT TO:
[001.088]<–450 Temporary denied.
[001.089]Cannot proof email address (reason: RCPT TO rejected)
[001.089]Note: This does not affect the CheckTLS Confidence Factor
[001.089] –>QUIT
[001.204]<–221 Closing connection.

In dem Sinne, checkt mal Eure Mailserver, ob die TLSv1.2 können und wenn nicht, warum!

Wer Fragen zu seiner Domain hat (bitte von der Domain senden) kann diese an „marius äd bloggt-in-braunschweig.de“ stellen, wir suchen gerne raus, was genau im Log steht. Dies Angebot kann aufgrund der entsprechenden Vorschriften nur eine begrenzte Zeit aufrecht gehalten werden.

Ach ja, im Rahmen der Krypto-Party der BS-LUG am 21. 2. 2018 um 18 Uhr im Haus der Talente, Braunschweig. sprechen wir mal drüber 😉

eine Weisheit

Wenn man die Scheisse Anderer nicht auslöffeln will,
sollte man den Stein, unter dem sie zu finden ist, nicht umdrehen.

Ein Teaser

Es folgt (vermutlich) bald(tm) ein Beitrag zum Thema Mailserver-TLS und es kommen oft die Worte „WIESO?“ ,“unsicher“,“gebrochen“ und vermutlich „args!“ darin vor. Die Liste der Verdächtigen beinhaltet das Who-is-Who nationaler und internationaler Konzerne.

hmm

Da ich ja schon früher über TLS geschrieben habe, wär es dann nicht eigentlich ein Cliffhanger in einer Endlos-Storyline ? 🙂

Followup – Der SSLv3 Stand

Ihr erinnert Euch noch an diese Beiträge zum Thema SSLv3 aus 2016 ?

Sächsische Polizei benutzte gebrochene Verschlüsselung

Neue TLS Probleme beim BSI

Häufigkeit von TLS Ciphern

Stand der Dinge

Ich habe mir mal gedacht, dies Analyse 2 Jahre danach nochmal zu machen und bin zu dem erfreulichen Ergebnis gekommen, daß kein Kontakt der letzten 4 Wochen noch mit SSLv3 um die Ecke gekommen ist. Natürlich hat das jetzt auch einen deftigen Nachteil, ich habe nichts über das man schreiben könnte 😉 Ich finde aber, daß ich den Preis gerne bezahle 😀

Naja, machen wir doch noch was daraus, das Update der meist benutzten Chipers der letzten 4 Wochen :

214417xTLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
109616xTLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128
40927xTLSv1:ECDHE-RSA-AES256-SHA:256
19728xTLSv1.2:ECDHE-RSA-AES256-SHA384:256
16346xTLSv1:ECDHE-RSA-AES128-SHA:128
12112xTLSv1:AES128-SHA:128
9864xTLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
7270xTLSv1:DHE-RSA-AES256-SHA:256
7139xTLSv1.2:AES256-GCM-SHA384:256
6924xTLSv1:AES256-SHA:256
3767xTLSv1.2:AES128-SHA256:128
2649xTLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256
2443xTLSv1.2:DHE-RSA-AES128-SHA:128
2062xTLSv1.2:ECDHE-RSA-AES256-SHA:256
1226xTLSv1.1:ECDHE-RSA-AES256-SHA:256
805xTLSv1.2:AES128-SHA:128
748xTLSv1.2:DHE-RSA-AES256-SHA:256
442xTLSv1.2:AES256-SHA:256
362xTLSv1:DHE-RSA-CAMELLIA256-SHA:256
167xTLSv1:DES-CBC3-SHA:168
151xTLSv1.2:AES256-SHA256:256
135xTLSv1.2:ECDHE-RSA-AES128-SHA256:128
59xTLSv1:EDH-RSA-DES-CBC3-SHA:168
51xTLSv1.2:DHE-RSA-AES256-SHA256:256
40xTLSv1.2:AES128-GCM-SHA256:128
35xTLSv1:DHE-RSA-AES128-SHA:128
22xTLSv1.1:DHE-RSA-AES256-SHA:256
14xTLSv1.1:AES256-SHA:256
5xTLSv1.2:DHE-RSA-AES128-GCM-SHA256:128
3xTLSv1:DHE-RSA-DES-CBC3-SHA:168
3xTLSv1.2:ECDHE-RSA-AES128-SHA:128
2xTLSv1.2:ECDHE-RSA-DES-CBC3-SHA:168
1xTLSv1.2:DHE-RSA-CAMELLIA256-SHA:256
1xTLSv1.1:AES128-SHA:128

Bei 459.536 Emailtransporten insgesamt, ist der hohe Anteil an TLSv1 Protokollen doch erschreckend.

Die beiden Spitzenplätze sind gleich geblieben, aber in nachfolgenden Rängen, hat sich einiges, und das nicht zu guten getan, wenn ich das mit dem Beitrag vom März 2017 vergleiche. Am besten macht Ihr Euch da selbst ein Bild.