smtp.1und1.de:587 vertrauenswuerdig?

  • Thunderbird-Version: 24.4.0
    Betriebssystem + Version: Windows 7 Ultimate 64
    Kontenart (POP / IMAP): POP
    Postfachanbieter (z.B. GMX): 1&1
    S/MIME oder PGP:


    Hallo, eigentlich wollte ich diesen Hilferuf an 1&1 schicken, aber wenn das Senden doch nicht mehr funktioniert ...


    Am 11.04.2014 abends um 19:21 bekam ich von meinem E-Mail- und Server-Hosting-Provider 1&1 per E-Mail die Aufforderung, wegen des Heartbleed-Bugs das OpenSSL in meinem 1&1-Server zu aktualisieren. Die ein- und ausgehenden E-Mails werden allerdings nicht von meinem Server, sondern von 1&1 verwaltet. Mein Server ist also vermutlich nicht ursaechlich fuer das Weitere (?):


    E-Mails zu empfangen funktioniert weiterhin.


    Am Mo. 14.04.2014 war ich den ganzen Tag unterwegs, aber seit heute Di. 15.04. frueh um 00:04 Uhr kann ich keine E-Mails mehr versenden, sondern bekomme zwei Dialoge:


    1. Dialog:
    Fenster "Sicherheits-Ausnahmeregel hinzufuegen"
    Hiermit uebergehen Sie die Identifikation dieser Website durch Thunderbird.
    Seriöse Banken, Geschäfte und andere öffentliche Seiten werden Sie nicht bitten, derartiges zu tun.
    Server Adresse: smtp.1und1.de:587
    Button: "Zertifikat herunterladen": (Nicht gedrueckt)


    Zertifikat-Status:
    Diese Website versucht sich mit ungueltigen Informationen zu identifizieren.
    Unbekannte Identität
    Dem Zertifikat wird nicht vertraut, weil es nicht von einer bekannten Authorität unter Verwendung einer sicheren Signatur verifiziert wurde.


    "Ansehen"-Button > Zertifikatshierarchie:
    - Deutsche Telekom Root CA 2
    - - TeleSec ServerPass DE-1
    - - - smtp.1und1.de



    und nach "Abbrechen" der 2. Dialog:
    Senden der Nachricht fehlgeschlagen. Die Nachricht konnte aus unbekannten Gründen nicht über den SMTP-Server smtp.1und1.de gesendet werden.



    Ist das Zertifikat smtp.1und1.de:587 vertrauenswuerdig?


    In einem anderen Forums-Tread hab eich gelesen, dass Thunderbird nun standardmaessig SSL verlangt - und alle moeglichen Tipps werden gegeben, wie man die SSL-Default-Einstellung umgehen kann ... . Wir schimpfen alle auf NSA & Co. - warum also eigentlich SSL umgehen?


    Meine Bitte an 1&1 waere gewesen: "Koennten Sie zu diesem Problem bitte eine offizielle Stellungnahme und eine Anleitung veroeffentlichen?"


    Wie ist Thunderbirds Reaktion bezueglich Sicherheit einzuschaetzen?
    Was konkret sollte ich tun? Das Zertifikat smtp.1und1.de:587 als vertrauenswuerdig akzeptieren,
    bzw. als "dauerhaft vertrauenswuerdig" akzeptieren?


    Danke im Voraus
    tomte

  • Hallo tomte,


    und willkommen im Forum!

    Zitat

    bekam ich von meinem E-Mail- und Server-Hosting-Provider 1&1 per E-Mail die Aufforderung, wegen des Heartbleed-Bugs das OpenSSL in meinem 1&1-Server zu aktualisieren.


    Dazu eine Frage meinerseits:
    Hast du wirklich bei 1&1 einen eigenen root-Server gemietet, für dessen Administration du selbst voll verantwortlich bist? => Dann müsstest du als Administrator eigentlich auch wissen, wie man einen derartigen root-Server administriert ... .


    Bitte schicke uns mal den vollständigen Text der betreffenden E-Mail und beschreibe mal ganz genau, was du bei 1&1 für einen Vertrag hast.


    Nebenbei: 1&1 hat auch eine kostenfreie Rufnummer, mit welcher deren Service erreichbar ist.



    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!

  • "Peter_Lehmann" schrieb:

    Hast du wirklich bei 1&1 einen eigenen root-Server gemietet? ...
    Bitte schicke uns mal den vollständigen Text der betreffenden E-Mail und beschreibe mal ganz genau, was du bei 1&1 für einen Vertrag hast.


    Hallo Peter,


    danke fuer die schnelle Antwort!


    Ja, eigener root-Server: "1&1 Server 2012 L 2 Core"
    CentOS 6 with Plesk Panel 10 (64bit)
    Den den Server betreffenden E-Mail-Wortlaut siehe unten.
    Diesen Kontext hatte ich der Vollstaendigkeit erwaehnt, der Server wird eh in den naechsten Tagen frisch aufgesetzt. Und E-Mails werden wie gesagt nicht von meinem Server gemanaged.



    Soweit die Server-betreffende E-Mail.


    Mein vordringliches Problem ist, dass ich mit meinem Thunderbird-Client wieder E-Mails senden koennen muss und nur ein vertrauenswuerdiges Zertifikat speichern moechte. Zu dieser Frage waere ich sehr dankbar fuer Tipps,
    danke,
    tomte

    3 Mal editiert, zuletzt von Peter_Lehmann () aus folgendem Grund: Code-Tags gesetzt / Quote-Tag ergänzt

  • So, jetzt weiß ich mehr.


    Als Verantwortlicher für einen root-Server kennst du ja sicherlich die Geschichte mit dem bislang größten Vorkommnis in der Geschichte der modernen Kryptologie. Und dein Provider weist dich auch noch einmal deutlich darauf hin und stellt dir eine klare Aufgabe.
    Denke mal, dazu muss ich nichts mehr sagen.



    Etwas völlig anderes ist es technisch gesehen mit deinem eigenen Thunderbird und seiner Kommunikation mit den Mailservern deines/r Provider/s.


    Hier haben die meisten dt. Provider nun endlich die bislang auch unverschlüsselt nutzbaren Verbindungen zu ihren Mailservern auf zwangsweise Verschlüsselung umgestellt. Genutzt werden konnte diese Verschlüsselung schon "seit ewig" - nur kaum einer hat sich die "Mühe" gegeben, diese Einstellung vorzunehmen. ("Wir haben ja nichts zu verbergen ...".) Jetzt müssen wir es (endlich!).
    Du als Nutzer hast außer der Veränderung der Verbindungssicherheit von "keine" auf "SSL/TLS" bzw. "STARTTLS" und bei ganz wenigen Providern auch noch des Servernamens (hier ist mir nur t-online.de bekannt) nichts zu tun. Der zur Verschlüsselung genutzte Schlüssel befindet sich auf dem Server! Dein Client muss ihn nur akzeptieren, was normalerweise völlig unbemerkt vom Nutzer vonstatten geht. Noch mal: es wird jetzt immer verschlüsselt (bei den Providern, die das jetzt zwangsweise eingestellt haben) und es gibt da absolut nix zu umgehen!


    Zwei Probleme können dabei auftreten:
    1.) Wenn du einen AV-Scanner hast, und dieser die Verbindung zu den Mailservern überwachen (scannen) soll. Genau so, wie ein Angreifer die Verbindung nicht belauschen kann, kann das der AV-Scanner auch nicht => er sperrt dann sinnvollerweise die Verbindung, bevor er dem Nutzer eine Sicherheit vorgaukelt, die es ja gar nicht mehr gibt. Was zum Lesen: >> klick <<
    Dort steht auch das Problem beschrieben, wenn der AV-Scanner in der üblen Art eines "Man-in-the-Middle" die Verbindung aufbricht, was zu Problemen wie deinem führt.


    2.) Wenn sich ein User den Luxus einer eigenen "Maildomäne" leistet. Also zum Bsp. "Max@Muster.de" und von seinem Provider als Mailserver "imap.muster.de" oder "smtp.muster.de" genannt bekommt.
    In diesem Fall stimmen die in den bei den Zertifikaten des Providers eingetragenen Daten (hier: der cn) natürlich niemals mit den bei dir eingetragenen Servernamen überein. Logischerweise erkennt das der Thunderbird und bemängelt das. Hervorragend! Aufgepasst! WOWEREIT! So muss das sein!
    In diesem Fall kannst du probieren, den (in Wirklichkeit niemals existierenden, weil nur virtuellen) eingetragenen Servernamen in den tatsächlichen Servernamen des Providers (also meinetwegen "imap.1und1.de") umzubenennen. Damit stimmt der Servername mit dem cn überein, und wenn das Empfangen und Senden funktioniert, ist auch alles in Ordnung.


    HTH


    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 Peter,
    vielen Dank fuer Deine Tipps!


    Pragmatisch habe ich das am leichtesten zu Testende zuerst getestet: Kaspersky, den "man in the middle", kurzzeitig beendet => Keine Aenderung.


    Dann STARTTLS geprueft: War fuer ausgehende E-Mails schon gesetzt, ok, dadurch also keine Aenderung (fuer eingehende bei der Gelegenheit auch gleich gesetzt).


    "Peter_Lehmann" schrieb:

    Der zur Verschlüsselung genutzte Schlüssel befindet sich auf dem Server! Dein Client muss ihn nur akzeptieren, was normalerweise völlig unbemerkt vom Nutzer vonstatten geht.


    Tatsaechlich, unbemerktes Akzeptieren von Zertifikaten hatte ich Thunderbird verboten, ich denke also, da liegt der Hund begraben.


    Die obigen drei Meldungen


    Diese Website versucht sich mit ungueltigen Informationen zu identifizieren.
    Unbekannte Identität
    Dem Zertifikat wird nicht vertraut, weil es nicht von einer bekannten Authorität unter Verwendung einer sicheren Signatur verifiziert wurde.


    haben mich allerdings bislang davon abgehalten, das zu tun, was die Standardeinstellung, wie Du schreibst, automatisch getan haette.


    Damit ist aber noch nicht mein Misstrauen gegenueber der Automatik beseitigt, und ich komme zurueck zur Frage: Woran erkenne ich, dass ich dem vorgeschlagenen bzw. server-seitig vorgefundenen Zertifikat vertrauen kann? (sogar gegen die eingebaute Warnung!)? Da stimmt doch etwas nicht im Prozedere. Noch habe ich es nicht getan ...


    Ich fuehle mich knapp vor dem befreienden Klick ...
    Danke im Voraus!
    tomte

  • Hallo tomte,


    was bedeutet denn dieses von dir (und allen anderen Nutzern) erwartete "Vertrauen"?
    Es geht doch "nur" darum, dass der Mailclient sicher feststellt, dass er mit dem richtigen Mailserver, also dem deines Providers verbinden ist. Kommt keine Fehlermeldung, dann ist das so - kommt eine, dann stimmt was nicht und der Prüfalgorithmus weist dich darauf hin. Es geht also um nichts anderes als einen "Man in the Middle" zu erkennen.(Jahrelang wurde durch die Masse der Nutzer SSL/TLS überhaupt nicht genutzt, und kein Schw*** hat sich dafür interessiert ... .)


    Dazu müssen die aktuellen und gültigen Zertifikate des vollständigen Zertifikatsbaumes in deinem Client vorhanden sein.
    - das "Deutsche Telekom Root CA 2"
    - das "TeleSec ServerPass DE-1" und
    - das Zertifikat des jeweiligen Servers.


    Jetzt kann es sein, dass du zwar noch gültige, aber bereits ausgetauschte Zertifikate im Speicher hast. Es kann auch einfach sein, dass die Uhr deines Rechners nicht genau geht (der häufigste Fehler!).


    Auf dieser Seite : https://de.ssl-tools.net/mailservers/smtp.1und1.de kannst du die gültigen Zertifikate herunterladen, aber auch evtl. vorhandene in deinem Client anhand der Prüfsummen überprüfen. Sollten diese nicht aktuell sein (aus gewissen Gründen wurden ja in den letzten Tagen Tausende Zertifikate ausgewechselt!), dann kannst du die veralteten Z. einfach löschen (sie sind ja von der Ablaufzeit immer noch gültig, werden nur nicht mehr genutzt). Spätestens dann holt sich der Client die aktuellen vom Server.
    Selbstverständlich kannst du dir die aktuellen Z. auch selber laden und installieren.
    Ganz paranoide (wie ich) überprüfen die Hashwerte sogar noch auf der Webseite des jeweilichen TrustCenters. Zumindest die root-Zertifikate.


    OK?


    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!

  • Moin Peter,


    "Peter_Lehmann" schrieb:

    Ganz paranoide (wie ich) überprüfen die Hashwerte sogar noch auf der Webseite des jeweilichen TrustCenters. Zumindest die root-Zertifikate.


    Was sicher so verkehrt ja auch wieder nicht ist?! Ich habe gerade ein neues Zertifikat für einen FTP-Zugang bekommen, weil dieses vom Hoster erneuert wurde. Herausgeber ist GlobalSign. Nun wollte ich dieses auch beim Herausgeber überprüfen ... muss aber gestehen das ich nicht fündig geworden bin bzw. diese Möglichkeit zu versteckt ist? Oder ich einfach nur Blind bin?


    Hast du zufällig ein Beispiel wo man sehen kann wie man die Hashwerte eines Zertifikats überprüfen kann?


    MfG Siggi

  • Du musst auf die Webseite des TrustCenters gehen. Jedes seriöse TC hat irgendwo auf seiner Seite seine eigenen Herausgeberzertifikate zum Download angeboten. Und es steht auch immer der Hashwert und/oder die Zertifikatsseriennummer dabei. Diese beiden Daten vergleichst du mit dem bei dir gespeicherten Herausgeberzertifikat. Wenn dieses übereinstimmt, kannst du diesen Herausgeber als vertrauenswürdig ausgehen. Mehr ist nicht drin.
    Und bei deinem eigenen Zertifikat (von diesem Herausgeber) kannst du durch Ansicht der Zertifikatsdaten (draufklicken ...) den Herausgeber und den Hashwert und/oder die Zertifikatsnummer des Herausgeberzertifikates finden. Und dieses muss dann wieder mit den oben gesehenen Daten übereinstimmen. Damit gilt als bestätigt, dass der Herausgeber dein Zertifikat mit seinem geheimen Schlüssel signiert hat, also dieses von ihm stammt.


    Suchen musst du allerdings selber ... .


    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!

  • "tomte" schrieb:

    In einem anderen Forums-Tread hab eich gelesen, dass Thunderbird nun standardmaessig SSL verlangt - und alle moeglichen Tipps werden gegeben, wie man die SSL-Default-Einstellung umgehen kann ... . Wir schimpfen alle auf NSA & Co. - warum also eigentlich SSL umgehen?


    Mir fehlt hier der Kontext. Oder, fehlte ;)


    Erstmal hattre cih ohne server nur als Gratiskunde anfänglich auch Probleme mit Ausgang (SMTP) auf 465. Mußte 587 nutzen. Nach deren "Komplettumstellung" :D Seit einiger Zeit geht aber auch 465. POP über 995 ging gleich. Hab mich nur gewundert, daß bei einer Testmail an mich 110/587 immer 1-2min. dauerten, mit 995/465 dauert es 5s-15s bis die Mail wieder hier ist.


    Das hat hier aber mit dem Thema weniger zu tun. Was es damit aber zu tun hat: Was hat TLS mit einer Sicherheit gegen NSA&Co. zu tun? Das bringt da nichts.