Gefälschtes Microsoft Zertifikat blocken

Aus SSLplus
Wechseln zu: Navigation, Suche

Gefälschtes Microsoft Zertifikat im Umlauf

Am 17.03.2015 wurde bekannt, dass es Unbekannten [1] gelungen ist, ein Zertifikat für die Domain live.fi zu fälschen. Die Verifizierung erfolgte laut Microsoft – so heise.de – scheinbar über eine unterhalb live.fi registrierte Email-Adresse. Anwender sollten dieses Zertifikat schnellst möglich blocken.

Blockieren des gefälschten Zertifikates

Um das Zertifikat für die Browser und andere Anwendungen als ungültig zu markieren, muss es auf die Sperrlisten der Betriebssysteme, beziehungsweise Anwendungen gesetzt werden.

Microsoft Internet Explorer und Google Chrome

Das Zertifikat wird bei Nutzern aktueller Windows Versionen durch automatische Updates in die Liste der widerrufenen Zertifikate aufgenommen. Nuter von älteren Versionen (Windows Vista, Windows 7, Windows Server 2008 usw.) sollten dringend das Update KB2917500 einspielen. Bei Versionen die noch nicht mit dem automatischen Update des Zertifikatsspeichers für gültige und widerrufene Zertifikate ausgestattet sind, läßt sich dieser nachrüsten KB2677070.

Firefox und andere

Browser, die wie der Firefox einen eigenen und nicht nicht den Zertifikatsspeicher des Betriebssystems nutzen, müssen über separate Updates gepflegt werden. Die Mechanismen CRL und OCSP arbeiten nicht zuverlässig genug, als dass man sich hier auf eine automatische Aktualisierung des Zertifikatsspeichers verlassen könnte. Details diskutierte Heise anlässlich des Heartbleed Bugs bereits ausführlich [2].

Gründe und Schlussfolgerungen

Das Zertifikat wurde auf Grund eines Fehlers ausgestellt, der nicht primär bei Comodo zu suchen ist. Die Praxis, domainvalidierte Zertifikate auf eine Emailbestätigung hin auszustellen, ist gang und gäbe. Viel mehr sollte man zunächst Microsoft die Frage stellen, warum die generischen Emailadressen, die für die Adresseierung von Hostmaster, Webmaster, Postmaster etc. per RFC vorgegeben sind, nicht für die Freischaltung blockiert wurden, bzw, warum diese nicht schon in Betrieb waren [3].

Da es offensichtlich immer wieder vorkommt, dass ISPs diese Adressen nicht vorbelegen, bleibt zu überlegen, ob SSL Zertifikatsanträge zukünftig nur noch über alternative Mechanismen wie Hashes in DNS Records oder über spezielle Dateien auf dem Webserver hin validiert werden sollen.

Verweise