[Eisfair] Fetchmail Meldung, die zweite

[Marcus Roeckrath]

Hallo,

Marcus Roeckrath wrote:

> Ich bleibe - bis mich ein echter Fachmann überzeugt - dabei, dass die
> Falschkonfiguration auf Seiten von 1und1 liegt.

Ich habe gerade folgende Antwort auf die Antwort des Supports verfasst:

[Zitat]
Sehr geehrter Herr Wolf,

Am Donnerstag, 15. Mai 2014 11:02 schrieb support at hosting.1und1.de:

> Beide Zertifikate für pop.1und1.de sind gültig, bei fehlerhafter
> Konfiguration der abrufenden E-Mail-Systeme kann es aber sein dass die
> Zerifizierungs-Kette nicht korrekt nachvollzogen werden kann.

Die Zertifikatsketten für beide Zertifikate sind vollständig.

> In der Regel fehlt das entsprechende Root-CA auf dem Server / im
> entsprechenden E-Mail-Client. Alle aktuell gehaltenen Systeme sollten
> mit beiden Zertifikaten keinerlei Probleme haben.

s. o.

Ein Kunde hat von Ihnen auf eine ähnliche Fehlermeldung die Antwort
bekommen, dass es falsch sei, wenn das Mailempfangsprogramm (hier ein
Linux-Mailserver mit fetchmail) mit dem Fingerprint des Mailservers
arbeitet und nicht auf das Root-Zertifikat prüft.

Das kann definitiv so nicht richtig sein.

1. Fetchmail erfordert zwingend die Konfiguration des Fingerprint
desjenigen Zertifikats, das von der Gegenstelle im Handshake übermittelt
wird; das war immer schon Standard auf einem Linux-Mailserver.

2. Wenn fetchmail nur prüfen würde, ob das im Handshake übermittelte
Zertifikat eine gültige Zertifikatskette hat, könnte nicht sichergestellt
werden, ob überhaupt eine Verbindung zu einem bestimmten Server
hergestellt wurde (Man-in-the-Middle-Attacke).

3. Eine Prüfung auf eine gültige Zertifikatskette sagt nichts über die
Gültigkeit des eigentlichen Serverzertifikats aus; auch wenn ein
Serverzertifikat abgelaufen ist, bleibt die Kette gültig.

4. Punkt 3 würde somit auch bedeuten, dass kompromittierte Zertifikate
weiterhin Gültigkeit behalten und somit als zulässig erkannt würden.

5. Ich halte es für eine Fehlkonfiguration, wenn ein Mailserver sich mit
verschiedenen Zertifikaten ausweist.

6. Ein manipulierter MX-Record könnte in einer solchen Konfiguration dazu
führen, dass Mailverkehr über einen (siehe 2.) fremden Server umgeleitet
werden kann und vom eigenen Mailserver akzeptiert würde, solange dessen
Falschzertifikat von einem gültigen Root-Zertifikat signiert ist.

Mit freundlichen Grüßen

Marcus Röckrath
[/Zitat]

-- 
Gruss Marcus