HOSTBLOGGER.de

Ich sage es nur ungern, aber in diesem Fall scheint nur Microsoft eine aus Sicherheitssicht vernünftige Lösung zu bieten:

Bei dem Modell von Mozilla Thunderbird sind ganz offensichtlich Man-in-the-Middle-Attacks möglich, weil die Auto-Discovery-Datei per HTTP geladen werden kann. Damit kann ein falscher Hostname für den Mail-Server übermittelt und anschließend das Passwort abgefangen werden (ein gültiges SSL-Zertifikat ist kein Problem, weil man schließlich den Hostname frei wählen kann).

In RFC 6186 wird immerhin auf dieses Problem eingegangen und vorgeschlagen, dass der Mail-Client den Benutzer entsprechend benachrichtigen sollte (wenn nicht per DNSSEC sichergestellt ist, dass die DNS-Abfrage unveränderte Daten zurückgeliefert hat). Aus meiner Sicht ist diese Forderung aber zu schwach: Erstens ist es nur ein "soll" kein "muss" und zweitens dürfte eine entsprechende Meldung von unerfahrenen Benutzern (welche schließlich gerade die Zielgruppe für Auto-Discovery sind) einfach wegklickt werden. Um nämlich überprüfen zu können, ob die angegebenen Mailserver richtig sind, muss man diese kennen. In diesem Fall kann man aber die Konfiguration auch gleich manuell vornehmen.

Das von Microsoft verwendete Protokoll macht es hingegen richtig: Die Auto-Discovery-Datei wird ausschließlich über HTTPS mit einem gültigen SSL-Zertifikat durchgeführt. Damit ist die gesamte Sicherheit auch nicht schwächer, als bei einer manuellen Konfiguration, da auf SSL-Ebene der Angriff auch auf die Verbindung mit dem richtigen Mailserver erfolgen kann. Der einzige Nachteil dieses Protokolls ist, dass der Konfigurationsaufwand für ISPs, die ihren Kunden E-Mail-Adressen mit kundenspezifischen Domains anbieten, höher ist, weil für jede Domain ein gültiges SSL-Zertifikat erforderlich ist. Meiner Meinung nach sollte man aber nie Sicherheit aufgeben, nur um die Umsetzung etwas einfacher zu machen.

Die Microsoft-Variante erlaubt aber auch - eben weil nicht für jede Kundendomain ein SSL-Zertifikat vorhanden sein muss - die Umleitung per SRV-Eintrag auf einen beliebigen anderen Hostname. Für diesen muss dann ein Zertifikat vorhanden sein und der Benutzer wird darüber informiert, dass umgeleitet wurde - ich habe die Meldung zwar nicht geprüft, gehe aber davon aus, dass sie genauso aussieht wie alle anderen Microsoft-Meldungen: Unten rechts oder links ein OK-Knöpfchen, ein bisschen Technobabble - fast alle Nutzer klicken drauf und gut.

Wenn ich mir Sorgen mache, dass bei meinen Nutzern bei der Ersteinrichtung des E-Mail-Kontos eine MITM-Attacke stattfinden könnte, dann bekommen die eine genaue Anleitung zur manuellen Einrichtung. Und vorher einen Virenscan auf dem System, oder schon mal gar kein Windows auf den Rechner. Oder so.

Übrigens: MS-Vorschlag zur Auto-discovery: HTTP 405? SRSLY? Und dann Konfigurationsdaten als "Fehlermeldung"? Bäh!

Wo wir gerade dabei sind:
Wieso kann man Emails bei Manitu mit TLS abholen, aber "nur" mit SSL versenden? Oder bin nur ich betroffen. Verhaelt sich bei mir schon immer so mit Evolution, Android Stock Emailclient und HTC Emailclient.

Bei welcher Domain kann ich mir die Konfiguration mal angucken? Würde mich interessieren, wie ihr das im Detail gemacht habt.

Cool, das Blog maskiert automatisch eure IP-Adressen!?

Wer wirklich eine braucht, findet die z.B. auch im PDF, das die Einrichtung eines Webhosting-Accounts erklärt, im Screenshot des Verwaltungs-Web-Services. Da habe ich das her. Die Adresse dort endet auf eine dreistellige Zahl. Die letzten beiden Ziffern dieser Zahl sind offensichtlich zwischen verschiedenen Webhosting-Servern unterschiedlich - und passen jeweils zu dem Hostname, den man im SMTP-Helo zu sehen bekommt.

Es sieht mir aber so aus, als wäre Autokonfiguration zumindest noch nicht für alle Domains aktiv - dazu fehlen noch einige SRV-Einträge im DNS bei mehreren der so ermittelten Domains.

Naja, für hostblogger.de oder shopblogger.de könnte man das ja mal verändern, da weiß eh jeder, dass die bei Manitu sind

Ich persönlich halte das MITM-Szenario durchaus für relevant, aber nicht für das primäre Problem.

Wahrscheinlicher ist, dass eine Workstation direkt infiziert ist. Dann ist es egal, ob falsche Autoconfig-Daten im E-Mail-Client landen, oder auf der Maschine Traffic mitgelauscht wird etc.

Die Wahrscheinlichkeit, dass jemand weiß, wann ich mir Autoconfig-Daten über welches Transport-Netz "besorge", ist gegeben, aber jemand DAS kontrollieren kann, kann er auch gleich komplett den gesamten Traffic mitschnipseln.

Und ja: Dagegen hilft SSL/TLS mitsamt Zertifikaten, aber nur bei nicht-unbedarften Anwendern, denn die klicken eh jedes nicht passende Zertifikat weg. Und Anwender vom Fach brauchen kein Autoconfig.

Wie schon vorher kommentiert, würde dagegen wohl nur DNSSEC in Verbindung mit Erzwingen von Antworten via https (oder ähnlich) helfen.

hat jemand schon eine Lösung, um auch Apple Mail auf Mac OS X automatischen mit den Daten zu versorgen?
Konnte dazu kaum etwas finden im Netz...