|
|||||
Home Themenübersicht / Sitemap Notizen Webmaster | |||||
HTTPS-Herausforderungen und Certificate Authorities (CA)Philipp Schaumann - Letzte Aktualisierung: Mai 2018 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.2) 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-ZertifikateIn 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 HTTPSBei 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 AppsDas 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. Hier sind Links zu Artikeln mit den Details dazu, z.B. The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software und Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security. Der erste der Artikel gibt sogar Code-Beispiele für App-Entwickler, die zeigen, wie es richtig und wie es falsch ist. Die Tipps für Entwickler finden sich auch in Your app shouldn't suffer SSL's problems. 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 jedenEine 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:
|
|||||
Lösungsvorschläge und -implementierungen
Einfache HTTPS-Implementierung für alle durch kostenlose, einfache Basis-ZertifikateIn 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 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 ZertifikateDiese Verschlüsselungen schützen aber nur dann vor dem Abgehört-Werden, wenn 2 Dinge sichergestellt sind:
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: 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: 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). Certificate Transparency, wird in dem Artikel von einem Google Mitarbeiter erklärt und ebenfalls in Security Collapse in the HTTPS Market Das heißt, das Problem ist nicht ganz gelöst. :-(
|
|||||
Angriffe, Kompromitierungen, Schlampereien und mehr oder weniger freiwillige Kooperation mit Regierungen von 2011 bis 2018
Aug. 2011: Der Iran hackt DigiNotarDer 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. Weitere sehr anschauliche Artikel dazu von f-secure DigiNotar Hacked by Black.Spook and Iranian Hackers und Sophos Google blacklists 247 certificates. Is it related to DigiNotar hacking incident?
Sept. 2011: Wie kritisch das ganze geworden ist zeigt dieser Artikel: Niederländische Regierung übernimmt Kontrolle über DigiNotar. Bezeichnend ist diese Stellungnahme:
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: 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:
Feb. 2012:
Trustwave
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:
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.
Sept. 2012:
Nov. 2012: Dann, Nov. 2012, ein 100-seitiger Bericht durch die Sicherheitsexperten von Fox-IT Black Tulip - Report of the investigation into the DigiNotar Certificate Authority breach. Für DigiNotar hatte der Vorfall bereits Konsequenzen: Das Unternehmen wurde kurz nach dem GAU liquidiert.
Dez. 2012:
Feb. 2013:
Sept. 2013:
Dez. 2013:
Feb. 2014:
März 2018: 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. Ebenfalls im März wird berichtet, dass die Webseite des SSL-Resellers Trustico für Root-Attacke anfällig gewesen sei.
Philipp Schaumann, http://sicherheitskultur.at/
Copyright-Hinweis:
|