Diskussion:STARTTLS

message: 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)
replies: text: 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)

text: 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)
thread_title: Spezifische Schwächen

message: 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)
thread_title:  Artikel benötigt Überarbeitung 

message: 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)
thread_title:  Abweichende Bezeichnungen in Programmen 

message: 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)
thread_title:  CheckTLS.com 

message: …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)
replies: text: 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)

text: 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)
thread_title:  Warum wurden die separaten TLS-only-Ports abgeschafft? 

message: „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)
replies: text: Aussage entfernt. --Matthäus Wander 10:38, 14. Jan. 2020 (CET)

text: 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)
replies: text: Aussage umformuliert. --Matthäus Wander 10:38, 14. Jan. 2020 (CET)
thread_title:  Sicherheit von STARTTLS 

message: „Ä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)
replies: text: 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)
replies: text: Aussage entfernt. --Matthäus Wander 10:39, 14. Jan. 2020 (CET)
thread_title:  Caching bei E-Mail 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: Erledigt: HTTPS Resource Record. --Matthäus Wander 20:11, 20. Apr. 2024 (CEST)
thread_title:  HTTPS Resource Record