6
Was passiert wenn TLS nicht funktioniert?
Hallo zusammen,
ich nutze Android 5.0 und das vorinstallierte Mailprogramm.
Die Ausgangsmailserver habe ich z.B. die von GMX und googlemail auf TLS und Port 587 gelegt, wie von GMX beschrieben.
TLS müsste ja in diesem Zusammenhang STARTTLS sein, ist meines wissens bei vielen Mailclients ein wenig verwirrent angegeben.
Meine Frage lautet jetzt, was ist wenn GMX Störungen hat, versucht dann der Mailclient die Daten unverschlüsselt an den Mailprovider zu übertragen oder wird die Verbindung sofort beendet?
Es gab ja bei vielen alten Mailclients die Funktion, dass wenn TLS nicht funktioniert unverschlüsselt übertragen wird, durch Port 587 ja auch unverschlüsselte Verbindungen möglich sind.
Grüße Sebasitan.
ich nutze Android 5.0 und das vorinstallierte Mailprogramm.
Die Ausgangsmailserver habe ich z.B. die von GMX und googlemail auf TLS und Port 587 gelegt, wie von GMX beschrieben.
TLS müsste ja in diesem Zusammenhang STARTTLS sein, ist meines wissens bei vielen Mailclients ein wenig verwirrent angegeben.
Meine Frage lautet jetzt, was ist wenn GMX Störungen hat, versucht dann der Mailclient die Daten unverschlüsselt an den Mailprovider zu übertragen oder wird die Verbindung sofort beendet?
Es gab ja bei vielen alten Mailclients die Funktion, dass wenn TLS nicht funktioniert unverschlüsselt übertragen wird, durch Port 587 ja auch unverschlüsselte Verbindungen möglich sind.
Grüße Sebasitan.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 272282
Url: https://administrator.de/contentid/272282
Printed on: April 20, 2024 at 01:04 o'clock
6 Comments
Latest comment
Hey, kenne das Protokoll nicht im Detail, aber ich nehme mal an dass der Provider vordiktiert was möglich ist und was nicht. Der Provider kann ja für seine Server festlegen welche Verschlüsslungsmethoden erlaubt werden und welche nicht
Moin,
kommt drauf an ob der Provider Oportunistic- oder Required TLS auf dem Port aktiviert hat.
Eine gute Beschreibung findest du hier:
Exchange 2007: TLS aktivieren
Gruß jodel32
kommt drauf an ob der Provider Oportunistic- oder Required TLS auf dem Port aktiviert hat.
Eine gute Beschreibung findest du hier:
Exchange 2007: TLS aktivieren
Gruß jodel32
Wieder was dazu gelernt 
Da es keine Option im Mailprogramm selbst gibt required tls auszuwählen sondern nur die Option SSL oder TLS.
Und die folgenden Mailprovider eh nur verschlüsselte Übertragungen erlauben, gehe ich davon aus das TLS auf Port 587 seien Dienst tun wird.
Denn die Provider werden mit sicherheit Required TLS, da unverschlüsselt nicht gesendet werden kann, hab ich ausprobiert.
Ging mir nur darum, ob der Android Mail Client von Lollipop bei fehlerhafter Verbindung dennoch das PW in Klarschrift versucht zu senden, obwohl es nicht geht.
Sollte ja dann nicht der Fall sein, dass OS mit dem Mailclient sind ja auch aktuell.
Grüße Sebastian.
Da es keine Option im Mailprogramm selbst gibt required tls auszuwählen sondern nur die Option SSL oder TLS.
Und die folgenden Mailprovider eh nur verschlüsselte Übertragungen erlauben, gehe ich davon aus das TLS auf Port 587 seien Dienst tun wird.
Denn die Provider werden mit sicherheit Required TLS, da unverschlüsselt nicht gesendet werden kann, hab ich ausprobiert.
Ging mir nur darum, ob der Android Mail Client von Lollipop bei fehlerhafter Verbindung dennoch das PW in Klarschrift versucht zu senden, obwohl es nicht geht.
Sollte ja dann nicht der Fall sein, dass OS mit dem Mailclient sind ja auch aktuell.
Grüße Sebastian.
Port 587 ist der sogenannte Submission-Port. Da wird TLS ("STARTTLS") empfohlen, aber nicht vorgeschrieben.
Port 465 hingegen ist SMTP-S, hier wird durchgängige Verschlüsselung impliziert (also erfordert).
Beide Ports erfüllen die selbe Funktion, beim einen ist Verschlüsselung mittels STARTTLS einfach draufgesetzt, beim anderen wird von vornherein durchgängig mit Schlüsselaustausch u.s.w. verschlüsselt.
Bei Port 587 erfolgt die Datenübertragung erstmal unverschlüsselt im Klartext, der Server bietet aber dem Client eine optionale Verschlüsselung an:
Da taucht dieses konspirative "STARTTLS" auf.
Ein Angreifer, der in der Leitung hockt, könnte aber diese STARTTLS-Zeile einfach aus der Verbindung rauswerfen. Die Verbindung erfolgt hier noch im Klartext, also ist das problemlos möglich.
Wenn der Server oder der Client jetzt nicht auf STARTTLS insistieren, wird die Verbindung weiterhin unverschlüsselt bleiben - denn der Client ist ja der Meinung, dass der Server kein STARTTLS kann. GMX in diesem Beispiel lässt den Login auch ohne vorheriges STARTTLS zu!
Dass da tatsächlich ein Angreifer in deiner Leitung hockt und STARTTLS wegfiltert passiert doch nie, sagst du?
http://www.heise.de/security/meldung/Eingriff-in-E-Mail-Verschluesselun ...
Bei Port 465 wird eine Verschlüsselung impliziert. Das heißt, dass erstmal eine TLS-Gesicherte Verbindung aufgebaut wird, bevor überhaupt irgendein Befehl an den Server gesendet wird. Wenn hier keine Verschlüsselung zustande kommt, kommt halt generell garkeine Verbindung zustande - denn der verwendete Port verlangt nach Verschlüsselung und Klartext geht da einfach nicht.
Das gilt für die Ports 993 (IMAP-S) und 995 (POP3-S) übrigens ebenfalls. Man *kann* auf dem normalen IMAP-Port mit STARTTLS anfangen zu verschlüsseln, aber wenn man direkt Port 993 benutzt kann man sich halt wirklich darauf verlassen, dass in jedem Fall verschlüsselt wird.
Aus diesem Grunde mag ich eigentlich diesen Mischmasch mit STARTTLS nur so mittelmäßig und nutze an sich immer die "echten" TLS-Ports
Port 465 hingegen ist SMTP-S, hier wird durchgängige Verschlüsselung impliziert (also erfordert).
Beide Ports erfüllen die selbe Funktion, beim einen ist Verschlüsselung mittels STARTTLS einfach draufgesetzt, beim anderen wird von vornherein durchgängig mit Schlüsselaustausch u.s.w. verschlüsselt.
Bei Port 587 erfolgt die Datenübertragung erstmal unverschlüsselt im Klartext, der Server bietet aber dem Client eine optionale Verschlüsselung an:
250-gmx.com Hello CLIENT [x.x.x.x]
250-SIZE 69920427
250-AUTH LOGIN PLAIN
250 STARTTLSEin Angreifer, der in der Leitung hockt, könnte aber diese STARTTLS-Zeile einfach aus der Verbindung rauswerfen. Die Verbindung erfolgt hier noch im Klartext, also ist das problemlos möglich.
Wenn der Server oder der Client jetzt nicht auf STARTTLS insistieren, wird die Verbindung weiterhin unverschlüsselt bleiben - denn der Client ist ja der Meinung, dass der Server kein STARTTLS kann. GMX in diesem Beispiel lässt den Login auch ohne vorheriges STARTTLS zu!
Dass da tatsächlich ein Angreifer in deiner Leitung hockt und STARTTLS wegfiltert passiert doch nie, sagst du?
http://www.heise.de/security/meldung/Eingriff-in-E-Mail-Verschluesselun ...
Bei Port 465 wird eine Verschlüsselung impliziert. Das heißt, dass erstmal eine TLS-Gesicherte Verbindung aufgebaut wird, bevor überhaupt irgendein Befehl an den Server gesendet wird. Wenn hier keine Verschlüsselung zustande kommt, kommt halt generell garkeine Verbindung zustande - denn der verwendete Port verlangt nach Verschlüsselung und Klartext geht da einfach nicht.
Das gilt für die Ports 993 (IMAP-S) und 995 (POP3-S) übrigens ebenfalls. Man *kann* auf dem normalen IMAP-Port mit STARTTLS anfangen zu verschlüsseln, aber wenn man direkt Port 993 benutzt kann man sich halt wirklich darauf verlassen, dass in jedem Fall verschlüsselt wird.
Aus diesem Grunde mag ich eigentlich diesen Mischmasch mit STARTTLS nur so mittelmäßig und nutze an sich immer die "echten" TLS-Ports
1
Hallo und danke für die Antwort
Wenn du allerdings wie bei Android die Auswahl "TLS" nutzt, wird doch beim scheitern der STARTTLS Verbindung der Kontakt zum Server beendet oder nicht?
Ist man bei dieser Problematik nicht nur betroffen wenn man "TLS wenn möglich" oder sowas in der Art auswählt?
Grüße und Danke Sebastian.
Wenn du allerdings wie bei Android die Auswahl "TLS" nutzt, wird doch beim scheitern der STARTTLS Verbindung der Kontakt zum Server beendet oder nicht?
Ist man bei dieser Problematik nicht nur betroffen wenn man "TLS wenn möglich" oder sowas in der Art auswählt?
Grüße und Danke Sebastian.
Das kommt halt ganz darauf an, wie der Client sich eine sichere Verbindung mit STARTTLS so vorstellt. Da gibt es keine so richtig verbindliche Konvention wie das benannt werden soll...
Wenn du ganz sicher gehen willst, nimmst du die TLS-Ports der jeweiligen Protokolle - dann kann der Client nicht anders, als zu verschlüsseln.
Wenn du ganz sicher gehen willst, nimmst du die TLS-Ports der jeweiligen Protokolle - dann kann der Client nicht anders, als zu verschlüsseln.
1
