Diskussion:STARTTLS

Spezifische Schwächen

Ich war mal so frei und habe den Absatz

Ein weiterer Nachteil ist, dass über Ausfiltern/Überschreiben des STARTTLS-Befehls
z. B. auf Firewalls die Verbindung unverschlüsselt bleibt, was für den Nutzer meist
unbemerkt geschieht. Dies ist bei explizit verschlüsselten Protokollen wie SMTPS
(tcp/465), IMAPS (tcp/993) und POP3S (tcp/995) nicht möglich.

aus dem Artikel genommen.

Ich sehe nicht dass dies zutrifft. Zumindest gilt es nicht generell für das Verfahren. Gibt der Benutzer an, eine SSL-/TLS-gesicherte Verbindung aufbauen zu wollen, ist es ein leichtes für den Client, das Fehlen der STARTTLS-Möglichkeit zu bemerken und dem Benutzer mitzuteilen. --jailbird 11:51, 13. Jun. 2007 (CEST)

Ich habe gerade folgenden Absatz von 80.66.20.18 entfernt:

Ein weitere Schwäche beruht darauf, dass der Befehl STARTTLS unverschlüsselt übertragen wird. Es ist daher denkbar, dsas Filtersysteme sowohl das Angebot von STARTTLS nach einem EHLO als auch die Anforderung durch den Client verändern, so dass beide Systeme glauben, dass keine TLS-Verschlüsselung möglich sei und dann eine abhörbare unverschlüsselte Verbindung aufbauen. Beim Einsatz von STARTTLS als Sicherheitsfunktion muss daher sichergestellt werden, dass kein Fallback ohne Verschlüsselung erfolgt. Selbst dann muss sichergestellt werden, dass die verwendeten Zertifikat auch zur Gegenstelle passen.

Begründung: Das ist ist keine spezifische Schwäche von STARTTLS, sondern gilt bei jeder Art der Verschlüsselung. Auch bei SMTP über SSL kann ein Man in the Middle den Verbindungsaufbau manipulieren und dem Client vortäuschen, dass der Server keine verschlüsselte Verbindung unterstützt. --Fomafix 17:43, 7. Jul. 2008 (CEST)

"Ein essentieller Vorteil bei STARTTLS ist die Tatsache, dass die Peers die Fähigkeiten aushandeln können; wird auf einem dedizierten SSL-Port eine Klartextverbindung aufgebaut, kommt es zwangsläufig zum Abbruch, in umgekehrter Kombination ebenso." Ähem - worin bitte besteht denn der "essentielle" Vorteil? Der SSL-handshake findet doch in jedem Fall statt. 93.219.169.243 17:30, 10. Jan. 2010 (CET)

So gewandt kann man aneinander vorbei reden. Während TLS (oder SSL) zwingend verschlüsselt ist, besteht bei STARTTLS durch das Aushandeln die Möglichkeit zu einer unverschlüsselten Verbindung. Ich habe es nicht getestet, aber die Möglichkeit liegt nahe, dass Email-Programme dies nicht anzeigen oder abfragen. Durch das Zulassen unverschlüsselter Verbindungen sind Man-in-the-Middle-Attacken einfach. -- 178.115.129.148 17:33, 20. Nov. 2014 (CET)

Artikel benötigt Überarbeitung

Eine Überarbeitung ist dringend nötig und wäre sinnvoll, weil (i) die Nutzung von STARTES in versch. Protokollen unvollständig ist, (ii) der Artikel im Aufbau verschiedenen Applikationen folgt, dies m.E. didaktisch nicht sinnvoll und vom Protokoll Layering genau vermieden werden soll, und (iii) die Risiken bzw. der erzielte Schutz im Vergleich zu der Nutzung separater Ports nicht aufgeführt werden. Ppso (Diskussion) 09:54, 6. Jan. 2014 (CET)

Abweichende Bezeichnungen in Programmen

Einige Programme, wie Outlook oder TINE 2.0 verwenden abweichende Bezeichnungen. STARTTLS wird zu TLS, 'SSL (/ TLS)' wird zu SSL. Dies soll vermutlich eine Vereinfachung für den Benutzer darstellen, verwirrt allerdings, wenn man sich über die richtigen Bezeichnungen informiert. Versucht man etwa eine vermeintliche TLS verbindung über Port 993 zu initiieren, dann scheitert dies, weil das Programm versucht eine STARTTLS-Verbindung herzustellen, welche Port 25 voraussetzt. -- 178.115.129.148 17:44, 20. Nov. 2014 (CET)

CheckTLS.com

Unter den Weblinks fand sich bis eben (eingetragen am 17. Dezember 2013‎ von P.oppenia):

• SMTP TLS Tests and Tools US (um selbst genutzte E-Mail-Provider auf TLS-Verschlüsselung zu testen)

Der Dienst wird offensichtlich von einer amerikanischen Firma angeboten und der zugehörige Server steht in den USA. Um die Tests nutzen zu können, muss man zumindest eine vollständige E-Mail-Adresse eingeben (Domain alleine scheint nicht zu reichen) bzw. eine E-Mail von seinem Account an checktls.com schicken. Insbesondere der TestReceiver Full fordert unverhohlen (und anscheinend ohne eine entsprechende Warnung bzw. Aufklärung) zur Eingabe umfassender Login-Daten (u. a. E-mail Address, E-mail MX Host, E-mail Port, AUTH Type, AUTH User, AUTH Pass) auf. Außerdem dienen diese anscheinend kostenlosen Individual-Angebote offensichtlich in erster Linie dazu, auf die kostenpflichtigen Professional- und Corporate-Angebote aufmerksam zu machen. Ich habe den Eintrag daher aus der Liste der Weblinks entfernt. --DufterKunde (Diskussion) 19:09, 7. Dez. 2015 (CET)

Warum wurden die separaten TLS-only-Ports abgeschafft?

…bzw. als "veraltet" gebrandmarkt? Ich finde STARTTLS einen "netten Hack" aber würde dedizierte Protokolle, die stets verschlüsselt sind, bevorzugen. Ich denke, das sollte im Artikel erläutert werden. --RokerHRO (Diskussion) 18:46, 25. Jan. 2017 (CET)

RFC 2817: "At the Washington DC IETF meeting in December 1997, the Applications Area Directors and the IESG reaffirmed that the practice of issuing parallel "secure" port numbers should be deprecated." --Matthäus Wander 19:12, 12. Jan. 2020 (CET)

Weitere Gründe in RFC 2595 Sec. 7. Eine Neubewertung findet in RFC 8314 Appendix A statt. --Matthäus Wander 18:09, 13. Jan. 2020 (CET)

Hier stimme ich voll zu. Die Separaten Ports wurden nicht abgeschafft. Nur Port 465, der nie offiziell von der IANA fuer SSL SMTP registriert wurde, wurde nun für einen anderen Dienst registriert und sollte dafuer nicht mehr verwendet werden. Soweit ich das lese besteht die Kritik im RFC 2595 nur in falsch konfigurierten Servern und schlechter Implementation von seiten einiger Clients Programme. Dies sind fuer mich vorgeschobene Argumente wobei das größte ist, das es nur eine begrenze Anzahl Port Nummern gibt. Da sollte man eher ersteinmal Uralt Protokollen die keiner mehr nutzt die Port Registrierungen entziehen oder Port 16 freigeben der "for furture use" registriert ist. Alles im allem finde ich den Port Absatz in dem RFC nicht stichhaltig. Und verunsicht nur die Wiki Leser. (nicht signierter Beitrag von 46.244.194.88 (Diskussion) 22:22, 9. Jul. 2017‎)

Im Januar 2018 gab es dazu den RFC 8314, dieser negiert die die Aussagen von RFC 2595 bezüglich der Portnutzung und fordert in Abschnitt 3.3 auf aus Konsistenzgründen auf zu implizietem smtps zu wechseln. Demzufolge wurde auch der Port 456 von der IANA doppelt vergeben die Diskussion ist ebenfalls in dem RFC 8314 dargestellt. Ich werde dementsprechend den ersten Satz des letzten Absatzes entfernen und den Absatz entsprechend anpassen. (nicht signierter Beitrag von Wesx1 (Diskussion | Beiträge) 22:21, 18. Jan. 2019‎)

Sicherheit von STARTTLS

„STARTTLS kann jedoch nicht verhindern, dass eine Client-Software, die STARTTLS nicht kennt, die Login-Daten im Klartext sendet (siehe Kapitel 9 von RFC 2595). Bei der Verwendung der dedizierten Ports für TLS ist dies ausgeschlossen.“

Die Argumentation finde ich etwas schräg. Wenn ein Client STARTTLS nicht kennt, kann STARTTLS nicht verhindern, dass die Login-Daten im Klartext gesendet werden. Soweit logisch. Aber: wenn der Client TLS nicht kennt, kann TLS ebensowenig verhindern (dedizierter Port hin oder her), dass die Login-Daten im Klartext gesendet werden. Darum geht es in RFC 2592 Kap. 9 jedoch gar nicht. Es geht darum, dass STARTTLS gegenüber Downgrade-Angriffen (Stripping Attack) anfällig ist, TLS auf dediziertem Port jedoch nicht. --Matthäus Wander 10:06, 13. Jan. 2020 (CET)

Aussage entfernt. --Matthäus Wander 10:38, 14. Jan. 2020 (CET)

„Ein weiterer Nachteil gegenüber SSL rührt von der Tatsache her, dass die meisten E-Mail-Programme in der Standardeinstellung 'TLS wenn möglich' verwenden und es für den Nutzer nicht sichtbar ist, wenn die Verbindung zum Mailserver nicht (mehr) verschlüsselt ist.“

Die Aussage ist veraltet. Thunderbird hatte früher die Option "TLS, wenn möglich" zusätzlich zu "TLS" (siehe Screenshot Seite 7). Selbst wenn das heute noch einen MUA betreffen sollte (sicherlich nicht mehr "die meisten"), dann sehe ich das nicht als Nachteil von STARTTLS, sondern von dem MUA. --Matthäus Wander 23:37, 13. Jan. 2020 (CET)

Aussage umformuliert. --Matthäus Wander 10:38, 14. Jan. 2020 (CET)

Caching bei E-Mail

„Ähnliches trifft auf Proxys zu, die zwar auf Applikationsebene arbeiten, aber über die Portunterscheidung sehr viel leichter und schneller darüber entscheiden können, ob ein Caching ausgeführt werden soll.“

Caching wovon? --Matthäus Wander 23:09, 13. Jan. 2020 (CET)

Wofür braucht man einen auf Applikationsebene agierenden Proxy bei SMTP, IMAP und POP? Gibts sowas überhaupt? --Matthäus Wander 23:12, 13. Jan. 2020 (CET)

Aussage entfernt. --Matthäus Wander 10:39, 14. Jan. 2020 (CET)

Sicherheit: SSL/TLS ist sicherer?

Sollte man das in der Einleitung erwähnen? Quelle: https://www.privacy-handbuch.de/handbuch_31c.htm ‣Andreas•⚖ 21:09, 7. Mär. 2020 (CET)

Pauschal finde ich die Aussage "SSL/TLS ist sicherer als STARTTLS" nicht korrekt, da es nicht grundsätzlich zutrifft. Richtig wäre: "SSL/TLS kann unter Umständen sicherer als STARTTLS sein". --Matthäus Wander 17:21, 8. Mär. 2020 (CET)

In der angegebenen Quelle steht aber schon, dass das ein Design-Fehler von STARTTLS ist, da das Ausverhandeln ungesichert passiert und anfällig für Man-in-the-Middle-Attacken ist. Von daher trifft es eigentlich immer zu, dass TLS (meist angeführt als "SSL/TLS") sicherer ist als STARTTLS, da bei TLS auch der Verbindungsaufbau zum Server bereits verschlüsselt und gesichert von statten geht. ‣Andreas•⚖ 22:47, 8. Mär. 2020 (CET)

Ich finde diese Aussagen ("Design-Fehler" oder "trifft immer zu") in der Quelle nicht wieder. Dort steht "... können dabei unter Umständen ...", "... könnten ..." und "Einige E-Mail Clients ...". --Matthäus Wander 14:42, 7. Apr. 2020 (CEST)

Okay, dann eben so: Wenn mein E-Mail-Client – und nur darum geht es hier, denn bei einem Webmail trifft weder STARTTLS noch SSL/TLS zu, da nur die https-Verbindung zum Webmail verschlüsselt sein muss (oder als http-Verbindung eben ungesichert) – ... wenn also mein E-Mail-Client eine Verbindung zum Server aufbaut, macht dieser diese immer unverschlüsselt bei STARTTLS. Wenn man also Man-in-the-Middle-Attacken versteht, weiß man auch, dass man an genau dieser Stelle – dem ersten Verbindungsaufbau eben – immer verwundbar ist.

Zitat aus besagter Quelle: „Wenn STARTTLS genutzt wird, beginnt die Kommunikation erst einmal unverschlüsselt. Der E-Mail Client wartet ab, ob der Mailserver in den Capabilities mit 250-STARTTLS eine Transportverschlüsselung anbietet. Erst dann erfolgt ein Aufbau der verschlüsselten Verbindung und der Client beginnt nochmal von vorn.“

Abgesehen davon, dass selbt ohne eine Attacke dabei – je nach Client – Daten geleakt werden können, die eine Identifizierung möglich machen, ergibt sich daraus ein viel schwerwiegenderer Fehler, wenn jemand diesen unverschlüsselten Datenaustausch mit dem E-Mail-Server filtert (Man-in-the-Middle) und damit z.B. angibt, eine der beiden Seiten könne keine Verschlüsselung (also genau das, wofür STARTTLS ja eigentlich entworfen wurde):

„Bewusst oder unbewusst könnten Provider als man-in-the-middle die verschlüsselte Übertragung deaktivieren. Es wird einfach die Meldung 250-STARTTLS gefiltert und überschrieben. Scheinbar verfügen alle DSL-Provider über die Möglichkeit, dieses Feature bei Bedarf für einzelne Nutzer zu aktivieren. Einige E-Mail Clients verwenden standardmäßig die Option "STARTTLS wenn möglich". Diese Einstellung ist genau in dem Moment wirkungslos, wenn man es braucht, weil der Traffic beschnüffelt wird.“

Mit anderen Worten: STARTTLS ist nur dann sicher, wenn sowohl beim Client als auch beim Server alles so konfiguriert ist, dass es ohnehin nur TLS akzeptiert, mit dem Nachteil, dass es dann Design-bedingt am Anfang immer einen unverschüsselten Verbindungsaufbau gibt. Dieser ist jedoch immer anfällig, weil er unverschlüsselt ist. Patzt hier abermals entweder Client oder Server (vermutlich meißt der Client), dann schickt dieser eventuell Daten nach draußen, die Rückschlüsse über den Nutzer ermöglichen, wie in der Quelle angegeben eben z.B. die intern genutzte IPv4-Addresse, mit der man die Nutzer indirekt identifizieren kann.

Bei TLS fällt diese Schwachstelle weg. Und zwar auch Design-bedingt. Immer.

Fassen wir zusammen: STARTTLS kann sicher sein, wenn alles passt und keiner Fehler macht. Das ist im Design von STARTTLS so vorgegeben (Verhandlung zwischen Client und Server ist immer unverschlüsselt). SSL/TLS ist immer sicher, weil jedwede Verbindung verschlüsselt erfolgt. (Sicher in diesem Kontext heißt: so sicher, wie die Verschlüsselung.)

‣Andreas•⚖ 16:42, 7. Apr. 2020 (CEST)

Ich habe das jetzt so in die Einleitung geschrieben, es erschien mir eine sehr wichtige Information. Es steht genau so ohnehin bereits im Text, nur viel weniger klar formuliert und weiter unten. Im Sinne von WP:OMA ;-) ‣Andreas•⚖ 12:23, 14. Mai 2020 (CEST)

HTTPS Resource Record

Ich finde es gut, dass der HTTPS Resource Record jetzt auch in der Wikipedia erläutert wird, denke jedoch, dass der Artikel STARTTLS dafür nicht der richtige Ort ist. Das in RFC 9460 beschriebene Verfahren verwendet kein STARTTLS. Es gibt eine konzeptionelle Verwandtschaft von DANE und MTA-STS zum HTTPS RR, da alle drei Verfahren das DNS verwenden, um zu signalisieren, dass eine TLS-verschlüsselte Verbindung verwendet werden muss. Ich plädiere dafür, einen neuen Artikel HTTPS Resource Record anzulegen und den Abschnitt STARTTLS#Resource_Record_HTTPS dort einzuarbeiten. --Matthäus Wander 21:12, 5. Apr. 2024 (CEST)

Genau so war es gedacht. Ähnlich wie bei DANE sollte dann die Vorlage Hauptartikel zum Einsatz kommen und hier nur ein Hinweis. Ich habe den Einleitungssatz ergänzt. Du kannst gerne dazu einen neuen Artikel HTTPS Resource Record anlegen und danach hier kürzen wie bei DANE. --ocrho (Diskussion) 22:45, 5. Apr. 2024 (CEST)

Einen Verweis über die Vorlage Hauptartikel finde ich nicht angebracht, weil es zwischen dem HTTPS Resource Record und STARTTLS keinen thematischen Zusammenhang gibt. Ich könnte mir vorstellen, hinter dem Satz "Üblicherweise wird hier aber implizites HTTPS nach RFC 2818 verwendet." eine kurze Erwähnung des HTTPS RR zu ergänzen (max 1 Satz). --Matthäus Wander 11:26, 6. Apr. 2024 (CEST)

In Ordnung. Nach einer Nacht darüber schlafen ist ein „historisches Verfahren“ anderes zu bewerten als ein aktuelles Verfahren bei der prominenter auf geeignetere sichere Alternativen/Nachfolger hingewiesen werden sollte. Für mich war der Satz aus der c't rückblickend erhellend, wo das eigentliche Problem lag und die Alternativen so selten unlogisch konstruiert waren, weil Mailserver und Website in der Praxis zwei unterschiedliche Infrastrukturen sind, die aber einen gemeinsamen DNS-Eintrag nutzen und dennoch so weit wie möglich getrennt administrierbar sein sollten. Das kommt aus den bestehenden Artikel STARTTLS nicht deutlich genug hervor und sollte an anderer Stelle genannt werden. Ich klink mich jetzt der weiteren Diskussion aus und überlass Dir und den anderen Autoren die Umgestaltung von STARTTLS und Neuanlage HTTPS Resource Record. --ocrho (Diskussion) 12:37, 6. Apr. 2024 (CEST)

Erledigt: HTTPS Resource Record. --Matthäus Wander 20:11, 20. Apr. 2024 (CEST)