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.

Lets Encrypt: Zertifikatsprobleme auf iOS Geräten

Seit Dezember 2015 stellt Lets Encrypt kostenlose Zertifikate zur Verfügung. Damit kann man Webseiten und Mailserver schützen, wenn da nicht die liebe Realität in Form von iOS wäre.

Bei unserem hausinternen Versuch, die Mailserver von einem kommerziellen Comodozertifikat auf Lets Encrypt umzustellen, was für Webseiten überhaupt kein Problem war, stellte sich raus, das sofort alle iOS Endgeräte, egal ob iPhone 5,6,7 oder iOS 9,10 keine Emails mehr empfangen konnten. Entäuschenderweise war auch Thunderbird betroffen 🙁

Daraufhin haben wir auf ein Comodozertifikat umgestellt und die Lage beruhigte sich, bis einige iOS Geräte anfinden, nur noch Emails zu senden, aber keine mehr zu empfangen. Wohlgemerkt, mit dem gleichen SSL-Zertifikat 😉

Nach derzeitigen Erkenntnissen seitens Comodo und unseren Technikern, liegt das Problem beim iOS Gerät selbst. Mal sehen was Apple dazu meint.

Auflösung: Mail.APP ist buggy, denn jedes andere installierte Emailprogramm auf einem betroffenen IPhone hat das Zertifikat einwandfrei akzeptiert. Aber der Witz kommt jetzt, dem Kunden hat das neue Mailprogramm „My Mail“  viel besser gefallen als die original App 😀

 

TLS: Wie man sich selbst austrickst

Nicht das einer meiner geneigten Leser glaubt, ich hätte zuviel Phantasie oder mir wäre das selbst passiert und ich würde es jetzt in einer netten Story schön reden wollen, vergeßt es, es ist tatsächlich so passiert.

Was ist TLS ?

Um zu verstehen was genau passiert ist, muß ich etwas ausholen, da nicht jeder Leser wissen wird, was TLS genau macht.

Erstmal TLS ist die Transport Layer Verschlüsselung(Security) für Emailserver und Webseiten und hat SSL ( Secure Socket Layer ) abgelöst, weil es a) ein paar Vorteile gegenüber SSL hat und b) nicht komplett gebrochen ist wie SSL. (Ja, SSL ist tod, wer noch SSL 1-3 benutzt, kann es auch abschalten und die Rechenleistung anderweitig nutzen 😉 ).

Wenn ein Mailprogramm einen Mailserver mit TLS Unterstützung kontaktiert, tut er das auf den an sich unverschlüsselten Port 25. Der Mailserver meldet dem sich verbindenden Programm/Client/Server welche Möglichkeiten der Server anbietet, z.B. den Befehl STARTTLS . Finden ein sich verbindendes Programm diesen Befehl, wird es diesen Aufrufen und damit die Verbindung von unverschlüsselt auf verschlüsselt „upgraden“ .  Damit man das machen kann, sendet der Mailserver seinen öffentlichen Schlüssel in einem Zertifikat an das verbindende Programm und das baut daraus ein passendes Antwortpaket mit einem Sessionkey, der nur für diese eine Datenübertragung existiert. (Idealerweise)

Authentizität

Dabei wird geprüft, ob sich der Mailserver mit einem gültigen SSL-Zertifikat ausweist. An dieser Stelle wird es nun interessant. Unser Mailserver, kann wie die meisten Server, genau ein Zertifikat  benutzen, weil alle Domains auf seiner Hauptipadresse liegen. Für Emails ist das auch nicht tragisch, es geht ja nur um die Verschlüsselung des Transports. Also präsentiert der Mailserver sein gültiges Serverzertifikat, daß auf seinen Hostname ausgestellt ist, denn damit meldet sich der Server und damit weiß man, daß dies Zertifikat zum Host paßt. Soweit, so normal.

Die Experten

Jetzt gibt es Leute, die wollen wissen, ob sie abgehört werden, was ein naheliegendes Interesse ist. Deswegen prüfen sie, ob in dem Zertifikat das Ihnen angeboten wird, auch wirklich der Name des Mailserver drinsteht, mit dem sie sich verbinden wollen. Ist das nämlich nicht der Fall, könnte jemand an der Verbindung rumgespielt haben und sich als Man-in-the-Middle-Angreifer betätigt haben, um die Verbindung zu belauschen. Wenn ich jetzt auf Sicherheit und Authentizität wert lege, müßte ich aufhören und die EMail nicht zustellen, weil „irgendwas stimmt nicht“.

Damit Ihr mir folgen könnt, ein paar Beispiele :

$ dig mx bloggt-in-braunschweig.de
;; ANSWER SECTION:
bloggt-in-braunschweig.de. 21599 IN    MX    10 bloggt-in-braunschweig.de.

Das meint, daß die Emails für BIB.de  auf einem Mailserver mit dem Hostnamen „bloggt-in-braunschweig.de“ entgegengenommen werden. Verbindet man sich auf Port 25 dort hin, findet man das vor:

$ nc bloggt-in-braunschweig.de 25
220 s120.resellerdesktop.de ESMTP Exim 4.85_2 Sat, 27 Aug 2016 12:11:04 +0200

das meint, daß sich unser Mailserver mit „s120.resellerdesktop.de“ identifiziert, weil das sein Name ist. Entsprechend präsentiert er ein Zertifikat von s120.resellerdesktop.de . Das ist vollkommen ok so 🙂

Aber genau das ist, was einige Experten als den MITM-Angriff definiert haben, denn die haben erwartet, daß sich der Mailserver mit „bloggt-in-braunschweig.de“ meldet, was er nicht tut, weil er noch hunderte andere Domains beherbergt.

Jetzt der Catch 🙂

Statt jetzt aber die Verbindung zu trennen, wie man es bei einem MITM Angriff erwarten müßte, fällt der Expertenmailserver auf unverschlüsselte Kommunikation zurück und stellt die Email unverschlüsselt auf genau diesem Server zu!  Das ist FAIL² . Er hätte auch gleich das Zertifikat nehmen können, denn dann wäre die Email wenigstens verschlüsselt übers Netz gegangen, statt im Klartext.

Logik ist nicht jedermans Sache, wie es scheint 😀

Den Experten helfen…

Wenn man jetzt mit solchen Experten kommunizieren muß, ohne das man unverschlüsselte Emails haben will, kann man natürlich etwas tun, was allerdings mit Nachteilen daher kommt. Für den Augenblick sind diese aber vernachlässigbar.

Das Problem liegt ja in der Erwartungshaltung des sendenden Mailservers, der in unserem Beispiel bloggt-in-braunschweig.de haben wollte, aber s120.resellerdesktop.de bekommen hat. Der Name ist im DNS MX Eintrag hinterlegt, weil man so bei einem Domainumzug auf einen anderen Server lediglich einen Eintrag ändern muß. Der MX zieht quasi automatisch um.  Unsere Experten würden aber folgendes gerne sehen :

$ dig mx bloggt-in-braunschweig.de
;; ANSWER SECTION:
bloggt-in-braunschweig.de. 21599 IN    MX    10 s120.resellerdesktop.de

Wenn man also seinen MX auf den „echten“ Namen des Mailserver ändert, sind diese Expertenserver zufrieden und schicken einem ab sofort wieder reguläre TLS verschlüsselte EMails zu.

Man darf nur nicht vergessen, daß man bei einem Domainumzug auch den MX ändert, wenn der neue Mailserver anders heißt. Es ist also auch davon abhängig wie der Provider seine Umgebung betreibt.

 

1+1: „Sie haben das Internet kaputt gemacht.“

Störung des Mailversands bei 1+1

Wie aus diversen Berichten von Betroffenen hervorgeht, hat 1+1 derzeit massive Probleme Emails eigener Kunden zu versenden und Emails an Kunden zu empfangen.

Seit 10:30 Uhr heute früh hat 1+1 eine Störungsmeldung auf ihrer Seite http://status.1und1.de

Die Ursache dafür, daß man 1und1 keine Emails mehr schicken kann, liegt darin begründet, daß viele Netze eine sogenannte CNAME-Delegation haben. Damit vermeiden große Anbieter, daß jeder kleine Kunde bei RIPE ein Netz bekommt. Stattdessen werden kleine Teile des eigenen Netzes an die Nameserver des Kunden delegiert. Dadurch kann der Kunde dann eigene PTR-Records für seine IPs setzen.

Nachforschungen zu folge, funktioniert genau dieser Mechanismus bei 1+1 Mailservern derzeit nicht mehr.

1+1 selber spricht nur von Emailproblemen seiner eigenen Kunden.

Die Störung bei 1+1 fing unseren Recherchen zufolge am 3.11. gegen 14.20 Uhr an.Eine typische Meldung sieht im Log so aus : host mx-ha02.web.de [213.165.67.120]: 554-web.de (mxweb101) Nemesis ESMTP Service not available\n554-No SMTP service\n554 invalid DNS PTR resource record, IP=1.2.3.4
Daran können Sie erkennen, ob Sie betroffen sind oder nicht.Der Support von 1und1 hat dies Problem bestätigt und verweist darauf, daß es mit Nachdruck gelöst wird. Wie lange auch immer das dauern mag 🙂