{"id":1242,"date":"2010-04-15T18:29:16","date_gmt":"2010-04-15T17:29:16","guid":{"rendered":"http:\/\/www.mitternachtshacking.de\/blog\/1242-who-do-you-trust-teil-1-rapidssl"},"modified":"2018-05-22T18:34:10","modified_gmt":"2018-05-22T17:34:10","slug":"who-do-you-trust-teil-1-rapidssl","status":"publish","type":"post","link":"https:\/\/www.mitternachtshacking.de\/blog\/1242-who-do-you-trust-teil-1-rapidssl","title":{"rendered":"Who do you trust? &#8211; Teil 1: RapidSSL"},"content":{"rendered":"<p>So langsam wird das ja mein Lieblingsthema hier im Blog: IT-Sicherheit und Vertrauen. Wem vertrauen wir und warum? L\u00e4sst sich das \u00fcberhaupt rational begr\u00fcnden? Manches kommt mir schon seltsam vor. Trust Center beispielsweise f\u00fchren im Namen schon die Bezeichnung &#8222;Trust&#8220;. Gerade so, als w\u00e4re es zwingend notwendig darauf hinzuweisen, dass man diesen Centern doch bitte auch vertrauen soll. Ein normaler, vern\u00fcnftiger Mensch w\u00fcrde das n\u00e4mlich nicht tun.<\/p>\n<p>Der aktuelle Anlass um mal wieder \u00fcber Trust Center zu polemisieren ist <a href=\"http:\/\/www.heise.de\/security\/artikel\/SSL-fuer-lau-880221.html\">die Art und Weise, wie manche Zertifizierungsstellen die Identit\u00e4t eines Antragsstellers \u00fcberpr\u00fcfen<\/a>. Dazu muss man wissen, dass sich in der Praxis vier (genauer 4,5) Klassen der Identit\u00e4tspr\u00fcfung herausgebildet haben:<\/p>\n<ul>\n<li>Class 0: keine \u00dcberpr\u00fcfung des Antragsstellers. Hier wird ein Zertifikat ausgestellt, ohne den Antragsteller \u00fcberhaupt zu pr\u00fcfen. In der Praxis wird das nur f\u00fcr Testzertifikate gemacht, die sich nicht gegen eine bekannte CA verifizieren lassen.<\/li>\n<li>Class 1: \u00dcberpr\u00fcfung der E-Mail Adresse. Das ist praktisch f\u00fcr E-Mail-Zertifikate. Man schickt einen Antrag an die Zertifizierungsstelle und die schickt das Zertifikat an die angegebene E-Mail Adresse zur\u00fcck. Wenn man das empfangen kann ist es offensichtlich korrekt. Eine weitere \u00dcberpr\u00fcfung ist nicht notwendig. Das ist sehr g\u00fcnstig und effizient aber halt nur eingeschr\u00e4nkt sicher.<\/li>\n<li>Class 2: \u00dcberpr\u00fcfung der Organisation anhand von irgendwelchen Unterlagen. Hier wird gepr\u00fcft, ob es z.B. die Organisation des Antragstellers tats\u00e4chlich gibt, ob die Domain eines Webservers tats\u00e4chlich dem Antragsteller geh\u00f6rt, usw. Allerdings nur auf Basis \u00f6ffentlich zug\u00e4nglicher Dokumente. Beispielsweise kann ich f\u00fcr mitternachtshacking.de ein Zertifikat beantragen mit dem Namen der in DeNIC als Eigent\u00fcmer der Domain registriert ist aber nicht auf einen anderen Namen.<\/li>\n<li>Class 3: \u00dcberpr\u00fcfung der Organisation mit Kontaktaufnahme. Hier wird in der Regel die Organisation gepr\u00fcft und zum Antragsteller direkt Kontakt aufgenommen. Die meisten deutschen Zertifizierungsstellen machen das beispielsweise durch PostIdent. Bei den amerikanischen Beutelschneidern wei\u00df ich das gar nicht. Meistens gibt es da ein Fallback auf Class 2.<\/li>\n<li>Die letzte halbe Klasse ist dann das &#8222;Extended Verification&#8220; von Verisign. Ich denke das kommt auch dadurch, dass es in den USA kein PostIdent oder vergleichbar gibt und f\u00fcr Class 3 dann eigentlich nur eine etwas erweiterte Class 2 Pr\u00fcfung stattfindet. Mit dem &#8222;Extended Verification&#8220; wird dann halt ein wenig mehr gepr\u00fcft. Wenn \u00fcberhaupt.<\/li>\n<\/ul>\n<p>Soweit ist das ja ok. Allerdings setzt bereits eine Class 2 Verification einen gewissen Aufwand voraus. Unter Umst\u00e4nden kann man das nicht komplett automatisieren sondern muss manuell pr\u00fcfen, ob die ganzen Daten \u00fcbereinstimmen. 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 \u00fcbereingestimmt haben. (Ursache war, dass wir am umziehen waren und ich das Zertifikat schon mal auf die neue Anschrift ausgestellt haben wollte).<\/p>\n<p>Der eine oder andere Zertifizierungsstellenbetreiber ist deshalb auf folgenden Trick gekommen, den Aufwand zu minimieren:<\/p>\n<ul>Man definiert ein paar sogenannter &#8222;System-E-Mail-Adressen&#8220;, die per Definition (<a href=\"http:\/\/de.wikipedia.org\/wiki\/Mufti\">par ordre de mufti<\/a>) in jedem Mailsystem vorhanden sein m\u00fcssen und die dann vertrauensw\u00fcrdig sind, weil die nur vom Betreiber des Mailsystems und damit vom Eigent\u00fcmer der Domain genutzt werden k\u00f6nnen.<\/ul>\n<p>Das ist eine mutige Annahme. Darunter befinden sich n\u00e4mlich auch so Adressen wie:<\/p>\n<ul>\n<li>administrator@domain.org<\/li>\n<li>admin@domain.org<\/li>\n<li>info@domain.org<\/li>\n<li>hostmaster@domain.org<\/li>\n<li>root@domain.org<\/li>\n<li>ssladmin@domain.org<\/li>\n<li>sysadmin@domain.org<\/li>\n<li>webmaster@domain.org<\/li>\n<li>info@domain.org<\/li>\n<li>postmaster@domain.org<\/li>\n<\/ul>\n<p>und teilweise noch abwegigere wie<\/p>\n<ul>\n<li>ssladministrator@domain.org<\/li>\n<li>it@domain.org<\/li>\n<li>dnsadmin@domain.org<\/li>\n<\/ul>\n<p>In irgendwelchen nie gelesenen RFCs sind tats\u00e4chlich alle diese E-Mail Adressen f\u00fcr 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\u00fcr die Domain beantragen obwohl er daf\u00fcr gar nicht berechtigt sein sollte.<\/p>\n<p>Aufgeflogen ist das ganze jetzt mal wieder, weil <a href=\"https:\/\/www.seifried.org\/security\/index.html\">Kurt Seifried<\/a> beim Freemail-Anbieter <a href=\"http:\/\/portugalmail.pt\/\">Portugalmail<\/a> die nicht gesperrte E-Mail Adresse ssladministrator@portugalmail.pt registriert hat und damit erfolgreich ein SSL-Zertifikat f\u00fcr die Domain portugalmail.pt bei RapidSSL bekommen hat. \u00dcbrigens mal wieder eine 100%ige Tochter von Verisign. Dokumentiert ist das in einem <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=556468\">Bugreport bei Mozilla<\/a> der fordert, RapidSSL aus den vertrauensw\u00fcrdigen Zertifizierungsstellen zu entfernen sowie in einem <a href=\"http:\/\/www.linux-magazine.com\/Issues\/2010\/114\/BREACH-OF-TRUST\">Artikel im Linux Magazine<\/a>.<\/p>\n<p>Passieren wird aber mal wieder nichts, weil sich die Mozilla Foundation nicht mit dem m\u00e4chtigen Konzern Verisign anlegen will. Und RapidSSL hat ja auch verk\u00fcnden lassen, Zertifikate nur noch bei einigen wenigen Mailadressen einfach so rauszuschicken. Klingt ganz toll, l\u00f6st n\u00e4mlich das darunterliegende Problem nicht: Erschreckend vielen Zertifizierungsstellen ist es offensichtlich einfach viel zu teuer die eigentlich geforderte korrekte \u00dcberpr\u00fcfung des Antragstellers auch durchzuf\u00fchren. Statt dessen wird da gemauschelt und geschummelt was das Zeug h\u00e4lt. Eigentlich geh\u00f6rt <a href=\"\/blog\/1133-eff-zweifelt-an-ssl\">das ganze Sicherheitskonzept von SSL entsorgt<\/a> und neu entworfen.<\/p>\n<p>Und darum hei\u00dfen diese Firmen ja auch Trust Center, sonst w\u00fcrde denen schlie\u00dflich niemand vertrauen.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>So langsam wird das ja mein Lieblingsthema hier im Blog: IT-Sicherheit und Vertrauen. Wem vertrauen wir und warum? L\u00e4sst sich das \u00fcberhaupt rational begr\u00fcnden? Manches kommt mir schon seltsam vor. Trust Center beispielsweise f\u00fchren im Namen schon die Bezeichnung &#8222;Trust&#8220;. Gerade so, als w\u00e4re es zwingend notwendig darauf hinzuweisen, dass man diesen Centern doch bitte [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[8,10,6],"tags":[],"_links":{"self":[{"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/posts\/1242"}],"collection":[{"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/comments?post=1242"}],"version-history":[{"count":0,"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/posts\/1242\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/media?parent=1242"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/categories?post=1242"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mitternachtshacking.de\/blog\/wp-json\/wp\/v2\/tags?post=1242"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}