Mitternachtshacking

Kommunikation mit der Bank wird immer gefährlicher. Weder Internetbanking noch Geldautomaten sind noch ausreichend sicher. Aber egal, das Risiko trägt ja bekanntlich der Kunde.

BSI-zertifizierter Kobil Kartenleser gehackt

Tja, si eine BSI-Zertifizierung ist auch nicht mehr das, was sie nie war. Der Kobil SecOVID Reader III, der vom BSI für den Einsatz nach dem strengen deutschen Signaturgesetz (SigG) zugelassen wurde, kann mit einer fremden nicht signierten Firmware geflasht werden. Und schon hat sich die Sicherheit erledigt. Und sehr schön, das Problem wurde nicht allgemein bekannt gemacht, weil es sich um “eine überschaubare Kundengruppe” handeln soll und die die Anwendungen für Geldkarte, HBCI und Secoder nicht von der Lücke betroffen seien. Stimmt zwar nicht aber klingt besser und beruhigt die Homebanking-Kunden die ja für den Schaden haften, wenn was schiefgeht.

Mehr Geldautomaten werden manipuliert

Das Abheben von Geld am Geldautomat wird dafür auch immer unsicherer. Das BKA warnt mal wieder vor Skimming, d.h. manipulierten Geldautomaten um Kartendaten und PIN abzugreifen. „Als normaler Kunde kann man eine Manipulation im Grunde nicht erkennen“, sagte BKA-Präsident Jörg Ziercke. Und: “Viele Banken würden die Manipulationen nicht melden, weil sie sonst um ihre Reputation fürchteten”. Na toll. Aber laut AGB haftet eh der Kunde.

OCSP rettet uns auch nicht

Und für das gewöhnliche Internet-Banking gibt es auch beruhigende Nachrichten für den bösen Hacker. Das Online Certificate Status Protocol (OCSP), das vom Browser verwendet wird um die Gültigkeit von SSL-Zertifikaten zu verifizieren kann geschickt manipuliert werden. Dazu erklärt man dem Browser über eine OCSP-Statusmeldung einfach, der Server sei überlastet und der Browser solle es später nochmal probieren. Das Standardverhalten der Browser ist dann, das Zertifikat halt solange anzuerkennen.

Mobile Banking bedroht

Und für die Freunde von Mobile Banking oder Mobile TANs  gibt es zum Schluß noch den Hinweis, dass zumindest im Android Market bereits eine Applikation aufgetaucht ist, die Bankzugangsdaten ausspähen sollte. Ich denke wir werden noch viel mehr in diese Richtung erleben.

Ich sollte mir mein Gehalt vielleicht wieder bar auszahlen lassen

Wenn man mit einem frisch installierten Firefox beispielsweise die Webseite des CCC aufruft, bekommt man diesen lustigen Zertifikatsfehler:

Der Grund ist bekanntlich, daß die Zertifizierungsstelle CACert im Browser nicht als vertrauenswürdige CA enthalten ist.

Einige Browserhersteller liefern deshalb auch CA-Aktualisierungen aus. Microsoft beispielsweise stellt immer wieder mal über Microsoft Update eine Aktualisierung der Zertifizierungsstellen (”Update der Stammzertifizierungsstellen”) bereit. Ich kucke meistens dann auch, wer da alles neu drin steht.

Meines Wissens (ich lasse mich aber gerne eines besseren belehren) verlangt Microsoft, um in die Liste der vertrauenswürdigen Zertifizierungsstellen aufgenommen zu werden, die Erfüllung mehrerer Voraussetzungen:

• Eine Vereinbarung mit Microsoft (Microsoft CA Agreement)
• Mind. 2048 Bit Schlüssellänge, mind. SHA-1 Hashalgorithmus, min. 8 Jahre gültig, höchstens bis 2030
• CRL Distribution Point Extension, d.h. eine CRL muß bereitgestellt werden
• Eine dokumentierte Policy (Certificate Practice Statement, CPS)
• Ein erfolgreich bestandenes Audit, typischerweise nach
  • WebTrust for Certificate Authorities v1.0 or later, durch einen lizensierten WebTrust for CAs Auditor
  • ETSI TS 101 456 v1.2.1 or later
  • ETSI TS 102 042 V1.1.1 or later
  • ISO 21188:2006, “Public key infrastructure for financial services — Practices and policy framework”, ebenfalls durch einen lizenzierten Auditor
• Außerdem habe ich mal gehört, daß Microsoft dann noch so ca. 50.000 USD haben möchte, für den ganzen Aufwand

In den Auditregeln stehen insgesamt ganz schön viele  Anforderungen drin. CACert beispielsweise wird von Microsoft nicht aufgenommen, alleine weil die vermutlich die geforderten Kosten für Audit und RootCA-Zertifikatsverteilung nicht bezahlen können. Bei einigen Antragstellern scheint es Microsoft mit den Regeln auch nicht ganz so genau zu nehmen. Beispielsweise muß man das CPS der Cisco Root CA im Internet suchen. Im Zertifikat ist der Link dahin leider nicht enthalten.

Was mir aber langsam Sorgen macht, sind die vielen Regierungs-CAs die als vertrauenswürdige Zertifizierungsstellen im Internet Explorer (und anderen Browsern mit Verzögerung) auftauchen. Hier beispielsweise die Liste cer CAs die mir beim Durchsehen des aktuellen IEs aufgefallen sind:

• CN = AC RAIZ DNIE, OU = DNIE, O = DIRECCION GENERAL DE LA POLICIA, C = ES
• OU = Application CA G2, O = LGPKI, C = JP (Japanese Local Government)
• OU = ApplicationCA, O = Japanese Government, C = JP
• CN = Common Policy, OU = FBCA, O = U.S. Government, C = us
• CN = ComSign, O = ComSign CA, C = IL
• O = Government Root Certification Authority, C = TW
• CN = GPKIRootCA, OU = GPKI, O = Government of Korea, C = KR
• CN = IGC/A, OU = DCSSI, O = PM/SGDN, L = Paris, S = France, C = FR (Secrétariat Général de la Défense Nationale)
• OU = MPHPT Certification Authority, OU = MPHPT, O = Japanese Government, C = JP
• CN = Root CA, OU = GPKI, O = Government of Korea, C = KR
• CN = Root CA Generalitat Valenciana, OU = PKIGVA, O = Generalitat Valenciana, C = ES
• OU = sigov-ca, O = state-institutions, C = si
• CN = Staat der Nederlanden Root CA, O = Staat der Nederlanden, C = NL
• CN = VRK Gov. Root CA, OU = Varmennepalvelut, OU = Certification Authority Services, O = Vaestorekisterikeskus CA, S = Finland, C = FI

Bei Firefox ist das nicht anders. Mozilla (Kathleen Wilson) selbst sagt dazu:

“Mozilla has included many root certificates that are operated either by actual government agencies or by organizations that are government sponsored. We do not have a policy against accepting government sponsored CAs into our program.”

Bei der Aufnahme bzw. dem späteren Rauswurf von CNNIC, einer (möglicherweise staatlich kontrollierten) chinesischen Zertifizierungsstelle gab es bei Mozilla riesige Diskussionen. Die spanische Polizei kann aber inzwischen genauso Man-in-the-Middle Angriffe mit gültigen Zertifikaten auf beliebige SSL-Verbindungen durchführen. Und ich bin sicher, die eine oder andere scheinbar harmlose Organisation im Browser die nicht auf meiner Liste steht, wird von irgendeinem Geheimdienst kontrolliert.

Im Ergebnis habe ich folglich im Browser inzwischen fast 300 RootCA-Zertifikate von rund 100 Zertifizierungsstellen. Welche davon staatlich kontrolliert sind, welche davon tatsächlich vertrauenswürdig sind und welche böse, ist für mich nicht mehr überschaubar. Die Regeln Microsoft, Mozilla und Co. helfen wie oben gesehen leider nicht weiter. Ich denke, ich werde demnächst meine eigene Liste “Mitternachtshacking traut diesen CAs” veröffentlichen und alle anderen aus meinem Browser rauswerfen. Tatsächlich stammen alle SSL-Zertifikate der von mir genutzten verschlüsselten Verbindungen aus den letzten drei Monaten von lediglich 8 Zertifizierungsstellen, sagt Certificate Patrol. Die anderen 92 können folglich raus.

So langsam wird das ja mein Lieblingsthema hier im Blog: IT-Sicherheit und Vertrauen. Wem vertrauen wir und warum? Läßt 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, daß man diesen Centern doch bitte auch vertrauen soll. Ein normaler, vernünftiger Mensch würde das nämlich nicht tun.

Der aktuelle Anlaß um mal wieder über Trust Center zu polemisieren ist die Art und Weise, wie manche Zertifizierungsstellen die Identität eines Antragsstellers überprüfen. Dazu muß man wissen, daß 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, daß 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 muß 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, daß 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 gesperrteE-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.

Genaugenommen nicht am SSL-Protokoll sondern an der durch die Zertifikate garantierte Abhörsicherheit. Die EFF vermutet, daß staatliche (insbesondere amerikanische) Stellen die Anbieter von SSL-Zertifikaten zwingen können, falsche Zertifikate auszustellen.

Soghoian und Stamm beschreiben als möglichen Schutz ein Firefox-Add-on, das Zertifikatsinformationen aller besuchten SSL-Websites speichert.

Das wäre doch mal eine gute Sache. Und Firefox warnt mich immer dann, wenn sich das Zertifikat ändert. Genaugenommen der SHA-1 Fingerprint. Am liebsten auch, wenn das Zertifikat nur verlängert wird. Dann kann ich selbst entscheiden ob und wem ich vertrauen will.

Mal nachdenken. Fefe hat vor einiger Zeit einen Bugreport dafür bei Mozilla eingereicht. Carlo von Loesch verweist dort auf das Browser-Addon Certificate Patrol, das diese Funktion angeblich implementiert. Ich habe das jetzt mal installiert und wenn es was taugt, kommt es zur Liste meiner dauerhaften Addons dazu.

Nachtrag:

Freedom to Tinker hat auch drei interessante Beiträge dazu:

• Mozilla Debates Whether to Trust Chinese CA von Ed Felten
• Web Security Trust Models von Steve Schultze
• Web Certification Fail: Bad Assumptions Lead to Bad Technology by Ed Felten

Und erwähnte ich eigentlich schon, daß ich das zertifikatsbasierte Sicherheitsmodell von SSL als gescheitert ansehe? Und Karthago muß zerstört werden!

Ich lach mich schlapp. Die Beutelschneider von Verisign haben ein neues Geschäftsmodell gefunden. Musste ja kommen, weil Jamba (die mit den Klingeltonabos für kleine Kinder) im Oktober 2008 an Rupert Murdoch verkauft wurde.

Zur Wiederholung, das Geschäftsmodell von Verisign basiert neben der überteuerten Domainverwaltung von .com und .net vor allem darauf, überteuerte Zertifikate für SSL-Server zu verkaufen. Am besten gleich die mit Extended Verification, was bei mir den Eindruck erweckt als würde Verisign bei den anderen SSL-Zertifikaten gar nicht richtig prüfen. (Naja, tun sie ab und zu auch nicht wie die fehlerhaft auf den Namen Microsoft ausgestellten Zertifikate zeigen.) Aber gut, man braucht ja nicht unbedingt ein Zertifikat von Verisign. Es gibt auch günstige seriöse Anbieter.

Verisign hat jetzt aber entdeckt, daß es ja gaaaanz viele Webseiten gibt, die gar kein SSL haben. Und den gaaaanz vielen Webseiten ohne SSL kann man gar kein SSL-Zertifikat verkaufen. Was verkauft man denen dann? Genau, ein Webseiten-Siegel. Sowas wie es der TÜV (die anderen Beutelschneider) auch im Angebot hat. Bei Verisign heißt das “VeriSign Trusted” (nur 299 USD, umgerechnet 220 Euro) und beinhaltet laut Heise die Identitätsprüfung des Seitenbetreibers. Ein SSL-Zertifikat ist nicht enthalten, das ist nämlich dann “VeriSign Secured” und kostet natürlich mehr. Nebenbei ist noch ein Malware-Scanner für die Webseite enthalten. Ich persönlich halte das ja für Quatsch, aber es gibt sicher genug Webseitenbetreiber die drauf reinfallen. Und vielleicht gibt’s das Siegel irgendwann sogar im VeriSign-Sparabo.

Nachtrag:

Ganz sachlich: ein normales VeriSign-SSL-Zertifikat kostet umgerechnet 440 Euro (599 USD) für ein Jahr, ein VeriSign-SSL-Zertifikat mit Extended Validation kostet umgerechnet 1250 Euro (1699 USD) für einen Server außerhalb der USA/Kanada. Ein vergleichbares SSL-Zertifikat z.B. von TC Trustcenter kostet 159 Euro (aktuelle Promo 143 Euro) zzgl. MwSt., von der Deutschen Telekom kostet es 150 Euro zzgl. MwSt. Aber da VeriSign keine Zwangslage ausnutzt darf man nicht von Wucher sprechen.

Wir sind in einer Diskussion auf folgende Überlegung gekommen:

Ich sitze an einem Windows-PC (ohne Desktop-Firewall) in einem geschützten Netz hinter der großen Firmen-Firewall. Surfen im Internet ist erlaubt. Außerdem ist auf dem Rechner hier ein SSL-VPN Client installiert, in meinem Fall Juniper Network Connect der Juniper SSL-VPN SA-Serie. Welches Produkt von welchem Hersteller verwendet wird, ist für die Fragestellung aber egal. Das Network Connect wird normalerweise gestartet, indem man auf die Anmeldeseite des SSL-VPN-Gateways geht und sich dort anmeldet. Abhängig von der Konfiguration wird der eigentliche Network Connect Client dann automatisch gestartet. Ich habe dann ein SSL-basiertes VPN von meinem Windows-PC durch die große Firmen-Firewall hindurch zu meinem Juniper Gateway.

Die klassische Diskussion ist dann, daß ich da natürlich beliebige Daten hinausschleusen kann, weil der Juniper Gateway z.B. Uploads erlaubt und das ja SSL-verschlüsselt ist, d.h. die Firmen-Firewall nichts mehr sieht. Geschenkt.

Die interessante Frage die sich in unserer Diskussion jetzt gestellt hat geht genau andersrum:

Kann ein Angreifer im Internet einen bösartigen Webserver aufsetzen der automatisch diesen Network Connect startet und so einen VPN-Tunnel aufbauen, wenn der Benutzer ihn ansurft?

Das würde nämlich bedeuten, ich habe dann eine IP-basierte VPN-Verbindung von diesem Webserver im Internet durch die Firmen-Firewall hindurch zum eigentlich geschützten Client im LAN und kann diesen direkt angreifen. Eine fehlende Desktop-Firewall natürlich vorausgesetzt.

Das ist eine ähnliche Frage wie mit den diversen ActiveX-Controls die sich im Browser wiederfinden. Die können im Grunde auch von einem beliebigen Webserver gestartet werden, wenn sie “safe” sind. Und wenn dann eine Sicherheitslücke bekannt wird, muß Mirosoft wie diesen Monat wieder, Killbits für ActiveX verteilen. Oder haben die Hersteller von SSL-VPN Clients ein Verfahren implementiert mit dem der Client feststellen kann, ob er mit einem unmodifizierte Gateway des Herstellers kommuniziert?

Hach ja, SSL ist ein lustiger Dienst. Da braucht man so Zertifikate (X.509v3 ist recht beliebt) nur um dann feststellen zu können, die Webseite www.commerzbank.de gehört wirklich der Commerzbank in Frankfurt.

Wobei, wieso wirklich? Im Fall der Commerzbank bestätigt mir das die TC Trustcenter GmbH in Hamburg, seit neuestem eine Tochter der PGP Corp. Mein Mozilla Firefox (3.0.x) zeigt mir das in blauer Farbe vor der URL. Die Frage ist jetzt natürlich, ob ich TC Trustcenter glaube. Also quasi ob ich denen vertraue, daß sie die Prüfung korrekt durchgeführt haben und mich nicht belügen. Ich persönlich halte TC Trustcenter für recht seriös seit sie mal ein Zertifikat von mir nicht signieren wollten, das zugegeben geringfügig phisy aussah.

Wenn ich bei Verisign schaue, dem vermutlich weltweit wichtigsten Zertifikatsanbieter, bekomme ich sogar einen grünen Balken in meinem Firefox. Grün! Viel besser als blau! Weil Verisign hat sogar ein “Extended Validation”-Zertifikat. Übrigens von Verisign selbst ausgestellt. Die bescheinigen sich also selbst, daß sie Verisign sind. Das Extended Validation Zertifikat ist meiner Ansicht nach ja Beutelschneiderei par Excellenz. Da verlangt Verisign doppelt so viel Geld für das Zertifikat nur um den Antragsteller “genauer” zu prüfen als für weniger Geld. Als ob eine vertrauenswürdige Zertifizierungsstelle nicht sowieso genau prüfen sollte. Aber gut, von Verisign kann man vermutlich nichts anderes erwarten. Die haben auch schon mal ohne Prüfung Zertifikate auf den Namen Microsoft ausgestellt. (Die sind übrigens immernoch im Internet Explorer als “Fraudulent” zu finden). Außerdem war Verisign bis Oktober 2008 Haupteigentümer von Jamba. Das ist die Firma, die kleine Kinder mit Klingeltonabos über den Tisch zieht. Ob ich die wirklich vertrauenswürdig finde … ich bin mir da gar nicht so sicher. Verisign wäre jedenfalls der letzte Anbieter bei dem ich ein Zertifikat kaufen würde.

Der Chaos Computer Club greift übrigens auf die Dienste von CACert zurück. Die kennt mein Firefox nicht, und der Internet Explorer erst recht nicht. Obwohl ich die für recht vertrauenswürdig halte. Beim IE ist das aber klar. Ich habe mir sagen lassen, daß Microsoft rund 50.000 USD will, damit eine Zertifizierungsstelle in den IE aufgenommen wird. Und da CACert die Zertifikate kostenlos anbietet, vertragen sich die beiden Geschäftsmodelle recht schlecht. Vertrauen hin oder her.

Über die lustigeren Zertifizierungsstellen will ich gar nicht lästern, auch wenn mir ein Zertifikat einer deutschen Onlinebank ausgestellt z.B. vom “Autoridad Certificadora del Colegio Nacional de Correduria Publica Mexicana” etwas … naja, spanisch … vorkommen würde. Obwohl die laut Internet Explorer sicher sehr vertrauenswürdig sind. Leider ist deren Zertifikat Mitte 2009 abgelaufen. Aber es gibt ja auch noch die “Saunalahden Server CA” aus … na? … genau, Finnland. Wo soll so ein Saunala(h)den auch sonst herkommen

Warum ich das alles schreibe? Weil es bei SSL-Zertifikaten eben einfach nur um das Vertrauen zum Aussteller geht. Ist die Zertifizierungsstelle (CA) vertrauenswürdig? Stellt sie nur Zertifikate aus wenn die Identität korrekt verifiziert worden ist? Oder kann jeder dahergerollte Schäuble zu so einer CA gehen und ein falsches Zertifikat bekommen um einen staatlichen Man-in-the-Middle Angriff durchzuführen? Dann will ich so eine CA gar nicht im Browser haben.

Die Mozilla Foundation hat sich genau diese Diskussion nämlich jetzt eingefangen, nachdem die staatlich kontrollierte chinesische Domainregistry CNNIC mit ihrer Zertifizierungsstelle in den Firefox-Browser aufgenommen wurde. Dabei wurden die Anforderungen der Mozilla Foundation strikt erfüllt. CNNIC hat eine Zertifikatspolicy (CSP) die formal allen Anforderungen genügt. Meine Freunde von Ernst & Young haben geprüft, daß diese Policy formal ok ist. Webtrust hat gekuckt, daß Ernst & Young formal korrekt geprüft hat. Und die Mozilla Foundation verläßt sich darauf, daß die Anforderungen von Webtrust formal korrekt sind. Formal eben. Nur das mit dem Vetrauen, das ist halt schwierig.

Aber wenn mich jemand fragt … das Sicherheitsmodell von SSL ist sowieso für’n Arsch.

(via Fefe)

Nachtrag:

Die Mozilla Foundation hat die CNNIC-SSL-Zertifikate wieder aus der Standardinstallation entfernt.

Ich suche ein Stück Software, das folgende Anforderungen erfüllen sollte:

Required:

• SSL-Portforwarding, d.h. eine TCP-Verbindung (mind. SSHv2) über HTTPS
• muß mit Web-Proxys und Proxy-Authentisierung zurechtkommen
• muß im Kontext eines vorhandenen Apache Webservers laufen, weil nur eine IP-Adresse zur Verfügung steht und dort bereits ein Webserver läuft
• Darf Geld kosten, muß aber nicht

Nice to have:

• SSL-VPN, d.h. eine echte IP-Verbindung über HTTPS
• Open Source

Die Software soll auf einem meiner Webserver installiert werden und das Problem lösen, daß ich ab und an in fremden Firmen sitze, eine SSH-Verbindung nach Hause brauche aber nur HTTP und HTTPS über den Proxy bekomme. Es gibt nur eine (dynamische) IP-Adresse und ich kann auch nicht einfach einen SSH-Dienst an 443 binden, weil da weiterhin ein normaler Webserver laufen muß.

Insbesondere die Anforderung, daß das im Kontext einen vorhandenen Webservers laufen muß, scheint ein Problem zu sein. Die diversen SSL-VPN Appliances wollen alle den Port 443 alleine haben. Das ließe sich bei nur einer IP-Adresse zwar mittels Port-Forwarding auf dem DSL-Router lösen, nur brauche ich an Port 443 trotzdem noch einen normalen HTTPS-Webserver. Eine zweite IP-Adresse geht leider auch nicht.

Ich habe jetzt mit Webtunnel rumgespielt, das macht aber nicht so ganz das was ich gern hätte. Außerdem habe ich HTTPTunnel gefunden, das eine Version enthält die das in PHP implementiert. Nur kriege ich über die PHP-Version kein SSHv2 zum Laufen. Da bricht mein SSH-Server immer mit ner Fehlermeldung ab. Außerdem können beide nur TCP-Forwarding, kein echtes IP-VPN. Die üblichen Verdächtigen wie OpenVPN oder GNU HTTPTunnel scheiden aus, weil sie nicht im Kontext meines Webservers laufen. Und PHP kann ich nicht so gut programmieren, daß ich den HTTPTunnel-Fehler beheben könnte.

Alternativ wäre auch ein PHP-SSH, also ein SSH-Server im Kontext des Webservers ok. Ich finde nur gar nix, das mein Problem lösen würde. Open Source Lösungen werden bevorzugt, was nicht heißt, daß es nichts kosten darf.

Ach ja, und welchen PHP Proxy (mit ähnlichen Anforderungen wie oben, d.h. muß über HTTPS im Kontext eines Apache Webservers laufen) würdet Ihr mir empfehlen?

Vor einigen Tagen hat der schwedische Sicherheitsexperte Dan Egerstad in seinem Blog eine Liste von Passwörtern einiger ausländischer Botschaften veröffentlicht. Hier ein kleiner Ausschnitt:

Uzbekistan Foreign Affairs 57.66.151.179 Qohira 5gx7n1e4w9
Iran Embassy in Ghana 217.172.99.19 iranemb_accra@mfa.gov.ir accra
Iran Embassy in Kenya 217.172.99.19 iranemb_kenya@mfa.gov.ir kenya
Iran Embassy in Oman 217.172.99.19 iranemb_muscat@mfa.gov.ir muscat
Iran Embassy in Tunisia 217.172.99.19 iranemb_tunisia@mfa.gov.ir tunisia
Iran Ministry of Foreign Affairs 217.172.99.19 bagheripour@mfa.gov.ir amir1368
Kazakhstan Embassy in Italy 213.21.159.23 kazakstan.emb@agora.it rfywkth
Kazakhstan Embassy in Egypt 213.131.64.229 kazaemb piramid

Die vollständige Liste findet sich in Dans Blog. Ich will jetzt nicht über die Qualität der uzbekischen Passwörter und die tollen iranischen Passwörter reden, das ist dann doch ein wenig langweilig.

Irgendeine wichtige US-Behörde hat die Seite dann ein paar Tage aus dem Netz nehmen lassen, aber natürlich viel zu spät. Die Passwort-Liste hatten ich und viele andere natürlich längst gespeichert. Wenn der Geist erstmal aus der Flasche und im Internet ist, läßt er sich kaum noch wieder einfangen. Das ist wie mit dem geheimen Virtual Earth Bildern.

Interessant ist eigentlich die Art und Weise, wie Dan an die Passwörter gekommen ist. Er hat fünf Exit-Nodes des Anonymisierungsnetzwerks Tor modifiziert und einen Passwort-Sniffer für POP3 und IMAP integriert. Tor bietet halt nur anonymen Zugriff auf einen Client, aber keinen Schutz der übermittelten Daten. Das Problem ist, eigentlich ist das jedem bewußt, aber so richtig Gedanken macht sich keiner darüber.

Egerstad vermutetn außerdem, daß einige der Exit-Nodes von staatlichen Behörden, beispielsweise aus den USA, Russland oder China betrieben werden und so gezielt eine große Menge von Daten abgefischt wird. Wichtige Daten sollte man deshalb nur verschlüsselt, per SSL oder HTTPS übertragen.

Der komplette Blog-Eintrag und Heise hat es auch schon gemerkt.

Ach ja, bevor ihr jetzt alle einen Tor Exit-Node aufsetzt: StGB § 202b sagt dazu, wer unbefugt sich oder einem anderen unter Anwendung von technischen Mitteln nicht für ihn bestimmte Daten (§ 202a Abs. 2) aus einer nichtöffentlichen Datenübermittlung oder aus der elektromagnetischen Abstrahlung einer Datenverarbeitungsanlage verschafft, wird mit Freiheitsstrafe bis zu zwei Jahren oder mit Geldstrafe bestraft, wenn die Tat nicht in anderen Vorschriften mit schwererer Strafe bedroht ist.

Also 1. Hacker-Gebot nicht vergessen: Laß Dich nicht erwischen!

Microsoft hat sich mal wieder etwas eigenes ausgedacht, eine proprietäre Implementierung eines VPNs über SSL. Der Cable Guy erklärt, worum es geht.

Das Secure Socket Tunneling Protocol (SSTP) ist ein neues Protokoll, das eine sichere VPN-Verbindung auch über Adresstranslation (NAT) herstellen soll. Dabei kommen primär die bekannten TLS-Sicherungsverfahren zum Einsatz. Die ersten sechs Schritte im Tunnelaufbau sind identisch zum normalen SSL-Handshake:

1. Der Client baut eine Verbindung zum TCP-Port 443 (HTTPS) des Servers auf
2. Der Client sendet eine SSL Session Setup Message die anzeigt, daß der Client eine SSL-Verbindung zum Server aufbauen will
3. Der Server sendet dem Client sein SSL-Zertifikat
4. Der Client überprüft das Zertifikat, bestimmt die Verschlüsselungsmethode für die SSL-Sitzung, generiert einen Sitzungsschlüssel und verschlüsselt diesen mit dem öffentlichen Schlüssel des Zertifikats des Servers
5. Der Client sendet den verschlüsselten SSL-Sitzungsschlüssels zum Server
6. Der Server entschlüsselt den SSL-Sitzungsschlüssel mit dem zugehörigen privaten Schlüssel. Die gesamte Kommunikation wird mit diesem Sitzungsschlüssel verschlüsselt

Soweit kein Problem, das ist bewährter Standard. Aber nun kommt die Erweiterung:

1. Der Client sendet eine HTTP-über-SSL-Anforderungsnachricht zum Server und handelt mit dem Server einen SSTP-Tunnel aus
2. Der Client handelt mit dem SSTP-Server eine PPP-Verbindung aus. Zu dieser Aushandlung gehören die Authentifizierung der Anmeldeinformationen des Benutzers mit einer PPP-Authentifizierungsmethode und die Konfiguration der Einstellungen für den Datenverkehr
3. Der Client beginnt, über die PPP-Verbindung Datenverkehr zu senden

Das kommt mir irgendwie bekannt vor. PPP ist anscheinend das Lieblingsprotokoll von Microsoft. Das kam ja schon in PPTP zum Einsatz.

Der Overhead ist jedenfalls lustig: IP-Header, TCP-Header, SSTP-Header, PPP-Header und dann erst das eigentliche Datenpaket. Ok, gegenüber IPSec over HTTPS ist das ein wenig effizienter, der PPP-Header hat 8 Byte, der ESP-Header hat 20 Byte. Trotzdem erscheint mir PPP nicht wirklich zwingend notwendig. Die meisten mir bekannten SSL-VPN-Verbindungen kommen jedenfalls ohne PPP aus und bieten direkt IP over HTTPS. Und das scheint recht stabil zu funktionieren.

Na mal sehen, wie es sich verbreitet und ein Vorteil gegenüber PPTP dürfte es allemal sein.