Störungsfreier Umgang mit Zertifikat (SSL/TLS) bei The Bat, anderen Clients

    MODEDIT: abgeteilt von securepop.t-online.de (TLS-Handshakefehler)

    Schon wieder einer, der mehr Behinderung als Sicherheit fürs Geld bekam.
    Aber wenn's jetz' geht.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

    Einmal editiert, zuletzt von GwenDragon (15. Januar 2014 um 10:11) aus folgendem Grund: abgeteilt

    "Sicherheitsfeatures" einer/s Firewall/Virenscanner/Sicherheitssoftware, die den Betrieb stören, bei der Behebung eher Fachwissen erfordern, sind sinnlos für Normalanwender.

    Zitat von Laufenfeuer

    Wieso meinst Du eigenlich, dass dieses Verhalten eine Schwäche des Virenscanners sei?

    Welches Verhalten? Zertifikate zu fälschen, SSL-Verbindungen für Dritte zu entsclüsseln?
    Wenn das gemeint ist: Ja, es ist ein Sicherheitsbruch.

    Wenn andere Mail-Clients sich nicht an verpfuschten TLS-Verbindungen und Zertifikaten stören, macht mir das eher Sorgen als dass es beruhigt.
    Aber ob jemand wirklich einen abhörsicheren Transport von Logins und Mailinhalten braucht, bleibt jedem überlassen. Mein Sicherheitskonzept ist nicht so locker, dass ich Virenscanner SSL-Verbindungen fälschen/aufknacken lasse.

    Ich will diese Diskussion auch nicht auswalzen. Wir können die gern in einem eigenen Thread weiter führen, wenn gewünscht.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

    Zitat von Laufenfeuer

    @Gwen Dragon

    Wieso meinst Du eigenlich, dass dieses Verhalten eine Schwäche des Virenscanners sei?
    Andere E-Mail-Clients scheinen ja die Sorge nicht zu haben, oder täusche ich mich da?

    Da gibt es zwei wohl mögliche Überlegungen zu:

    A: The Bat! kann Zertifikate / TLS nicht richtig beherrschen

    oder

    B: Andere Mailprogramme beachten die Regularien für die Zertifikateprüfung nicht.

    Meiner Meinung nach soll ein Mailprogramm Mails empfangen und versenden.
    Für die Sicherheit habe ich andere Programme.

    The Bat! beherrscht TLS und ordnungsgemäß erstellte Zertifikate. Dass manchmal Root-Zertifikate hinzugefügt werden müssen, weil The Bat! nicht jede Root-CA kennt, gibt es auch bei anderen Programmen.

    Und das ist schon ziemlich lange so (auch schon in der 5er), dass The Bat! nicht jede Verbindung zulässt, weil das Root-CA-Zertifikat unbekannt ist.

    Zitat

    Andere E-Mail-Clients scheinen ja die Sorge nicht zu haben, oder täusche ich mich da?

    Das von Laufenfuer habe ich bislang nicht deuten können, was unter Sorge bei anderen Clients verstanden wird.
    Was Windows anbelangt, da kann es passieren, dass einfach Zertifikate im Hintergrund nachgeladen werden, was dazu führen kann, dass ein gefälschtes oder kompromittiertes Root-Zertifikat von woanders geladen wird.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

    Einmal editiert, zuletzt von GwenDragon (15. Januar 2014 um 11:26)

    Ich bin nicht sicher, ob es hierher paßt, wenn nicht, bitte verschieben.

    Ich möchte nur berichten, daß im Falle der SSL-Verbindung zu Servern der AOL-Spähre bei TB/Voyager 6.2.2.10 folgender Fehler auftrat:

    Ein TLS-Handshake-Fehler mit Meldung eines unbekannten Zertifikats, allerdings ohne die Möglichkeit, dieses zum Adressbuch hinzuzufügen.

    Im Log fand ich dann, um welches Zertifikat es sich handelte

    Zitat

    31.01.2014, 22:36:05: FETCH - Einleitung TLS-Handshake
    >31.01.2014, 22:36:05: FETCH - Zertifikat S/N: 037FFB4AD201448E1B7CFFC536A37C8F, Algorithmus: RSA (2048 Bits), ausgestellt von 16.08.2013 17:58:13 bis 16.08.2015 17:58:13, für 34 Host(s): imap.aol.com, imap.aim.com, imap.cs.com, client.imap.aol.com, imap.au.aol.com, imap.ar.aol.com, imap.br.aol.com, imap.ca.aol.com, imap.cl.aol.com, imap.de.aol.com, imap.fr.aol.com, imap.in.aol.com, imap.jp.aol.com, imap.mx.aol.com, imap.uk.aol.com, pop.aol.com, pop.aim.com, pop.mcom.com, imap.mcom.com, pop.goowy.com, imap.goowy.com, imap.tunome.com, pop.tunome.com, imap.mda.aol.com, east.us.imap.aol.com, east.us.pop.aol.com, alf.imap.aol.com, imap.angeliamail.com, pop.angeliamail.com, imap.csi.com, pop.csi.com, nginx.aol.com, imap.about.me, pop.about.me.
    >31.01.2014, 22:36:05: FETCH - Besitzer: "US", "Virginia", "Dulles", "AOL Inc.", "AOL Mail", "imap.aol.com".
    >31.01.2014, 22:36:05: FETCH - Aussteller: "US", "Virginia", "Dulles", "America Online Inc.", "AOL Member CA".
    >31.01.2014, 22:36:05: FETCH - Aussteller: "US", "America Online Inc.", "America Online Root Certification Authority 1".
    !31.01.2014, 22:36:05: FETCH - TLS-Handshakefehler. Ungültiges Serverzertifikat (Der Aussteller dieser Zertifikatskette wurde nicht gefunden)

    Im Netz fand ich dann auf dieser Seite das angegebene Zertifikat (ich hoffe jedenfalls, daß es das richtige ist). Nach manuellem Hinzufügen im Adressbuch kam keine Fehlermeldung mehr.

    War das richtig, oder habe ich damit Sicherheit ausgehebelt?

    Danke.

    Zitat von windhorse

    War das richtig, oder habe ich damit Sicherheit ausgehebelt?

    Trusted Root CA im TB!-Adressbuch ist dafür da, um auch neue Wurzelzertifikate hinzuzufügen (in v6.2.12 behoben, mehr hier). Grundsätzlich muss dabei auch das Zertifikat des Ausstellers enthalten sein. Ein paar sind bereits enthalten, von AOL hingegen nicht. Wer es braucht, muss es nachträglich selbst hinzufügen. Solange es sich um echte und gültige Zertifikate handelt, kann keine Sicherheit ausgehebelt werden.