[English]Das in der Netzwerkkommunikation, speziell bei E-Mails, einsetzbare Verschlüsselungsverfahren StartTLS weist eine Reihe Schwachstellen auf, die es ermöglichen, die Kommunikation aufzubrechen, indem beispielsweise Zugangsdaten gestohlen werden. Dies wurde bereits Anfang August 2021 von deutschen Sicherheitsforschern nachgewiesen.
Anzeige
Ich hatte die Information bereits Anfang August 2021 gesehen, weil einer der beteiligten Sicherheitsforscher, Hanno Böck das in diesem Beitrag bei Golem thematisierte. Stand dann auf meiner Agenda als "kannste mal thematisieren". Die Tage habe ich dann das Thema nochmals in nachfolgendem Tweet gesehen und das Thema doch mal kurz aufbereitet.
Worum geht es bei StartTLS?
Die Wikipedia hält eine Beschreibung von StartTLS bereit. STARTTLS bezeichnet ein Verfahren zum Einleiten der Verschlüsselung einer Netzwerkkommunikation mittels Transport Layer Security (TLS). Es wird vor allem bei der Kommunikation zwischen E-Mail-Servern und Clients eingesetzt, um Nachrichten per POP3, SMTP oder IMAP auszutauschen.
STARTTLS stammt aus dem Jahr 1999 und war damals adäquat, sollte es doch eine verschlüsselte Übertragungen forcieren. Ab 2018 werden nur noch vollständig verschlüsselte Übertragungen empfohlen. Bei STARTTLS wird explizit ausgehandelt, ob TLS zur Verschlüsselung genutzt werden soll.
Anzeige
Das Problem: Falls keine zusätzlichen Schutzmaßnahmen gegen einen Downgrade-Angriff umgesetzt werden, handelt es sich dabei um eine opportunistische Verschlüsselung (es wird nur verschlüsselt, falls auf beiden Seiten TLS verfügbar ist). Bei STARTTLS erfolgt der erste Verbindungsaufbau immer im Klartext. Da das Verfahren keine Vorteile mehr gegenüber TLS bietet, wird generell die Einstellung „SSL/TLS" in E-Mail-Clients empfohlen und somit von STARTTLS abgeraten.
Schwachstellen in StartTLS
Ein Team von Sicherheitsforscher, zu denen auch Hanno Böck gehört, haben sich das Verschlüsselungsverfahren genauer angesehen und ihre Ergebnisse auf der Webseite NO STARTTLS veröffentlicht. Die Kernbotschaft: StartTLS ist durch die unverschlüsselte Kontaktaufnahme und die Aushandlung der TLS-Verschlüsselung trivialerweise anfällig für Downgrade-Angriffe.
Moderne E-Mail-Clients erwarten jedoch in der Regel, dass STARTTLS erzwungen wird, und wenn es aktiviert ist, ist keine unverschlüsselte Kommunikation möglich. Die Verwendung von STARTTLS in Verbindungen ist anfällig für eine Reihe von Sicherheitslücken und Angriffen. Das Team von Sicherheitsforschern hat mehr als 40 Sicherheitslücken in STARTTLS-Implementierungen gefunden.
Die Sicherheitsforscher kamen zum Schluss, dass diese Schwachstellen so häufig sind, dass sie empfehlen, StartTLS nach Möglichkeit nicht zu verwenden. Ich erspare mir an dieser Stelle die Details, da die verschiedenen Angriffsmethoden auf der Webseite NO STARTTLS nachlesbar sind. Zudem gibt es den deutschsprachigen Golem-Beitrag von Hanno Böck, der die Probleme beschreibt. Für Leser und Leserinnen lautet die Botschaft: Prüft die Einstellungen an euren E-Mail-Clients (und ggf. für andere Kommunikationsverbindungen) und verwendet TLS statt StartTLS, sofern möglich.
Anzeige
Etwas polemisch, denn kein modernes Mailprogramm wird bei keinem vernünftigen Mailserver noch STARTTLS konfigurieren. Bei selbstbetriebenen Mailservern kann das natürlich noch vorkommen.
Du weisst schon dass es Leute gibt die seit Jahren oder Jahrzehnten email benutzen und bei Hardwarewechsel jeweils die emails und die Kontoeinstellungen auf die neue Hardware übertragen? Was zum Beispiel mit Thunderbird sehr einfach ist.
erwischt, und das mir ;-)
Ein uralter gmx.us account den ich im mobilen Thunderbird seit ewigen Zeiten für Zwangsmail Geschichten mitschleife.
gmx.us free bietet nach wie vor 10 Aliases, sehr einfach zu löschen und einzurichten. Ideal für temporäre Zwecke. Keine Werbung, Spam etc.
TLS gibt es nicht erst seit zwei Jahren. Alle zehn Jahre oder so kann man ruhig mal seine Einstellungen überdenken und ausmisten.
Das ist so nicht ganz richtig. Bis heute wird STARTTLS aktiv verwendet und oft genug müssen Anwender selbst Hand anlegen und die Einstellungen ändern. Bei Thunderbird kann man dann SSL/TLS auswählen.
Tja bei vernünftigen Mail Servern vielleicht nicht. Aber Thunderbird in Verbindung mit kostenlosen Outlook Konten bedeutet zumindest beim Postausgangsserver StartTLS, denn anders geht es leider nicht!
Bin gerade vom Sport zurück – vorher schnell den Artikel verfasst und gepostet, jetzt mal alle E-Mail-Konteneinstellungen überprüft. Nur beim eigenen 1&1-E-Mail-Konto war noch StartTLS eingestellt – inzwischen geht dort aber SSL/TLS. Alle anderen E-Mail-Konten, darunter auch ein outlook.de-Konto meiner Frau, waren bereits auf SSL/TLS eingestellt.
Hast Du POP3/SMTP? Ich habe IMAP für das Outlook-Konto eingestellt.
Korrektur: Ja, Du hast Recht – habe es explizit getestet – der TB 78 kann bei SSL/TLS beim Postausgangsserver von hotmail.com, outlook.com, outlook.de, web.de die neuen Mails nicht erfolgreich versenden, sondern läuft sich tot und endet mit einem Timeout. Also gmail.com oder einen anderen Freemailer nehmen.
kann man dort die Ports nicht manuell wählen?
Korrektur von der Korrektur:
Bei web.de konnte ich auf SSL/TLS umstellen, indem ich manuell den Port 465 gewählt habe.
Bei outlook.de und hotmail.com bin ich gescheitert – mal geht es scheinbar, dann aber wieder nicht. Egal, was ich da einstelle – da hat der anonyme Poster Recht. Wieder was gelernt. Mal sehen, vielleicht erstelle ich einen separaten Beitrag, in dem ich für nicht so fitte Nutzer zeige, wie was eingestellt sein soll, damit SSL/TLS genutzt wird.
@Günter Born
Bzgl. web.de. – Unter Thunderbird 91 wurde hier bei der Auswahl von SSL/TLS automatisch auf Port 465 umgestellt. Senden von Mails funktioniert.
Sollte man nicht besser Port 587 einstellen statt Port 465?
Zitate aus de KINSTA-BLOG:
"Port 587 ist der Standardport für die SMTP-Übermittlung im modernen Web."
"Port 465 war ursprünglich für SMTPS (SMTP over SSL) registriert. Nach einer kurzen Pause in dieser Funktion wurde Port 465 für eine andere Verwendung neu zugewiesen und veraltet.
Trotz dieser Tatsache unterstützen viele ISPs und Cloud-Hosting-Provider immer noch Port 465 für die SMTP-Einreichung."
@Günther Born
@Ralf Lindemann
Unter TB 78.13.0 wird ebenfalls automatisch auf Port 465 umgestellt, wenn man SSL/TLS auswählt. Ich meine, das ist schon seit Jahren so.
Was Outlook angeht, zumindest für outlook.com gibt MS noch STARTTLS an:
https://support.microsoft.com/de-de/office/pop-imap-und-smtp-einstellungen-f%C3%BCr-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040
Wir sollten die Polemik raus lassen. Als Thunderbird-Nutzer habe ich gerade gelernt, dass dieser zwingend beim SMTP-Versand StartTLS für Freemail-Konten wie hotmail, outlook, web.de erfordert.
Das liegt nicht an Thunderbird, sondern am Mailserver. Ist eben kein vernünftiger.
STARTTLS war auch vor dieser neuen Veröffentlichung schon seit Jahren nicht mehr zu empfehlen.
STARTTLS bei Web.de finde ich erstaunlich; bei GMX funktioniert SSL/TLS auch beim ausgehenden SMTP-Server problemlos. Ich habe hier seit Jahren nichts anderes als SSL/TLS in Thunderbird eingestellt – inkl. Gmail.
Siehe meine obigen Ergänzungen – ich musste den Port manuell vorgeben.
genau
StartTLS für SMTP nutzt idR POrt 587
TLS/SSL für SMTP idR Port 465
Emailprogramme (auch Outlook) schlagen gerne Port 25 für TLS/SSL vor.
Port 25 wird aber idR nur für SMTP unverschlüsselt genutzt, wenn überhaupt noch. Außerdem wird Port 25 auch gerne mal von Internetprovidern gesperrt
und auch auf einer Fritzbox gibt es eine Option um Port 25 zu sperren.
Hast Du bei den Outlook-Konten auch den Effekt, dass es einmalig mit dem Versand klappt und dann nicht mehr? Oder habe ich mich im TB bei meinen Tests selbst ins Knie geschossen?
Also bei meinem uralten Web.de-Konto (das ich nur zum Schutz vor Missbrauch nicht aufgegeben habe), klappte die Umstellung reibungslos: StartTLS mit Port 587 in den Thunderbird-Einstellungen vorgefunden, auf SSL/TLS umgestellt, dabei wurde automatisch Port 465 draus gemacht.
Mailversand geht, dreimal mit Zeitabständen probiert. Unter der Haube ist Web.de schließlich nichts anderes als GMX.
Selbiges hier: nach dem Umstellen von STARTTLS:587 auf SSLTLS:465 problemlos eine Test-Mail an verschiedene Endadressen verschickt und auch dort angekommen!
465 ist aber kein TLS, sondern SSL.
587 ist TLS.
Steht so in der Vodafone-Anleitung.
Für TLS braucht man aber eventuell auch die passenden Updates und Registry-Einträge.
Man sollte nicht nur die Mail-Programme dabei sehen. Auch Drucker versenden E-Mails. Je nach Modell kann man beim Versand von eingescannten Documenten froh sein, wenn dafür in der Konfigurationsoberfläche wenigstens STARTTLS zu Verfügung steht. Allerdings würde ich das nicht mehr für den Versand einsetzen und es besteht dabei die berechtigte Frage ob die Übermittlung per STARTTLS Befehl überhaupt noch den Datenschutzrichtlinien entspricht, auch wenn im Grunde ein Schutz gegen direktes Mitlesen vorhanden ist
Bei mir funktioniert auch Port 993 für SSL/TLS mit web.de, gmail.com und googlemail.com – letzteres sogar mit OAuth2 als Authentifizierungsmethode anstelle Passwort.
Das bezieht sich aber nur auf den Empfang, nicht auf den Versand.
Port 993 ist IMAP SSL Empfang
Port 143 ist IMAP TLS Empfang
Port 995 ist POP3 SSL Empfang
Port 110 ist POP3 TLS Empfang
Port 465 ist SMTP SSL Senden
Port 587 ist SMTP TLS Senden
465 war mal SSL.
Das es SSL (2.0 / 30.) nicht mehr gibt dürfte der Port nicht mehr funktionierten, dem ist aber nicht so!
Port 143 IMAP TLS endet bei mir (YAHOO, WEB, PYUR) immer in einem time-out.
Ich bleibe jetzt bei Port 587 SMTP TLS (STARTTLS) und Port 993 IMAP SSL (SSLTLS)!
Danke für die Hinweise!
Bei gmx steht für SMTP und TLS der Port 587 in der Anleitung, aber bei meinem Test verschickt das Mail-Programm "The Bat" die email nicht.
Nach Umstellung auf den Port 465 wird die email verschickt.
Eigentlich ist Port 465 veraltet und nur noch Legacy.
Auf Port 465 wird das ältere SSL benutzt und auf Port das neuere TLS.
Ich weiß jetzt aber nicht, warum aktuell bei mir alle Tests mit TLS und Port 587 fehlschlagen (gmx, vodafone, arcor. t-online).
Sobald ich es auf Port 465 (also SSL) umstelle, dann funktioniert es.
Kann es sein, dass die TLS-Version auch relevant ist und dass mein altes Win7 diese TLS-Version nicht mehr kann?
Bei Win7 und Win8 braucht man nämlich ein paar Updates und zusätzlich noch Registry-Einträge, die im Standard fehlen:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ Schannel \ Protocols
Fügen Sie folgende neue Schlüssel hinzu, sofern nicht bereits vorhanden:
TLS 1.1
TLS 1.2
Fügen Sie zu den Schlüssel TLS 1.1 und TLS 1.2 einen weiteren Schlüssel hinzu, den Sie Client nennen.
Erstellen Sie jetzt zu jedem Client-Schlüssel einen DWORD-Wert mit dem Namen DisabledByDefault, deren Wert 00000000 lautet.
In RFC 8314 wird unter 3.3 "Implicit TLS for SMTP Submission" auf Default Port 465 beschrieben. STARTTLS dürfte bei der Sicherheitsdiskussion de facto wohl eher bald Geschichte werden.
@Patrick
RFC 8314 sieht aber auch nach wie vor Port 587 SMTP STARTTLS als Standard an!
Port 465 SMTP TLS ist dort nur als (veraltete Ausweichmöglichkeit) angegeben.
https://blog.n4v.eu/rfc8314-verpflichtet-zum-verschlusselten-mail-versand/
Ich lese das genau umgekehrt, was sich auch in dem von dir gelinkten Beitrag und dem dort angegebenen Wikipedia-Eintrag mit Bezug zum RFC 8314 nachlesen lässt. Die Einleitung von RFC 8314 (Stand 2018!) stellt STARTTLS auf das Abstellgleis.
Also bei meinem Win7 fehlen die beiden Registry-Einträge für "TLS 1.1" und "TLS 1.2" unterhalb von
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ Schannel \ Protocols
Bei mir steht dort nur "SSL 2.0".
Die muss man also nachtragen und jeweils noch die Unterschlüssel "Client" erzeugen und jeweils im "Client" noch den DWRORD32 Wert "DisabledByDefault"=0
Anschließend ausloggen und neu einloggen oder neustarten, damit die Registry-Werte benutzt werden.
Sofern dann auch die notwendigen Updates installiert waren, dann sollte Win7 jetzt TLS 1.1 und TLS 1.2 können.
Falls das email-Programm die Windows-Funktionen benutzt statt eigene Funktionen, dann könnte TLS über Port 587 jetzt funktionieren.
Fehlen die Updates oder die Registry-Einträge, dann kann das Emailprogramm auch keine TLS-Funktionen von Windows benutzen, Port 587 funktioniert dann also nicht und mann muss auf Port 465, also SSL, ausweichen.
die reg Einträge braucht man NUR wenn man vom OS default abweicht.
Fehlen die Einträge greift der default Wert.
Bei einem gepatchtem W7 stollte das SSL2/3 off und TLS 1.0/1.1/1.2 an sein.
https://www.serverprofis.de/faq/content/2/105/de/wie-aktiviere-ich-tls-v11_12-auf-aelteren-betriebssystemen.html
Die Einträge müssen hinzugefügt werden, per default läuft da nichts. Gilt sogar beim 2012 R2.
Du verwechselst hier aktive Protokolle mit der optinalen Änderung des Windows Standard Protokolls.
Ich musste in der Registry nichts ändern und mit Windows Live Mail auf einem Windows 7 (aktueller Update-Stand) funktioniert bei GMX sowohl Port 587 als auch Port 465. Bisher hatte ich Port 587 genutzt und jetzt auf Port 465 umgestellt. Beim T-Online Account war schon Port 465 eingestellt und bei Microsoft-Accounts (Hotmail) funktioniert nur der Port 587, wie Günter bereits erwähnt hat.
Über Port 587 kann eine Verschlüsselung explizit angefordert werden über 465 wird von Anfang an implizit verschlüsselt. Mit der SSL Version hat das nichts zu tun.
In RFC8314 wird übrigens empfohlen Port 465 zu verwenden:
https://datatracker.ietf.org/doc/html/rfc8314
Ich habe jetzt doch mal in den Registry-Schlüssel "Protocols" geschaut und da gibt es, wie Du schreibst, tatsächlich nur SSL 2.0.
Im Unterschlüssel "Client" steht aber „DisabledByDefault"=1.
Windows Live Mail hat dennoch keine Probleme. Ich vermute, es nutzt die Einstellungen des IE und in dessen Einstellungen habe ich ausschließlich TLS 1.2 aktiviert. SSL 2.0, 3.0, TLS 1.0 und 1.1 habe ich schon lange deaktiviert.
Für Thunderbird sieht das vermutlich anders aus, da dieser sicherlich nicht Teile des IE nutzen wird.
Aber ich habe teilweise Probleme mit Ketarin. Da könnte ich vielleicht mal mit den zusätzlichen Einträgen experimentieren.
Das Problem mit Ketarin und einer bestimmten Seite ("Could not create SSL/TLS secure channel") konnte ich auch mit diesen Registryeinträgen nicht lösen.
"SchUseStrongCrypto" unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NetFramework\v4.0.30319
und
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NetFramework\v4.0.30319
habe ich schon lange angelegt, aber das half leider schon nicht.
Ich finde es gut, daß hier auf die RFC 8314 verwiesen wird. Vergeßt aber bitte auch nicht die Aktualisierung RFC 8997!
Und ob ein Port veraltet ist, oder nicht, entscheidet kein komischer KINSTA-BLOG, sondern die iana.