HTTPS-Verschlüssung, ihre Herausforderungen inkl. Certificate Authorities (CA)
Philipp Schaumann - Letzte Aktualisierung: August 2023 aus Anlass von '10 Jahre Let's Encrypt' - siehe hier.
Das verschlüsselte Protokoll HTTPS gehört zum Kern der Sicherheitsmaßnahmen des Internets. Daten die im Internet fließen, also z.B. vom Web-Browser zum Webserver, aber auch von der Smartphone App zum Webserver werden mittels HTTPS veschlüsselt und können dann nicht mehr abgehört oder verändert werden. Soweit die Theorie, in der Praxis kann es (wie bei allen Aspekten des Lebens, wo Software eine Rolle spielt) zu erheblichen Herausforderungen kommen.
Das HTTPS-Ökosystem besteht aus einer Reihe von Komponenten, von denen eine gute Anzahl erhebliche Sicherheitsprobleme hat.
Das Protokoll HTTPS wird implementiert mittels den Verschlüsselungen (früher SSL, heute hoffentlich TLS 1.3) und sog. SSL-Zertifikaten verschlüsselte Verbindungen, die nur zwischen Endpunkten aufgebaut wird, die sich "trusten" dürfen, d.h. die vorher gegenseitig ihre Identität geprüft haben.
Das ursprüngliche Konzept: Client- und Server-SSL-Zertifikate
In der Theorie sah das ursprünglich mal so aus, dass Client (d.h. der Webbrowser) und der Webserver beide jeweils selbst ein SSL-Zertifikat besitzen und sie das SSL-Zertifikat der anderen Stellle kennen. Dieses wird beim Verbindungsaufbau ausgetauscht und geprüft, damit wissen beide, dass sie eine direkte Verbindung miteinander haben, und dass kein böser Man-in-the-Middle dazwischen steht.
Das erste Problem ist, dass sich Client-SSL-Zertifikate nie durchgesetzt haben, weil sie für den Benutzer umständlicher wären als die jetzige Situation, d.h. die Browser werden vom Server immer akzeptiert, die Authentisierung findet über Benutzernamen und Passwort statt, mit all den damit verbundenen Passwort-Problemen. Die Server-Zertifikate werden im Browser angezeigt (durch Klick auf das Vorhängeschloss) und der Benutzer könnte jetzt z.B. beim Helpdesk anrufen und den sog. Fingerprint vergleichen. Auch dann wüsste er, dass er direkt und sicher mit dem Webserver seines gewünschten Dienstes, z.B. sein Webmail-Anbieter, verbunden ist.
Ich ignoriere jetzt mal die Schwächen der älteren Versionen der SSL- und TLS-Protokolle, die leider von den vielen Webservern weiter unterstützt werden (weil sonst die Browser nicht mehr funktionieren würden, die mehr als 5 Jahre alt sind und niemals aktualisiert wurden). Wenn die alten Protokolle vom Server noch akzeptiert werden, kann sich sehr wohl jemand in die Verbindung hängen, obwohl sie verschlüsselt ist. Begründung für das Akzeptieren der unsicheren SSL-Protokolle ist, das es immer noch Internet Explorer 6 Benutzer gibt, aber die sind fast alle in China. Das sollte für eine europäische Bank kein Grund sein, SSLv2 weiterhin zu erlauben.
Man-in-the-Middle Angriffe gegen HTTPS
Bei einem Man-in-the-Middle Angriff hängt der Angreifer im Datenverkehr zwischen Browser und Server und tritt gegenüber dem Webserver als Client auf und gegenüber dem Webbrowser als Webserver. D.h. er spielt beide Rollen gleichzeitig. Um diesen Angriff durchzuführen muss der Angreifer "im Datenverkehr" sitzen. Das ist aber in der Praxis oft gar nicht so schwierig. In dieser Position sind alle Stellen, die ihren Datenverkehr weiterleiten, z.B. ihr ISP (Internet Service Provider) oder der ihres Stammcafés über dessen WLAN sie surfen). Oder es sind staatliche Stellen, die sich (irgendwie) die privilegierte Position beschafft haben. Aber es geht auch harmloser: In jedem öffentlichen WLAN-Hotspot oder Hotel-Netwerks können die Techniker des jeweiligen Betreibers den Datenverkehr angreifen. Aber auch andere Nutzer im selben WLAN können evt. ihren Datenverkehr mitschneiden (abhängig davon, wie sicher das WLAN aufgebaut ist).
Die Herausforderung bei HTTPS-Verbindungen ist, dass der Browser vor jeder Verbindung überprüfen muss, ob das Zertifakat, das der Webserver dem Browser präsentiert, in der Liste der vertrauenswürdigen Certification Authorities (CAs) enthalten ist. Falls ja, so gibt es keine Warnung. Falls ein Angreifer in der Verbindung hängt und dem Browser nicht das Originalzertifikat, sondern ein vom Angreifer selbst ausgestelltes Zertifkat präsentiert wird ("self-signed"), so bekommt der Benutzer eine Warnung dass die Website unsicher wäre. An dieser Stelle brechen nach Studien ca. die Hälfte der Benutzer ab, die andere Hälfte geht trotzdem auf die Website und lässt sich damit den Datenverkehr abhören.
Aber es kann auch noch einfacher gehen: Die einfachste Methode für einen Angriff gegen eine HTTPS-Verbindung ist wohl SSL-Stripping. Dabei macht sich der Angreifer, der es geschafft hat sich als Man-in-the-Middle in den Datenvekehr zu hängen, gar nicht die Mühe, dem Benutzer eine HTTPS-Verbindung vorzugaukeln, er leitet den Datenverkehr einfach über HTTP and den Browser weiter und vertraut darauf, dass die Benutzer nicht merken, dass die URL-Zeile nicht so aussieht wie gewohnt. Ganz oft klappt das, weil die Benutzer am Inhalt der Seite selbst keinen Unterschied sehen. Dieser Angriff kann vereitelt werden, wenn die Website mittels HSTS dem Browser mitteilt, dass ihre Inhalte nie über http kommen werden, dies ist heute aber noch selten. (Technische Details zu diesem Angriff finden sich unter Man-in-the-Middle.)
Angreifer lösen die Herausforderung der Zertifikatsüberprüfung (in sehr seltenen Fällen), indem sie einen CA hacken, so wie das seit 2011 immer wieder mal passiert ist. So konnte sich ein Angreifer nach einem solchen Angriff Zertifikate im Namen von Google, Microsoft und Facebook selbst ausstellen und die iranischen Regierungsbehörden waren in der Lage, den Datenverkehr von vermutlich mehr als 1 Mio. Bürgern mitzulesen, die Passworte zu speichern und auf deren Emails zuzugreifen. Mehr zu solchen Problemen weiter unten.
Eine weitere Angriffsmethode geht davon aus, dass bei den meisten Webseiten verschüsselte und unverschlüsselte Inhalte kombiniert werden. In diesem Fall reicht es, wenn der Angreifer in eine der unverschlüsselten Übetragungen "böse" Scripts einbaut, damit kann er zwar nicht den ganzen Datenverkehr abhören, aber evtl. die Kontrolle über den Browser übernehmen. Dieser Angriff wird als "Mixed Scripts" bezeichnet. Oft reicht es dann für den Angreifer, sich einen Session Cookie zu besorgen und schon hat er eine eigene Verbindung zum Account des Opfers, z.B. zu seinem Emails oder seiner Facebook-Seite. Website-Designer können diesen Angriff einmal dadurch verhindern, dass sie ALLE Inhalte mittels HTTPS übertragen, zum anderen müssen sie bei Cookies den Parameter "secure" setzen und damit können diese nicht in unverschlüsselten Verbindungen übertragen werden.
Mehr dazu auch auf Living with HTTPS. Dort ist auch ein Link auf SSL Labs wo jede Website auf die Qualität ihrer SSL-Implementierung geprüft werden kann. Qualys, die diese Website erstellt hat, hat auch auf der RSA Conference 2012 vorgetragen: SSL and Browsers: The Pillars of Broken Security (pdf). Dieses Dokument präsentiert viele interessante Statistiken zum Zustand des Internets, die dadurch gewonnen wurden, dass die Ergebnisse von SSL Labs ausgewertet wurden. In dem Dokument wird es dann manchmal auch leicht technisch, dort wird auch erklärt, wie man einen Apache-Webserver korrekt mit SSL konfiguriert und wie die Website-Administratoren die Sicherheitsprobleme recht leicht vermeiden können.
HTTPS und Smartphone Apps
Das größere Problem (seit 2010 oder so) sind aber die Smartphone Apps. Beim Browser am PC oder MacOS-System hat der Benutzer wenigstens noch die Möglichkeit, sich das Zertifikat des Servers anzusehen, beim Browser am Smartphone wird aus Platzgründen oft darauf verzichtet, bzw. in den Smartphone Apps gibt es die Möglichkeit überhaupt nicht. Mal abgesehen davon, dass eine sehr große Zahl von Apps ganz ohne HTTPS sensible Daten (z.B. Adressbücher) versendet, so zeigen Studien, dass 80% (oder so) der Apps die Verschlüsselung falsch implementieren. Darunter sind auch Bankenapps, Paypal, Amazon Payment Services, etc.
Aber selbst wenn die App-Entwickler sich bemühen, die Daten verschlüsselt zu versenden, so machen es leider die meisten falsch. Sie prüfen entweder die Zertifikate die sie vom (angeblich korrekten) Webserver bekommen überhaupt nicht (und damit kann der Angreifer sein eigenes "self-signed" Zertifikat präsentieren und kann mitlesen) oder sie prüfen die Zertifikate, so wie die Browser das auch tun, gegen eine in den Browsern und den Smartphone "eingebaute" Liste von vertrauenswürdigen Zertifikatsausstellern (certificate authority). Und die Certificate Authorities sind eben manchmal gehackt und dann können Angreifer den Datenverkehr mitlesen. Dies war 2012 der Fall und die iranischen Regierungsbehörden waren in der Lage, den Datenverkehr von vermutlich mehr als 1 Mio. Bürgern mitzulesen, die Passworte zu speichern und auf deren Emails zuzugreifen.
Ein vernünftiger Schutz gegen gefälschte Zertifikate lässt sich dabei leicht implementieren. Die Technik wird Certificate Pinning und besteht darin, dass die App ja genau weiß, auf welche Website die Benutzer zugreifen werden und die Prüfung auf genau dieses Zertifikat kann im Quellcode der App fest eingebaut werden. Auf diese Weise wurden übrigens die Angriffe im Iran entdeckt: Google hat in den Chrome-Browser die Zertifikate der Google-Webseiten fest eingebaut und daher hat der iranische Angriff bei allen Browsern außer Chrome geklappt. Chrome-Benutzer haben das weitergemeldet und so kam der Angriff auf DigiNotar ans Licht.
Konzeptionelle Löcher bei den Certificate Authorities (CAs)
Die ganze Idee hinter den Certificate Authorities ist, dass diese Trust, d.h. Vertrauen in die Identität und Korrektheit einer Website herstellen können. D.h. es soll eine neutrale vertrauenswürdige Stelle geben, die für die Website bürgt. Dies setzt aber einmal voraus, dass dieser Stelle grundsätzlich getraut werden kann, und andererseits, dass diese Stelle technisch sicher implementiert ist. Beides ist nur begrenzt gegeben und damit auf sehr wackligen Beinen.
Ein Problem ist, dass seit spätestens 2011 sich eine erhebliche Zahl von CAs hat hacken lassen (z.B. DigiNotar, Verisign, Comodo, GlobalSign, Trustwave - und das sind nur die, bei denen durch mehr oder weniger Zufall der Sicherheitseinbruch in der Öffentlichkeit bekannt wurde). D.h. es ist Angreifern gelungen, sich SSL-Server Zertifikate für prominente Internet-Domains wie z.B. Gmail und Facebook auszustellen. Diese falschen Google- oder Facebook-Zertifikate wurden dann u.a. dafür genutzt, sich den Internet-Traffic von Websurfern im Nahen Osten (z.B. Iran) reinzuhängen und deren Emails und Facebook-Posts mitzulesen.
Jeder für jeden
Eine der Kernschwächen des HTTPS-Systems ist, dass jede Certificate Authority (CA) auf der Welt Zertifikate für jede Domain ausstellen kann. Das bedeutet, dass 1 unsichere CA das gesamte System gefährdet (so wie dies ja auch praktisch immer wieder der Fall war). Irgendwelche CAs werden überredet oder werden gehackt und stellen dann Zertifikate für alle möglichen Websites aus, die mit ihnen keine Geschäftsbeziehungen haben.
Dazu kommt, dass mindestens 50 CAs im Besitz von Regierungen sind, d.h. dort können die jeweiligen Geheimndienste SSL-Zertifikate für jede beliebige Website bestellen und haben damit Zugriff auf den verschlüsselten Datenverkehr ihrer Bürger (den HTTPS-Datenverkehr, um präzise zu sein, die Skype-Verschlüsselung läuft anders und gilt (noch) als sicher).
Für CAs die SSL-Zertifikate verkaufen möchten ist es unumgänglich, dass ihr Root-Certificate in den Browsern inkludiert ist, damit die Benutzer wenn sie eine Website ansurfen für die eine bestimmte CA ein SSL-Zertifikat ausgestellt hat, keine Warnung bekommen. In den verschiedenen Browsern ist die Zahl unterschiedlich, sie kann aber über 650 liegen. Dazu kommt noch, dass auch weiteren CAs vertraut wird, wenn sie nämlich als Sub-CA eines dieser 650 CAs gelten. Dies bedeutet, dass wir es mit einer unüberschaubaren Zahl von CAs zu tun haben, von denen eine einzige unsicher sein muss, um das ganze System zum Einsturz zu bringen.
Da die EU auf Grund der desolaten Situation bei Certification Authorities plant, eine strengere Regulierung für CAs einzuführen haben Forscher der Universität Amsterdam ein wissenschafliches Papier erstelllt, das die grundsätzliche Problematik behandelt:
Certificate Authority Collapse: Regulating Systemic Vulnerabilities in the HTTPS Value Chain (PDF, 31 Seiten). Dieses Dokument beschreibt einige technische Aspekte, aber das Hauptthema ist die Analyse der HTTPS-Ökosystems aus juristischer Sicht.
Dabei kommt aber die Analyse der bisherigen Vorfälle nicht zu kurz, speziell aus dem Fall DigiNotar leiten die Autoren eine ganze Reihe von Forderungen her. Dort sind nämlich die Schwächen sehr deutlich zu Tage getreten. Da offensichtlich desolate Zustände bei DigiNotar herrschten hat die Regierung kurzerhand die Kontrolle über die Firma übernommen (ohne dafür eine rechtliche Grundlage zu haben).
Dann wurde im Fall von DigiNotar (siehe unten) entschieden, dass die Zertifikate, die kompromitiert worden waren und eigentlich als "ungültig" erklärt werden müssten ("Revocation") erst mal weiterhin gültig bleiben müssen, weil sonst der Zugriff zu ca. 85 000 Websites nicht mehr möglich gewesen wäre (und keine elektronische Steuererklärung in den Niederlanden). Dadurch wurde aber die Sicherheit der iranischen Bürger weiterhin gefährdet, die deswegen weiterhin keine Browser-Warnungen bekamen wenn die Regierung sich in ihre Internet-Verbindungen reinhängt.
Folgende Punkte sehen die Forscher kritisch bei dem neuen Entwurf einer Regulierung der Certification Authorities:
Der Entwurf sieht als Begründung für die Regulierung, dass die Internetnutzer das Vertrauen in die Sicherheit ihrer Web-Aktivitäten nicht verlieren sollen. Dies ist leider am einfachsten dann erfüllt, wenn solche Vorfälle der Öffentlichkeit nie bekannt werden. Die Forscher schlagen vor, dass in Übereinstimmung mit der Europäischen Menschenrechtscharta eher die Sicherung der Privatsphäre und die Vertraulichkeit der Kommunikation die Priorität bei der Implementierung dieser Regeln sein sollte.
Der andere große Verbesserungsvorschlag ist, dass die Forscher es für unwahrscheinlich halten, dass das ganze HTTPS-Ökosystem durch die Vorgabe einer Haftung der europäischen CAs für grobe Fahrlässigkeit (die im Fall von DigiNotar sicher gegeben war) repariert werden kann. Wie auch in diesem Artikel aufgezeigt gibt es eine mindestens ebenso große Mitschuld an der Situation bei den Betreibern der Website und den Entwicklern der Apps, wo nur wenige HTTPS korrekt implementiert haben. D.h. selbst wenn bei den CAs alles in Ordnung wäre, so wären die Websites und die Apps immer noch fast genauso unsicher.
Die Forscher erwarten sich von einer europäischen Regelung eine Abwägung wie die Interessen in Bezug auf Vertraulichkeit der Kommunikation gegen die Verfügbarkeit der Websites bei Vorliegen eines Vorfalls im konkreten Fall gegeneinander abgewogen werden sollen.
Lösungsvorschläge und -implementierungen - Let's Encrypt
Einfache HTTPS-Implementierung für alle durch kostenlose, einfache Basis-Zertifikate
In den letzten Jahren hat es einige interessante und sogar gemäßigt erfolgreiche Verbesserungen gegeben. Ein wichtiger Faktor auf dem Weg zu eine Internet, in dem alle Daten verchlüsselt übertragen werden ist die Initiative Let's Encrypt (LE). Dies ist eine öffentlich betriebene Zertifizierungsstelle, die Ende 2015 in Betrieb gegangen ist und kostenlose X.509-Zertifikate für Transport Layer Security (TLS) anbietet. Dabei ersetzt ein automatisierter Prozess die bisher gängigen komplexen händischen Vorgänge bei der Erstellung, Validierung, Signierung, Einrichtung und Erneuerung von Zertifikaten für verschlüsselte Websites. Im Prinzip werden die Zertifikate direkt mit DNS-Einträgen gekoppelt - Wer eine Domaine besitzt, darf für diese auch ein SSL-Zertifikat ausstellen lassen.
Da die gesamte Arbeit automatisiert ist sind jetzt Website-Hoster, so wie der bei der diese Website betrieben wird, in der Lage, Leuten wir mir die eine Website mit HTTPS versehen wollen, die gesamte Aktivität von der Anforderung des Zertifikats bis zu seiner Installation mit einem simplen Klick anzubieten. Auch die Erneuerung der Zertifikate kann automatisiert werden. D.h. es gibt eigentlich keinen guten Grund mehr, eine Website NICHT zu verschlüsseln.
Dadurch dass HTTPS jetzt so leicht implementiert werden kann gibt es Aktivitäten der Browser-Anbieter, bereits im Sommer 2018 alle nicht-verschlüsselten Websites mit Warnungen zu versehen: Chrome markiert bald alle HTTP-Webseiten als unsicher . Wie sich das auswirken wird, d.h. ob dies zu einer weiteren "Abstumpfung" der Nutzer gegenüber Warnungen führt, hängt wohl davon ab, ob das Ziel einer wirklich fast vollständigen Abdeckung des WWW zu erreichen. Schon seit 2014 ist SSL sogar ein Ranking-Faktor: Eine HTTPS-Verschlüsselung verbessert die Position bei Google. Unverschlüsselte Seiten landen unter Umständen auf den hinteren Suchergebnisseiten. (Ebenso wie Google durch den Ranking-Algorithmus erzwingt, dass Websites "mobil friendly" sein müssen, wenn eine Website auf einem Smartphone nicht vernünftig zu nutzen ist, wird sie bei einer Google-Suche auf einem Smartphone auch nicht gelistet.)
Von Let's Encrypt werden sogenannte Domain-Validation-Zertifikate (DV)ausgestellt (und zwar mittlerweile [2018] sehr viele: Let's Encrypt stellt jetzt mehr als die Hälfte aller SSL-Zertifikate aus. Wer die Organization-Validation- (OV) und Extended-Validation-Zertifikate (EV) benutzen möchte, der muss weiterhin zu den kommerziellen CAs gehen.
Secorvo berichtet in seinem März Newsletter dazu: "Die EV (Extended Validation) Zertifikate enthalten über den oder die Servernamen hinaus weitere Angaben zum dahinter stehenden Unternehmen. In einem für Antragsteller und Trustcenter gleichermaßen aufwändigen Validierungsprozess wird sichergestellt, dass alle enthaltenen Angaben korrekt sind, das Unternehmen die fragliche Internet-Domain besitzt und die Erstellung des Zertifikats auch tatsächlich veranlasst hat. EV-Zertifikate werden eingesetzt, wo dies regulatorisch verlangt ist, bspw. beim Online-Banking, oder wo immer der Serverbetreiber Wert auf den „grünen Balken“ legt, mit dem Browser besondere Vertrauenswürdigkeit anzeigen."
Für die OV (Organization Validation) Zertifikate sieht secorvo keinen Markt mehr: "Bei der Ausstellung werden zwar ähnlich wie bei EV Angaben zum Unternehmen geprüft, vom Browser wird jedoch kein Unterschied zu DV-Zertifikaten angezeigt." D.h. mehr Arbeit für den Antragsteller, aber keine Verbesserung für den Nutzer gegenüber den simplen DV-Zertifikaten.
Aktivitäten zum Schutz gegen unautorisierte (gefälschte) oder ungültige Zertifikate
Diese Verschlüsselungen schützen aber nur dann vor dem Abgehört-Werden, wenn 2 Dinge sichergestellt sind:
Erstens muss der Benutzer eine Warnung bekommen wenn die Verbindung nicht ganz sicher ist
Zweitens muss der Benutzer mit dieser Warnung was anfangen können und nicht einfach auf OK klicken
Um den ersten Punkt zu erreichen sieht das Konzept der Zertifikate vor, dass eine Certificate Authority ein Zertifikat "devalidieren" kann.
Gleich zu Beginn der Einführung der Certificate Authorities wurden dafür CRLs (Certificate Revocation Lists) konzipiert. In dieser öffentlich verfügbaren Liste soll eine CA alle aus irgendwelchen Gründen nicht mehr gültigen Zertifikate eintragen. Diese Liste wächst natürlich mit den Jahren und ist daher auf die Dauer nicht praktikabel.
Darum wurde OCSP eingeführt, dies sind Server, bei denen die Gültigkeit eines einzelnen Zertifikats angefragt werden kann. Dies sollten die Webbrowser natürlich immer tun bevor sie eine HTTPS-Seite öffnen. Leider hat sich herausgestellt, dass die OCSP-Server oft nicht (oder nicht schnell genug) antworten. Dann wäre die Website nicht mehr erreichbar. Um das zu verhindern öffnen die Webbrowser typischerweise die Website trotzdem, was das Verfahren absurd macht.
Certificate Pinning, HPKP (HTTP Public Key Pinning), Certificate Transparency (CT), HTTP Strict Transport Security (HSTS) und Certificate Authority Authorisation (CAA)
Certificate Pinning ist ein Verfahren, bei dem ein Web-Client, d.h. eine Smartphone App oder ein Webbrowser, "weiß", mit welchen Zertifikat sich ein Webserver melden sollte und bei einem gültigen, aber gefälschten Zertifikat Alarm gibt. Banken verwenden so etwas (hoffentlich) bei ihren Smartphone Apps, Google hat dies im Chrome-Browser für die Google Webseiten implementiert und auf diese Weise Angriffe entdeckt, bei denen staatliche Stellen CAs aufgefordert hatten, falsche (aber formal gültige) Google-Zertifikate auszustellen. Das HPKP-Protokoll sollte dieses Verfahren generalisieren, aber das ist nicht so einfach: I'm giving up on HPKP, weil dies auch dazu führen kann, dass die eigene Website gar nicht mehr erreichbar ist.
Jan. 2013:
Hier zur Implementierung von Google im Chrome-Browser: "google detected a non-authorized certificate for the google.com domain. After investigations, it was confirmed that Turktrust Inc incorrectly created two subsidiary certificate authorities: *.EGO.GOV.TR and e-islam.kktcmerkezbankasi.org. The first one was used to create the fraudulent google.com domain certificate detected by Google Chrome."
Google entdeckt solche gefälschten Zertifikate weil in Chrome das sog. "Certificate Pinning" implementiert ist. Normalerweise prüfen Webbrowser die Echtheit einer HTTPS-Website indem sie in ihrem "Certificate Store" nachschauen, ob das Zertifikat von einer der vielen dort eingetragenen Certificate Authorities ausgestellt wurde. Certificate Pinnning ist schärfer: Google hat in Chrome eingebaut, dass die Google-Websites nur mittels einer Reihe von voreingestellten Zertifikaten erreichbar sind. D.h. sie merken wenn jemand die Google-Zertifikate nachmacht, andere Browser merken es nicht, wenn die nachgemachten Zertifikate von einer der "trusted" Authorities sind, wie hier z.B. Turktrust oder früher DigiNotar oder Trustwave, etc.
Juli 2014:
Regierungsnahe CA in Indien stellte falsche Google-Zertifikate aus. Zum Glück findet Google mittels Certificate Pinning in Chrome heraus, wenn solche Aktionen laufen. Die indische Regierung ist ja leider nicht die einzige, die "regierungsnahe" Certificate Authorities hat, fast jedes Land hat so was.
HPKP, Certificate Transparency und Certificate Authority Authorisation werden in dem Artikel I'm giving up on HPKP ausführlich erklärt. Leider hat sich noch keine Verfahren durchgesetzt, d.h. Man in the Middle Angriffe mittels unautorisierten Zertifikaten sind weiterhin möglich (z.B. wenn ein Staat den Datenverkehr seiner Bürger abhören will und dafür eine Certificate Authority zwingt, falsche Zertifikate, z.B. für Google, Whatsapp oder Facebook auszustellen). Beispiele dafür gibt es weiter unten reichlich.
Zu HPKP muss man sagen, dass es von Google 2017 zurückgezogen wurde. Grund ist, dass es sich nicht durchgesetzt hat, obwohl es auf den ersten Blick eine gute Idee scheint. Aber jedes feste Verknüpfen einer Web-Domaine mit einem bestimmten Zertifikat bietet Möglichkeiten zur Erpressung und ist vor allem ein Problem, wenn der Zertifikatsanbieter überraschend vom Markt verschwindet, was durchaus vorkommt.
Ein weiteres Verfahren ist HTTP Strict Transport Security (HSTS). Die Wikipedia-Seite schreibt dazu: "Die Speicherung der HSTS-Informationen durch den Client lässt sich für ein Tracking von Benutzern ausnutzen. Besonders kritisch wurde in diesem Zusammenhang diskutiert, dass Google Chrome die HSTS-Informationen auch in den für besonderen Datenschutz ausgelegten Inkognito-Modus übernimmt. Webserver sollten HSTS dennoch aktivieren, da, unabhängig vom Datenschutzrisiko auf der Browserseite, die Kommunikation durch HSTS sicherer wird, da Daten nicht unverschlüsselt übertragen werden. Auch kann eine zwingend erforderliche SSL/TLS-Verbindung helfen, einen Man-in-the-Middle-Angriff leichter zu erkennen - auch wenn es diesen nicht ausschließen kann".
Forscher der Universität Amsterdam haben ein wissenschaftliches Papier erstelllt, das die grundsätzliche Problematik behandelt:
Certificate Authority Collapse: Regulating Systemic Vulnerabilities in the HTTPS Value Chain. Anlass ist, dass die EU plant, eine strengere Regulierung einzuführen. Unklar ist aber, wie so etwas konkret aussehen könnte, daher dieses umfangreiche Diskussionspapier dazu (PDF, 31 Seiten).
Angriffe, Kompromitierungen, Schlampereien und mehr oder weniger freiwillige Kooperation mit Regierungen von 2011 bis 2018
Aug. 2011: Der Iran hackt DigiNotar
Der Iran hat gute Hacker in seinen Diensten: Sie haben es geschafft, sich falsche Google SSL-Zertifikate auszustellen und zwar durch Eindringen in eine niederländische Certificate authority (CA) die es mit der Sicherheit nicht sehr genau zu nehmen scheint. Damit konnten die irakische Regierung die SSL-verschlüsselten Email der Gmail-Benutzer lesen, ohne dass es zu Sicherheitswarnungen kam.
Sept. 2011:
Mit einem Einbruch bei die Certificate authority (CA) DigiNotar eine der Kernsäulen der Internetsicherheit, nämlich die SSL-Server Zertifikate und deren Integrität angeknackst worden. Die einzige gute Nachricht ist, dass es irgendwann dann doch entdeckt wurde (ganz langsam) und dass die für diesen Fall vorgesehenen Mechanismen wie Devalidieren von Zertifikaten jetzt eingesetzt werden. Anderseits hätte das eigentlich mehr oder weniger automatisch passieren sollen und nicht erst durch Code-Änderungen in den Browsern und Sicherheitsupdates von Microsoft. Das heißt nämlich dass nur diejenigen in den Genuss der neuen Sicherheit kommen, die ihre Geräte aktualisieren, und Konzepte wie CRLs und OCSP sollten eigentlich ohne Software-Aktualisierung greifen.
Bislang wurde das PKIoverheid-Stammzertifikat jedoch noch nicht zurückgezogen, weil dies sonst zu Ausfällen bei der Kommunikation von Computersystemen führen könne, die auf verschlüsselte Verbindungen angewiesen sind.
D.h. die Regierung hat eine sehr problematische Entscheidung getroffen: Sie hat abgewogen zwischen der Nicht-Verfügbarkeit des Zugangs zu diesem Websites (beim Sperren der Zertifikate) und auf der anderen Seite den Verletzungen der Vertraulichkeit, d.h. dem Abhören der Internetverbindungen durch die iranische Regierung (die bei Nicht-Sperren der Zertifikate weiter gegeben ist. Die niederländische Regierung hat sich gegen die iranischen Bürger entschieden und das Abhören einige weitere Monate ermöglicht. Diese Problematik wird ausführlich diskutiert in Certificate Authority Collapse: Regulating Systemic Vulnerabilities in the HTTPS Value Chain (PDF, 31 Seiten).
D.h. so einfach wie in der Theorie ist das Alles gar nicht. In der Praxis haben wir dann die üblichen Probleme: Kritische Infrastruktur war unzureichend geschützt. Der Angreifer behauptet übrigens, noch in 4 Zertifizierungsstellen Zugriff zu haben.
Okt. 2011:
Weitere Anzeichen für Einbrüche bei Zertifikatsherausgebern
Es wird spekuliert, ob weitere CAs gehackt worden sind: Weitere Anzeichen für Einbrüche bei Zertifikatsherausgebern? Zitat: "Das sind also mindestens fünf CAs, die innerhalb von nur 4 Monaten geknackt wurden, um missbräuchlich falsche Zertifikate auszustellen. Und diese Zahl ist nur eine untere Grenze. In der großen Mehrzahl der Fälle – insgesamt über 900.000 Mal – zog es der Herausgeber der CRL vor, das Begründungsfeld leer zu lassen."
Das Problem sind dabei die CAs, denen Browser automatisch vertrauen. Dies ist die Position, die jeder Zertifikatsvertreiber natürlich sucht, denn dadurch sind seine Zertifikate für alle Websites geeignet ohne die Besucher mit einer Warnung zu verschrecken. Ein Autor der Electronic Frontier Foundation spekuliert, dass es vielleicht viel mehr solche Angriffe gibt. Der Artikel berichtet, dass bei einer Auswertung von Certificate Revocation Lists (CRLs) eine Liste von 14 kompromitierten CAs herausgekommen ist, davon 4 seit Juni 2011). Diese Schwachstelle der CAs stellt ein erhebliches Problem für die Sicherheit von SSL und TLS dar.
Dez. 2011:
Ziemlich peinlich: Dutch SSL certificate provider Gemnet investigates website compromise: According to Webwereld, the hacker was able to break into gemnet.nl through a phpMyAdmin installation that wasn't password-protected. PhpMyAdmin is a popular software utility that facilitates the administration of MySQL databases through a Web interface. - Wenn das nicht grob fahrlässig ist, dann weiß ich es nicht. - Update: eine Presseerklärung von Globalsign sagt später, dass nur die Website gehackt worden sei.
Feb. 2012:
Weitere Meldungen zum Thema Certfication Agencies (CA)
Ein Spezialist vom bundesdeutschen BSI äußert sich zu den Zertifikatsproblemen in den Niederlanden: Der Diginotar-SSL-Gau und seine Folgen. Er bestätigt, dass es eben nicht so einfach ist, einfach Zertifikate auf die Sperrliste zu setzen, denn dann funktioniert eben alles mögliche nicht mehr. Der Artikel berichtet auch über einen Zusammenschluss der Zertifikatsanbieter CAB-Forum, der strengere Regeln aufstellt, die Qualitätskriterien für solche Anbieter festlegen sollen.
Der Artikel erklärt (mehr oder weniger klar) dass die Firma Trustwave einem Kunden die Möglichkeit gegeben hat, sich selbst Zertifikate auszustellen, die auf für fremde Websites gültig sind (z.B. Gmail, Facebook und Hotmail). Ziel des Unternehmens war es, den Datenverkehr ihrer Mitarbeiter auch dann überwachen zu können wenn diese per HTTPS auf diese Dienste zugreifen. D.h. das Unternehmen hat den Mitarbeitern vorgegaukelt, sie wären direkt mit dem Gmail oder Facebook verbunden. Gerechtfertigt hat die Firma (und Trustwave) dies damit, dass sie im Rahmen von DLP (Data Leak Prevention) überwachen wollen, ob die Mitarbeiter vertrauliche Daten ins Web laden. Um DLP legal einsetzen zu können muss ein Unternehmen sich "nur" mit dem Betriebsrat einigen und dann ist es sehr wohl möglich, den PC des Mitarbeiters mit einer entsprechenden Software zu versehen, die prüft ob jemand gewisse Arten von Daten, z.B. Kreditkarten, irgendwo hin lädt. Ob ein Betriebsrat diesem Ansinnen zustimmt wird sehr stark von den Umständen abhängen. Wenn das Unternehmen begründen kann, dass dies für die Zukunft des Unternehmens essentiell ist (z.B. bei einer Bank oder in einem Hochsicherheitsbereich), so wird ein Betriebsrat solchen Verfahren durchaus zustimmen und eine Mitwirkung bei der Datennutzung im konkreten Verdachtsfall verlangen. Außerdem ist es für die Erreichung des Zieles durchaus angemessen, dass die Mitarbeiter wissen, dass ihnen über die Schulter geschaut wird.
Trustwave hat jetzt erklärt, dass sie solche Blanko-Zertifikate nicht mehr ausstellen werden, allerdings sei dies durchaus übliche Praxis in der Industrie. D.h. das ganze System der HTTPS-Zertifikate scheint gründlich verrottet zu sein.
März 2012:
Heise.de berichtet, dass ein Trojaner namens Mediyes in Deutschland kursiert, der mit einem gültigen privaten Schlüssel der Schweizer Conpavi AG signiert wurde. Heise schreibt:
Mediyes ist kein Einzelfall. Die Antivirenhersteller stoßen immer häufer auf Malware, die mit einem gültigen Zertifikat signiert wurde. So hat etwa F-Secure vor geraumer Zeit bekannt gegeben, insgesamt 24.000 Exemplare digital signierter Malware identifiziert zu haben. Das prominenteste Beispiel hierfür ist Stuxnet, das für einen gezielten Angriff auf eine Urananreicherungsanlage im Iran entwickelt wurde.
Und in 2012 wird bekannt, dass es bei dem recht renomierten DNS-Betreiber und Zertifikats-Anbieter VeriSign in 2010 zu Einbrüchen kam, die aber dem Vorstand damals verschwiegen wurden, daher jetzt nachträglich eine Meldung an die Börsenaufsicht.
Nov. 2012: One year after DigiNotar breach, Fox-IT details extent of compromise: Die externe Untersuchung zum Einbruch bei Diginotar die zum Ende des Unternehmens führte. Sehr spannend: Wie der Angriff auf Diginotar im Detail ablief, wie er intern entdeckt wurde
(durch einen Check der Verwaltungsunterlagen gegen die PKI), und wie dann die Man-in-the-Middle Angriffe im Iran entdeckt wurde (weil Chrome
Certificate Pinning macht). Lessons learned für das System der SSL-Zertifikate.
Feb. 2013:
Heise.de berichtet, dass Zertifikatsherausgeber DigiCert offenbar am 19. November 2012 ein gültiges Zertifikat für das Signieren von ausführbaren Programmen für die 2011 aufgelöste Firma "NS Auto" ausgestellt hat. Damit wurde dann ein Bankentrojaner signiert, damit seine Installation nicht zu einer Warnung führt.
Feb. 2014:
arstechnica berichtet über Phony SSL certificates impersonating Google, Facebook, and iTunes. Dabei werden SSL-Zertifikate genutzt, die zwar auf die jeweiligen Besitzer der Domain ausgestellt sind, aber "self-signed". D.h. die gängigen Browser bringen alle eine Warnung, leider aber die meisten Handys und Handy-Apps nicht:
An October 2012 academic study, for instance, uncovered critical defects in a wide-range of applications running on computers and smartphones—some from banks such as Chase and services such as AOL—that failed to check the validity of SSL certificates. A separate study found that Android apps installed on as many as 185 million devices exposed end users' online banking and social networking credentials as well as e-mail and instant-messaging content because the programs used inadequate encryption protections. A more recent report from security firm IOActive uncovered similar weaknesses in apps written for Apple's iOS platform.
"Online banking apps for mobile devices are tempting targets for man-in-the-middle attacks, as SSL certificate validation is far from trivial, and mobile applications often fall short of the standard of validation performed by web browsers," the Netcraft researchers wrote in Wednesday's report. "40 percent of iOS-based banking apps tested by IO Active are vulnerable to such attacks because they fail to validate the authenticity of SSL certificates presented by the server. 41 percent of selected Android apps were found to be vulnerable in manual tests by Leibniz University of Hannover and Philipps University of Marburg in Germany."
März 2018:
Die lange Pause in diesen Berichten bedeutet nicht, dass nicht passiert sei, aber irgendwie wiederholt sich das alles immer wieder. :-(
Trustico und DigiCert: Widerruf von 23.000 SSL-/TLS-Zertifikaten. 23.000 über den Reseller Trustico verkaufte SSL-/TLS-Zertifikate von GeoTrust, RapidSSL, Symantec und Thawte müssen widerrufen werden. Das ganze ist etwas bizarr: In einer Mail wies Trustico den anderen Reseller DigiCert ohne Begründung dazu an, 50.000 Zertifikate zu widerrufen.
DigiCert lehnte das Anliegen ab und wies darauf hin, dass das nur geschehen kann, wenn beispielsweise die privaten Schlüssel der Zertifikate kompromittiert wären. Als Antwort darauf soll Trustico die privaten Schlüssel von 23.000 Zertifikate unverschlüsselt per Mail an DigiCert geschickt haben – einige Schlüssel tauchen bereits an anderen Stellen im Internet auf.
Nach so einem Widerruf ist bei den Webserver-Betreibern Panik angesagt, denn wenn Zertifikate als Vorsichtsmaßnahme innerhalb von 24 Stunden für ungültig erklärt werden so müssen die Betreiber in diesen 24 Stunden neue beantragen und installieren. Dies kann bei einem Betreiber wie einer Bank, die viele Webserver im Netz hat, zu etwas Hektik führen. Angeblich sind das Machtkämpfe auf dem Rücken der Website-Betreiber.