Mitternachtshacking

So langsam wird das ja mein Lieblingsthema hier im Blog: IT-Sicherheit und Vertrauen. Wem vertrauen wir und warum? Lässt sich das überhaupt rational begründen? Manches kommt mir schon seltsam vor. Trust Center beispielsweise führen im Namen schon die Bezeichnung „Trust“. Gerade so, als wäre es zwingend notwendig darauf hinzuweisen, dass man diesen Centern doch bitte auch vertrauen soll. Ein normaler, vernünftiger Mensch würde das nämlich nicht tun.

Der aktuelle Anlass um mal wieder über Trust Center zu polemisieren ist die Art und Weise, wie manche Zertifizierungsstellen die Identität eines Antragsstellers überprüfen. Dazu muss man wissen, dass sich in der Praxis vier (genauer 4,5) Klassen der Identitätsprüfung herausgebildet haben:

• Class 0: keine Überprüfung des Antragsstellers. Hier wird ein Zertifikat ausgestellt, ohne den Antragsteller überhaupt zu prüfen. In der Praxis wird das nur für Testzertifikate gemacht, die sich nicht gegen eine bekannte CA verifizieren lassen.
• Class 1: Überprüfung der E-Mail Adresse. Das ist praktisch für E-Mail-Zertifikate. Man schickt einen Antrag an die Zertifizierungsstelle und die schickt das Zertifikat an die angegebene E-Mail Adresse zurück. Wenn man das empfangen kann ist es offensichtlich korrekt. Eine weitere Überprüfung ist nicht notwendig. Das ist sehr günstig und effizient aber halt nur eingeschränkt sicher.
• Class 2: Überprüfung der Organisation anhand von irgendwelchen Unterlagen. Hier wird geprüft, ob es z.B. die Organisation des Antragstellers tatsächlich gibt, ob die Domain eines Webservers tatsächlich dem Antragsteller gehört, usw. Allerdings nur auf Basis öffentlich zugänglicher Dokumente. Beispielsweise kann ich für mitternachtshacking.de ein Zertifikat beantragen mit dem Namen der in DeNIC als Eigentümer der Domain registriert ist aber nicht auf einen anderen Namen.
• Class 3: Überprüfung der Organisation mit Kontaktaufnahme. Hier wird in der Regel die Organisation geprüft und zum Antragsteller direkt Kontakt aufgenommen. Die meisten deutschen Zertifizierungsstellen machen das beispielsweise durch PostIdent. Bei den amerikanischen Beutelschneidern weiß ich das gar nicht. Meistens gibt es da ein Fallback auf Class 2.
• Die letzte halbe Klasse ist dann das „Extended Verification“ von Verisign. Ich denke das kommt auch dadurch, dass es in den USA kein PostIdent oder vergleichbar gibt und für Class 3 dann eigentlich nur eine etwas erweiterte Class 2 Prüfung stattfindet. Mit dem „Extended Verification“ wird dann halt ein wenig mehr geprüft. Wenn überhaupt.

Soweit ist das ja ok. Allerdings setzt bereits eine Class 2 Verification einen gewissen Aufwand voraus. Unter Umständen kann man das nicht komplett automatisieren sondern muss manuell prüfen, ob die ganzen Daten übereinstimmen. TC Trustcenter hat sich bei mir da mal verdient gemacht (das ist jetzt ausnahmsweise nicht ironisch), weil sie es abgelehnt haben ein Zertifikat auszustellen in dem die Daten nicht 100% mit den Unterlagen übereingestimmt haben. (Ursache war, dass wir am umziehen waren und ich das Zertifikat schon mal auf die neue Anschrift ausgestellt haben wollte).

Der eine oder andere Zertifizierungsstellenbetreiber ist deshalb auf folgenden Trick gekommen, den Aufwand zu minimieren:

Man definiert ein paar sogenannter „System-E-Mail-Adressen“, die per Definition (par ordre de mufti) in jedem Mailsystem vorhanden sein müssen und die dann vertrauenswürdig sind, weil die nur vom Betreiber des Mailsystems und damit vom Eigentümer der Domain genutzt werden können.

Das ist eine mutige Annahme. Darunter befinden sich nämlich auch so Adressen wie:

• administrator@domain.org
• admin@domain.org
• info@domain.org
• hostmaster@domain.org
• root@domain.org
• ssladmin@domain.org
• sysadmin@domain.org
• webmaster@domain.org
• info@domain.org
• postmaster@domain.org

und teilweise noch abwegigere wie

• ssladministrator@domain.org
• it@domain.org
• dnsadmin@domain.org

In irgendwelchen nie gelesenen RFCs sind tatsächlich alle diese E-Mail Adressen für besondere Zwecke mal reserviert worden. Die meisten Mailsysteme und praktisch alle Administratoren wissen aber nichts davon. Und wenn dann ein normaler Anwender eine dieser Mailadressen hat, kann er damit beispielsweise SSL-Zertifikate für die Domain beantragen obwohl er dafür gar nicht berechtigt sein sollte.

Aufgeflogen ist das ganze jetzt mal wieder, weil Kurt Seifried beim Freemail-Anbieter Portugalmail die nicht gesperrte E-Mail Adresse ssladministrator@portugalmail.pt registriert hat und damit erfolgreich ein SSL-Zertifikat für die Domain portugalmail.pt bei RapidSSL bekommen hat. Übrigens mal wieder eine 100%ige Tochter von Verisign. Dokumentiert ist das in einem Bugreport bei Mozilla der fordert, RapidSSL aus den vertrauenswürdigen Zertifizierungsstellen zu entfernen sowie in einem Artikel im Linux Magazine.

Passieren wird aber mal wieder nichts, weil sich die Mozilla Foundation nicht mit dem mächtigen Konzern Verisign anlegen will. Und RapidSSL hat ja auch verkünden lassen, Zertifikate nur noch bei einigen wenigen Mailadressen einfach so rauszuschicken. Klingt ganz toll, löst nämlich das darunterliegende Problem nicht: Erschreckend vielen Zertifizierungsstellen ist es offensichtlich einfach viel zu teuer die eigentlich geforderte korrekte Überprüfung des Antragstellers auch durchzuführen. Statt dessen wird da gemauschelt und geschummelt was das Zeug hält. Eigentlich gehört das ganze Sicherheitskonzept von SSL entsorgt und neu entworfen.

Und darum heißen diese Firmen ja auch Trust Center, sonst würde denen schließlich niemand vertrauen.