Lässt sich EV SSL für Phishing-Kampagnen verwenden?

In jüngster Zeit ist eine teilweise erbittert geführte Debatte um den Wert von EV SSL-Zertifikaten entbrannt. Ausgelöst unter anderem von einigen Wissenschaftlern, die Beiträge zum Thema veröffentlicht hatten.

Einer von ihnen, Scott Helme, beschäftigte sich damit wieso der Firmenname in der URL-Leiste durchaus Verwirrung stiften kann. Der Artikel ist wiederum als eine Art Replik erschienen. James Burton hatte seinerseits gezeigt, dass er für eine in Großbritannien gegründete falsche Firma ein Zertifikat von Comodo und Symantec erhalten hatte. Seine Schlussfolgerung: Hacker können auf die Zugangsdaten im Dark Web zugreifen um eine „Fake“-Firma zu gründen. Um anschließend eine gefälschte Domain sowie ein EV SSL-Zertifikat zu kaufen und so die Domain abzusichern. Der Wissenschaftler Ian Carroll führte ein etwas anderes Experiment durch. Er registrierte eine falsche Firma, aber im Namen eines Unternehmens, das bereits existierte, Stripe. Er registrierte das Unternehmen in einem anderen Land, beantragte ein Zertifikat für https://stripe.ian.sh, anstelle des echten https://stripe.com, und demonstrierte, dass die URL-Leiste in Safari für beide Websites identisch erscheint.

Diese Beiträge haben eine branchenweite Welle von Diskussionen zum tatsächlichen Wert von EV SSL ausgelöst. Allerdings kommt die Debatte nicht ohne Verkürzungen und gelegentliche Falschdarstellungen aus, was die Voraussetzungen anbelangt. Sicherlich kann man Zertifizierungsstellen verantwortlich machen, wenn sie gelegentlich EV SSL so vermarkten als könne man damit nicht nur Phishing im Alleingang verhindern, sondern gleichzeitig die Online-Verkaufszahlen magisch in die Höhe treiben. Aber selbst Sicherheitsexperten und Befürworter von DV haben mit dafür gesorgt, dass EV SSL bei der Internetsicherheit nicht den Stellenwert hat, den es haben sollte. Und auch die Browser-Anbieter haben bei EV nicht unbedingt an eine benutzerfreundliche und auf den ersten Blick verständliche Oberfläche gedacht.

Dieser Beitrag beschäftigt sich mit einigen der wichtigsten Probleme mit EV SSL. Die verwendeten Zitate stammen aus der Mozilla Dev Security Policy Group in Google.

Sinn und Zweck eines EV SSL-Zertifikats

Lässt sich EV SSL für Phishing-Kampagnen verwenden? Offensichtlich ja. Aber ein Hacker muss schon ziemlich entschlossen sein und sich die Mühe machen, eine gefälschte Identität zu kaufen, ein falsches Unternehmen zu registrieren, ein Premium-Zertifikat zu bezahlen und 3 bis 5 Tage nach einer EV SSL-Bestellung auf seine Validierung zu warten. Erst dann kann er seine kriminellen Aktivitäten starten. Vor allem, wenn er bereits weiß, dass er in Sekundenschnelle ein kostenloses DV bekommen kann, mit dem er das grüne Vorhängeschloss erhält, das Signal in der Browserleiste dem wohl die meisten Verbraucher vertrauen.

Hier setzt EV SSL an. Als das CA/Browser-Forum (CA/B) die Richtlinien für EV aufgestellt hat, wurde ausdrücklich erklärt, dass der Zweck eines EV SSL-Zertifikats darin besteht:

a) den Rechtsträger zu identifizieren, der eine Website kontrolliert und
b) verschlüsselte Kommunikation mit einer Website zu ermöglichen.

Speziell in Bezug auf Punkt “a” besagen die Richtlinien, dass EV dazu bestimmt ist:

“Dem Nutzer eines Internet-Browsers eine angemessene Zusicherung zu geben, dass die Website, auf die der Nutzer zugreift, von einem bestimmten Rechtsträger kontrolliert wird, der im EV-Zertifikat mit Namen, Anschrift des Geschäftssitzes, Gerichtsstand oder Registrierung und Registrierungsnummer oder andere eindeutige Informationen identifiziert ist.”

Es ist ausdrücklich von einer angemessenen Zusicherung die Rede. Es lässt sich nicht zu 100% garantieren oder sicher wissen, dass die Website, auf der ein Kunde sich gerade befindet, die eines legitimen Unternehmens ist (und ein EV-Zertifikat bürgt schon gar nicht für die Aktivitäten des Unternehmens). Was das Zertifikat allerdings zeigt ist, wer dieses Unternehmen ist.

Datenschutz versus Identität

Seit den Anfängen des Internets gibt es zwei grundlegende Sicherheitsprobleme, die man versucht zu lösen:

1. Datenschutz – Wie stellen wir sicher, dass ein Dritter die private Kommunikation zwischen zwei Teilnehmern nicht liest?
2. Identität – Wie kann A sicherstellen, dass es wirklich B ist, mit dem A kommuniziert?

Diese Problematik ist derjenigen nicht unähnlich mit der wir es schon vor der Existenz des Internets zu tun hatten. Bei Postsendungen nutzen wir Umschläge und Siegel, um zu verhindern, dass sie geöffnet werden. Aber niemand garantiert, dass die Sendung nicht doch geöffnet oder ein Siegel gefälscht worden ist. Sozusagen die Old-School-Version eines Man-in-the-Middle- oder Phishing-Angriffs.

Dies erinnert an früher kursierende Argumente man könne DV für Phishing verwenden, letztlich ein Identitätsproblem – Besucher können nicht erkennen, wer die Website betreibt und mit wem sie kommunizieren. Am 20. März 2017 veröffentlichte Vincent Lynch von The SSL Shop einen Blog in dem er 1.000 Zertifikate zeigt die alle auf „PayPal“ ausgestellt worden waren.

Unternehmen wie Let’s Encrypt werden für die einfache und effektive Möglichkeit kostenlose DV-Zertifikate bereitzustellen gelobt. Allerdings hat diese Methode gleichzeitig den Weg für Millionen von Phishing-Websites bereitet, die jetzt das grüne Vorhängeschloss missbrauchen um vertrauenswürdig zu erscheinen. Und kürzlich haben einige Browser-UIs ein “Sicher”-Label für alle Sites aufgenommen, die SSL verwenden. Selbst eine Phishing-Site würde mit “sicher” gekennzeichnet, wenn sie ein DV-Zertifikat verwendet.

Das Problem ist, dass hier Datenschutz und Identität miteinander verschmelzen. Die Anzeige von Vorhängeschloss, HTTPS und in einigen Fällen dem “Sicher”-Label in einem Browser dienen nur dazu, für den Datenschutz zu bürgen (die Verbindung zur Website ist verschlüsselt). Allerdings setzen die Besucher einer Webseite aufgrund dieser Sicherheitsindikatoren automatisch ein gewisses Maß an Legitimität voraus.

Scott Helme hat das in seinem Artikel so ausgedrückt:

Die Anzeige “Sicher” bedeutet, dass der Browser sich mit einem Server verbunden hat, der ein gültiges Zertifikat für den Domainnamen, mit dem die Verbindung hergestellt wurde, vorweisen kann. Ausgestellt von einer CA, der der Browser vertraut, und dass eine verschlüsselte Verbindung hergestellt wurde. Das ist alles. Das ist alles, was das grüne HTTPS-Signal in der Adressleiste bedeutet. Das Problem ist, dass viele Nutzer annehmen, dass viel mehr dahinter steckt und dass es der Website eine gewisse Glaubwürdigkeit verleiht.
 

Könnte man die Identität einer Website für deren Besucher transparent gestalten, würde das vermutlich einen Teil der Verwirrung beseitigen. Etwa: “Ihre Eingaben werden verschlüsselt UND Sie kommunizieren tatsächlich mit der gewünschten Person”. In dieser verifizierten Identitätsinformation liegt der eigentliche Wert von EV. Und das ist einer der Gründe dafür warum EV SSL nicht wegzudenken ist.

EV soll den Rechtsträger zu identifizieren, der eine Website kontrolliert. Diese Information befindet sich bereits im Zertifikat. Es geht nur darum, sie dem Besucher leichter zugänglich zu machen. Wie diese Informationen präsentiert werden, ist möglicherweise verbesserungsfähig. Trotzdem rate ich davon ab EV vorschnell zu verwerfen, statt das Beste aus den strengen EV-Identitätsverifizierungsprozessen herauszuholen. Wie diese Informationen präsentiert werden hängt maßgeblich von der Browser-UI ab.

Browser UI

Wenn man sich die von Ian Carrol verwendeten Screenshots ansieht, erkennt man auf Anhieb, wie unterschiedlich EV SSL je nach Browser-Typ erscheint.

1. Safari – verbirgt die URL vollständig. Das ist kaum hilfreich für Benutzer, die versuchen, eine Phishing-Website zu erkennen.

2. Chrome – Chrome zeigt aktuell EV mit dem Firmennamen in grün nach dem Vorhängeschloss an. Um weitere Details zum hinter dem Zertifikat stehenden Unternehmen anzuzeigen, muss man einige Mausklicks ausführen und sich die Zertifikatdetails ansehen.

In der Mozilla Diskussionsgruppe ging Ryan Sleevi sogar so weit, dass Chrome dieses spezielle Merkmal aus seinem Browser entfernen könnte:

Wie Sie wissen, bewertet Chrome immer noch den Wert von EV mit einer speziellen Benutzeroberfläche, wie in vergangenen CA/Browser Forum-Meetings [1][2] diskutiert. Dies bezieht sich nicht auf den Wert von EV für das Ökosystem insgesamt, sondern eher auf den Wert für den Browser, solche Zertifikate zu unterscheiden oder spezialisierte UI zu benötigen.

3. Firefox – Erlaubt, im Gegensatz zu Chrome, Ort und Land/Staat in denen ein Unternehmen beheimatet ist mit zwei Mausklicks anzuzeigen. Ein Benutzer muss dazu aber wissen, wo das Unternehmen seinen Hauptsitz hat, bevor er überprüfen kann, ob die Informationen tatsächlich zutreffen.

Vertreter von Google schlagen allerdings vor, die EV-Benutzeroberfläche vollständig zu entfernen. Ein zumindest irritierender Vorschlag, wenn die Standardisierung einer EV-Benutzeroberfläche doch augenscheinlich zur Lösung der geschilderten Probleme beitragen könnte.

Sicher, wahrscheinlich macht sich nicht jeder die Mühe, Ort und Herkunftsland der besuchten Website zu überprüfen. Mit ein bisschen mehr Sensibilisierung würde das die Mehrzahl der Nutzer aber zumindest für sehr populäre Websites mit hoch vertraulichen Transaktionsdaten wie beispielsweise Pay Pal tun. Trennt man sich komplett von der EV-Benutzeroberfläche kann kein Internetnutzer mehr die Rechtmäßigkeit einer Website beurteilen. Phishing-Filter würden erst aktiv, wenn es bereits Opfer gegeben hat. Nicht unbedingt ideal. Eine eindeutige Browsererkennung und für eine weniger riskante Entscheidungsfindung sensibilisierte Benutzer, scheinen mir doch der bessere Weg zu sein.

EV-Validierung

Die EV-Validierung sei Teil des Problems, auch das ein Argument innerhalb der aktuellen Diskussionen. Gemäß den Richtlinien muss eine Zertifizierungsstelle Folgendes überprüfen:

1. die rechtliche Existenz oder Identität eines Antragstellers,
2. die physische Existenz eines Antragstellers,
3. die betriebliche Existenz eines Antragstellers.

Ein Antragsteller muss sich als private Organisation qualifizieren, indem er sich bei einer in seinem Hoheitsgebiet ansässigen Integrations- oder Registrierungsstelle anmeldet. In vielen Fällen gibt es dann eine Registrierungsnummer. Allerdings haben wir schon demonstriert bekommen wie einfach es ist ein Unternehmen anzumelden und zu registrieren. Es gibt keinerlei Überprüfung des Antragstellers durch die Behörden. Aber was würden die gegebenenfalls prüfen? Hier kommen Punkt zwei und drei ins Spiel.

Obwohl eine Zertifizierungsstelle prüfen würde, ob das Unternehmen registriert ist, sind weitere Überprüfungen nötig, um sicherzustellen, dass die Geschäftseinheit tatsächlich existiert. Die physische Existenz der Entität lässt sich mit einem virtuellen Büro vortäuschen. Es braucht also zusätzliche Schritte um sicherzustellen, dass der Standort real und nicht nur virtuell ist. Wer bei Ian Carrolls Antrag genauer hingesehen hat, der hat vielleicht bemerkt, dass der Geschäftsstandort von Stripe eher weniger “physisch” ist (zum Beispiel durch einen Blick auf Google Maps Street View).

Darüber hinaus besagt das CA/B-Forum, dass eine CA die betriebliche Existenz einer Geschäftseinheit überprüfen muss. Das stellt sicher, dass der Antragsteller tatsächlich ein Geschäft betreibt. Dabei muss die CA nicht prüfen, ob es sich um ein rechtlich und ethisch korrektes Geschäft handelt. Aber auch auf dieser Grundlage hätte man bei genauerem Hinsehen den Antrag von Stripe in Frage stellen müssen.

Dazu bieten einige Zertifizierungsstellen interne Verfahren an, die vorschreiben, jedes Unternehmen, das erste seit kurzem registriert ist, mit besonderer Vorsicht zu betrachten. Über die Anforderungen des CA/B-Forums hinaus hilft es, eine Organisation aus einer ganzheitlichen Perspektive heraus zu betrachten, um festzustellen, ob ein Unternehmen registriert ist, Geschäfte an einem physischen Standort tätigt und tatsächlich ein Geschäft betreibt.

Doug Beattie von GlobalSign dazu in der Mozilla-Gruppe:

Es liegt im eigenen Interesse einer CA die Richtlinien und Anforderungen für die Ausstellung von EV zu verbessern. Die Finanzbranche hat Vorschriften, die allgemein als “Know Your Customer” (KYC) bekannt und dazu gedacht sind, Vorgänge wie Geldwäsche, Terrorismusfinanzierung und ähnliches auszuschließen. Obwohl KYC nicht direkt auf CAs und EV anwendbar ist, kann es als Modell dienen, bei dem Kunden überprüft werden, bevor eine CA bestimmte Aktionen gestattet. Es erscheint mir zum Beispiel nicht vertretbar, dass eine CA ein EV-Zertifikat an ein Unternehmen ausstellt, das keine Vorgeschichte hat und nur einen dünnen Beweis seiner Legitimität übermittelt. Alle Zertifizierungsstellen müssen in dieser Hinsicht besser werden. Ich halte es für durchaus zumutbar, dass CAs vor der eigentlichen EV-Ausstellung eine dokumentierte, bereits bestehende Beziehung zu einem EV-Antragsteller haben.

Und jetzt?

Es ist richtig, CAs sind an den geschilderten Problemen und den damit verbundenen Diskussionen nicht ganz unschuldig. Deshalb hat der CA Security Council jetzt die EV SSL-Debatte zu seiner obersten Priorität gemacht. Gemeinsam mit dem CA/B-Forum sollen die Bedingungen für EV SSL so verändert werden, dass EV seine Qualitäten tatsächlich ausspielen kann.

Aus unserer Sicht sollten drei Dinge passieren und zwar zügig:

1. EV SSL-Zertifikate sollten nicht länger als Wunderwaffe gegen Phishing vermarktet werden. Sie bieten Unternehmen zwar die Möglichkeit, ihre Identität an ihre Websites zu binden, und Besucher der Seite diese Identität erkennen. Das trägt dazu bei, legitime Websites, die EV verwenden, von betrügerischen Websites, die DV-Zertifikate verwenden, zu unterscheiden. Aber EV-Zertifikate können und werden Phishing kein Ende setzen.
    
2. Browser-Anbieter müssen mit den CAs arbeiten, nicht gegen sie. Ja, sie sind verantwortlich für ihre Produkte und deren Vermarktung. Aber sie sind auch dafür verantwortlich, wie digitale Zertifikate von den Benutzern wahrgenommen werden. Mozilla und Google haben beide Allianzen mit Let’s Encrypt geschlossen. Sie kümmern sich also wenig um EV SSL. Initiativen sollten dahin gehen, Richtlinien durchzusetzen und Benutzeroberflächen zu standardisieren – das Vorhängeschloss für DV, ein anderer Sicherheitsindikator für EV und die Versicherung, dass URLs nicht verschleiert werden, wie es bei Safari mit EV der Fall war. Diese Themen sollten im CA/B-Forum offen diskutiert werden.
    
3. Strengere Prüfverfahren und -praktiken müssen ausgearbeitet und an alle Zertifizierungsstellen angepasst werden, um sicherzustellen, dass gründlichere Überprüfungen einer antragstellenden Organisation zur Regel werden. Nur so lässt sich das Risiko senken, dass ein gefälschtes oder illegitimes Unternehmen ein EV SSL-Zertifikat beantragen und bekommen kann.

DV ist großartig, wenn es um den Datenschutz geht. Aber es ist genauso wichtig die Identität innerhalb der Kommunikation sicherzustellen. Beides ist nötig, wenn man das Risiko für die Benutzer so weit wie möglich senken will.