smtp.1und1.de:587 vertrauenswuerdig?

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

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

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

Moin Peter,

Zitat von "Peter_Lehmann"

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

Zitat von "tomte"

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" 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.