STARTTLS - verschlüsselte Verbindung erzwingen [erl.]

Am 24.09.2018, werden in der Zeit zwischen 21:00 Uhr und 09:00 Uhr des folgenden Tages Wartungsarbeiten am Server durchgeführt. Daher wird die Webseite in dieser Zeit nur eingeschränkt erreichbar sein.
  • Thunderbird-Version: 17.0.7
    Betriebssystem + Version: Linux
    Kontenart (POP / IMAP): beide
    Postfachanbieter (z.B. GMX): egal


    Hi Leute,


    das Prinzip von STARTTLS ist ja, dass sich Server und Client erstmal unverschlüsselt verbinden, dann ausloten, was geht und dann, wenn beide das anbieten, auf eine verschlüsselte Verbindung upgraden, bevor die Logindaten gesendet werden.


    Kann ich Thunderbird irgendwie anweisen, dass er, wenn via STARTTLS keine verschlüsselte Verbindung zustandekommt, abbrechen soll? Habe keine Lust, dass er die Logindaten unverschlüsselt schickt. Einstellungen meinetwegen auch direkt in der about:config von TB.


    Danke!

  • Hi,
    soweit ich weiß, ist StartTTLS heutzutage beim TB genau das,was du willst, nämlich verschlüsselt - oder Abbruch. Früher gab es mal "TLS, wenn möglich".
    Gruß, muzel

  • Wunderbar, hat sich das Problem ja viel eleganter gelöst als erhofft. Besten Dank für die Info!

  • Hallo,


    @nuzel:

    "muzel" schrieb:

    soweit ich weiß, ist StartTTLS heutzutage beim TB genau das,was du willst, nämlich verschlüsselt - oder Abbruch

    sicher?
    Laut

    "[url=http://de.wikipedia.org/wiki/STARTTLS schrieb:

    STARTTLS – Wikipedia[/url]"]STARTTLS kann jedoch nicht verhindern, dass eine Client-Software, die STARTTLS nicht kennt (oder einfach schlecht programmiert ist), die Login-Daten im Klartext sendet (siehe Kapitel 9 von RFC 2595).

    ist dem nicht so.

  • Ja, so sehe ich das auch ... .
    Gut, beim Thunderbird wissen wir, dass er STSRTTLS beherrscht. Ich denke aber auch viel eher an den Mailserver als "Störfall".
    So gab es vor einigen Monaten das Problem, dass sich "in Folge eines technischen Fehlers" ;-) bei einem dt. Mobilfunkprovider ein dafür vorgesehener Parameter "zufälligerweise" verstellt hat, und eine mir nicht mehr bekannte Zeit lang die Verbindungen barfuß betrieben wurden, obwohl in den Clients STARTTLS eingestellt war. Das hat wohl erst jemand mitbekommen, der seine eigenen Verbindungen (so wie ich) ab und an mal mit Wireshark anschaut. Dabei fiel ihm der Klartext auf.


    Aber wir können ja davon ausgehen, dass das nicht wieder vorkommen wird.
    Seit dem 1. Juli können sich da die Ermittlungsorgane unser aller Passwörter recht problemlos von den Providern zuschicken lassen. Da benötigt man solche "Pannen" nicht mehr ... .



    MfG Peter

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!

  • Hallo rum, hallo Peter,

    Zitat

    STARTTLS kann jedoch nicht verhindern, dass eine Client-Software, die STARTTLS nicht kennt


    das trifft ja nicht zu

    Zitat


    (oder einfach schlecht programmiert ist)...

    und das hoffentlich auch nicht. Bleibt also noch die erwähnte Möglichkeit, daß der Server plötzlich kein StartTLS mehr will. Da würde ich aber doch ganz stark hoffen, daß TB dieses unmoralische Angebot zurückweist (wie gesagt, früher gab es in den Konteneinstellungen die Auswahl "TLS wenn möglich" als Fallback, das wurde aber abgeschafft. TB ist zum Glück nicht so flexibel, alles mögliche auszuprobieren, was der Server behauptet, zu beherrschen. Auch wenn es letztlich nichts nützt, die ersten Meter zu verschlüsseln, was dann doch offen übers Netz geht.
    Aber ich wäre natürlich stark an so einem Mitschnitt von wireshark o.ä. interessiert, oder wenigstens ein paar Fakten zu den Geschichte, wo ein Server den Client (Thunderbird?!) überredet, die Geheimniskrämerei zu lassen, obwohl der doch StartTLS will ;-). Peter ?


    Grüße, muzel

  • Hi muzel,


    in dem von mir aus dem Gedächtnis hervorgekramten Sachverhalt mit der "Panne" bei dem einen Mobilfunkprovider wurde in der Fachpresse (ich denke da an Heise, weiß es aber nicht mehr genau) das Kommando des Servers genannt, nach welchem trotz vom Client angefordertem STARTTLS nur offen gesendet wurde. Vielleicht findest du per gg diesen Beitrag noch.
    Das Problem bei STARTTLS ist ganz klar der gleiche Port, wie beim offenen Betrieb. Bei klar definiertem SSL/TLS kann etwas derartiges eben nicht passieren. Diese Ports können eben "nur" verschlüsselt betrieben werden und lehnen jeden unverschlüsselten Betrieb ab.


    Ich habe auf die Schnelle nur dieses hier gefunden: StartTLS | heise Security - Heise Online
    Auch wenn du dir in Wikipedia die Beschreibung für STARTTLS ansiehst, fallen dir ein paar "kann" auf:

    Code
    1. Ein essentieller Vorteil hierbei ist die Tatsache, dass die Peers, also die Verbindungspartner, die technischen Fähigkeiten beiderseits aushandeln können.

    => "beiderseits" und "können" ... .

    Code
    1. Dank STARTTLS kann zum Beispiel der Client (ohne Nutzereingriff) wahrnehmen, dass der Server die Erweiterung bietet und automatisch Gebrauch davon machen.

    => "kann wahrnehmen" und "kann ... davon Gebrauch machen" ... .
    Also das, was hier als "Vorteil" beschrieben ist, ist lediglich ein Vorteil für die Provider (vermeidet Serviceanfragen!) und für die technisch unbedarften und uninteressierten Nutzer.


    Jetzt frage mich bitte nicht, was der Unterschied zwischen dem heute üblichen "STARTTLS" und dem früher möglichen "TLS wenn möglich" ist. Ich habe trotz intensiver Suche nirgendwo eine Definition für letzteres gefunden. Könnte es vielleicht sein, dass früher mal STARTTLS fürs Verständnis der Nutzer etwas umschrieben dargestellt wurde? Von der erklärenden Wirkung trifft das nämlich genau zu.


    Zum Sniffen:
    Ja, ich als in dieser Hinsicht sehr misstrauischer Mensch ("Berufsparanoide") schaue mir schon ab und an mal den gewollt verschlüsselten Traffic an, ob er denn wirklich verschlüsselt ist. Oder besser gesagt, ob da nicht etwa Klartext gesendet wird, denn eine echte Verschlüsselung kann man nicht durch bloßes Ansehen erkennen.
    Fakt ist, dass ich immer den üblichen Verbindungsaufbau im Klartext (=> siehe Heise-Artikel) und danach nur "unlesbare" Zeichen sehen konnte. Bei den Fällen, bei denen ich mein Misstrauen ausleben durfte, wurde ich immer "positiv überrascht". Gleichzeitig weiß ich natürlich, dass ich lediglich meine (24 Byte großen kryptischen Zufalls-)Passwörter vor dem Mitlesen durch "Dritte" schütze.
    Nur frage ich mich jetzt, welchen Sinn das noch macht?
    Mein eigenes LAN betrachte ich als sicher. (Im Rahmen dessen, was ein sachkundiger privater Nutzer so machen kann.)
    Die knapp 100m vom Haus bis zum Outdoor-DSLAM kann ich per Sichtkontakt "überwachen".
    Und von dort an sind meine Daten bei meinem Provider. Dem gleichen, der dem neugierigen Staat meine sämtlichen Passwörter auf Nachfrage locker auf dem Silbertablett rüberreicht (seit 01.07.2013 rüberreichen muss.)
    Und die dazu notwendige Ordnungswidrigkeit begehe ich garantiert täglich auf meiner Anfahrt zur Arbeit ... .


    Für mich macht diese Verschlüsselung also nur noch Sinn bei Leuten, welche aus einem (Firmen-, Uni-, usw.) Intranet oder gar per unverschlüsseltem WLAN (Hotspot!) ihre Mails verwalten.


    MfG Peter

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!