GPN17:Vertrauen ist gut, Kontrolle ist besser.

aus dem Wiki des Entropia e.V., CCC Karlsruhe
Version vom 31. Mai 2017, 20:01 Uhr von JackMcCrack (Diskussion | Beiträge) (Video)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Ein Vortrag von Andreas Sperber auf der GPN17.

Im August 2011 berich­tet ein irani­scher In­ternetnutzer von ei­ner Brow­ser-War­nung, wenn er sich zu sei­nem Gmail-Konto einloggen will. Der Nutzer des Chro­me-Browsers wendet sich damit in ei­nem Forum direkt an Goog­le und fragt, ob es sich um ei­nen Man-in-the-Middle-Angriff auf die Verschlüsselung handeln könnte. Goog­le un­tersucht dar­aufhin die Si­tuati­on und bestätigt sei­ne Vermu­tung: es gab Angriffe auf die Verschlüsselung der Kommunikati­on, wovon primär In­ternetnutzer im Iran betroffen wa­ren. Die Zertifizierungs­stel­le DigiNo­tar habe un­ter an­de­rem für goog­le.com nicht autorisier­te Zertifikate aus­ge­stellt, die von Browsern an­stands­los akzep­tiert wur­den. Allein der kurz vor dem Vorfall veröff­entlich­ten Si­cherheits­funkti­on des Chro­me-Browsers sei es zu ver­danken, dass das missbräuch­lich verwende­te Zertifikat bemerkt wurde. Die neue Si­cherheits­funkti­on prüfe für den Goog­le E-Mail-Dienst Gmail nicht nur, ob das Zertifikat gültig ist, sondern auch ob es von ei­ner autorisier­ten Zertifizierungs­stel­le aus­ge­stellt wurde. In Chro­me und an­de­ren Browsern wur­den sofort alle Zertifikate ge­sperrt, die von DigiNo­tar aus­ge­stellt wur­den. Die Zertifizierungs­stel­le, die seit Juli 2011 von den nicht autorisier­ten Zertifika­ten für Domains von Goog­le, dem CIA, dem Mossad, dem MI6 und an­de­ren wusste, wurde unter die Aufsicht nieder­ländi­scher Behörden gestellt und es wurde ein Ermittlungs­verfah­ren ein­ge­leitet.

Kommt ein Angreifer in den Besitz ei­nes nicht autorisier­ten aber gültigen Zertifikats, sind verschlüsselte Ver­bindun­gen nicht mehr si­cher. Der Angreifer würde sich mit ei­nem Man-in-the-Middle-Angriff zwi­schen zwei Kommunikati­ons­partner set­zen und das gültige Zertifikat präsentie­ren. Dieses wird akzep­tiert, da der Client Zertifika­ten der nicht mehr vertrau­enswürdigen Zertifizierungs­stel­le vertraut. Die Kommunikati­on wird abgehört.

Das Pro­blem mit Zertifika­ten ist nicht neu. Aus diesem Grund wur­den in der Vergan­genheit meh­re­re Möglichkei­ten zur Ab­si­cherung gegen fal­sche Zertifikate vor­ge­schla­gen. Beispiele sind Certificate Transparency, DNS-based Authentication of Named Entities oder auch HTTP Public Key Pinning. Certificate Transparency ist zudem topaktuell, da der Internetgigant Google dieses Verfahren für https-Verbindungen in seinem Chrome Browser im Oktober 2017 verpflichtend einführen wird.

Der Vortrag gibt einen kurzen Überblick über Public Key Infrastrukturen und Zertifikate und stellt Lösungsansätze für das beschriebene Vertrauensproblem vor.

Links