[Eisfair] Fetchmail Meldung, die zweite

[Marcus Roeckrath]

Hallo,

Marcus Roeckrath wrote:

> Vielleicht sollte man mal der ct-Leserhotline (telefonisch zwischen 13 und
> 14 Uhr erreichbar) das Problem schildern.

Folgende Mail ist gerade an die c't rausgegangen:

[Zitat]
Hallo,

seit etwa Anfang Mai gibt es Problememit dem ssl-Pop-Mailabruf von den
Servern

pop.1und1.de und pop.kundenserver.de (beide im Hause 1und1)

mit fetchmail (Linux).

Fetchmail ist auf verschlüsselten Mailabruf mittels ssl konfiguriert und
der md5-Fingerprint des Serverzertifikats in der Fetchmail-Konfiguration
hinterlegt.

Die Mailserveraddressen pop.1und1.de und pop.kundenserver.de werden im
Hause 1und1 auf weitere interne (virtuelle?) Mailserver weitergeleitet.

Jedoch übermitteln die 1und1-Mailserver zwei verschiedene Zertifikate beim
Pop-SSL-Handshake, was dann zu Fingerprint-Mismatches von Fetchmail führt,
abhängig davon auf welchen internen 1und1-Mailserver man geführt wird.

Die beiden verschiedenen Zertifikate lassen sich u. a. dadurch
identifizieren, dass eines von der Telekom das andere von Thawte signiert
ist.

Zumindest der 1und1-Mailserver, der sich im Handshake als mieue101 zu
erkennen gibt, übermittelt das Thawte signierte Zertifikat, die weiteren
(mieueXXX) das Telekom signierte Zertifikat.

Inzwischen hat 1und1 nach mehreren Mails an support at hosting.1und1.de u. a.
folgende Erklärung geliefert:

[Zitat]
Beide Zertifikate für pop.1und1.de sind gültig, es macht aber den Anschein
als hätten Sie den Fingerprint eines Zertifikates fest in Ihrer
Konfiguration eingegeben. Eine Verifizierung der Zertifikate sollte aber
mit Hilfe der Root-Zertifikate erfolgen und nicht anhand eines speziellen
Fingerprints festgemacht werden.
[/Zitat]

Ich halte die Konfiguration der 1und1-Mailserver für falsch und habe
folgende Argumentation an 1und1 gerichtet:

[Zitat]
Ein Kunde hat von Ihnen auf eine ähnliche Fehlermeldung [Anmerkung: es
handelt sich um die obige Erklärung des 1und1-Supports] 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.
[/Zitat]

Können Sie entscheiden, welcher Standpunkt der richtige ist?

Wie kommt man aus diesem Dilemma raus?

Mit freundlichen Grüßen

Marcus Röckrath
[/Zitat]

-- 
Gruss Marcus