Schlagwort-Archive: RFC7469

Erster bekannter Missbrauch eines Let’s Encrypt Zertifikats

Dennis Schirrmacher berichtet in seinem heise-Artikel „Erste Malvertising-Kampagne mit Let’s-Encrypt-Zertifikat“ über die missbräuchliche Verwendung eines Let’s Encrypt Zertifikats.

Laut dem Artikel ist es Online-Gaunern gelungen, eine Subdomain für eine legitime Domain einzurichten und für diese ein Let’s Encrypt Zertifikat zu beantragen. Mit Hilfe der legitimen Domain und des vertrauenswürdigen Zertifikats wird Besuchern der Webseite Schadcode untergeschoben. Im konkreten Fall wird ein Online-Banking-Trojaner auf den Computern der Opfer installiert.

Die missbräuchliche Nutzung ist kein spezielles Problem von Let’s Encrypt. Es handelt sich vielmehr um ein generelles Designproblem der öffentlichen TLS/SSL-Infrastruktur, welches ich bereits in der Einleitung von „Certificate Pinning mit NGINX“ beschrieben habe.

Let’s Encrypt versucht den Missbrauch durch den Einsatz kurzlebiger Zertifikate einzuschränken. Dieser Versuch läuft meiner Ansicht nach jedoch weitgehend ins Leere. Denn auch Online-Gauner können die Erneuerung der ergaunerten Zertifikate mit dem Let’s Encrypt Client automatisieren.

Einen deutlich effektiveren Schutz gegen die genannte Art von Missbrauch bieten Verfahren wie „Public Key Pinning Extension for HTTP“[1. RFC 7469 – Public Key Pinning Extension for HTTP] [2. HTTP Public Key Pinning – Wikipedia (de)] und „HTTP Strict Transport Security (HSTS)“[3. RFC 6796 – HTTP Strict Transport Security (HSTS)] [4. HTTP Strict Transport Security – Wikipedia (de)]. Speziell mit Hilfe des Certificate Pinning kann ein Browser erkennen, ob ein TLS/SSL-Zertifikat zur besuchten Domain gehört oder nicht. Nähere Informationen dazu und wie das Certificate Pinning für den Webserver NGINX konfiguriert werden kann, finden sich im Artikel „Certificate Pinning mit NGINX“. Viel Spaß beim Lesen.

Pinning-Test im Firefox bei lokaler Root-CA erzwingen

In Certificate Pinning mit NGINX habe ich das „Public Key Pinning for HTTP“[1. RFC 7469] und dessen Einrichtung mit dem Webserver NGINX[2. Ubuntuusers.de-Wiki-Artikel zu NGINX] beschrieben. Im vorliegenden Artikel beschreibe ich, wie man den Pinning-Test im Firefox auch bei Installation einer lokalen Root-CA aktiviert.

Schmidt schreibt in seinem Artikel[3. Schmidt, Jürgen: Festgenagelte Zertifikate: TLS wird sicherer durch Certificate Pinning, in: c’t magazin für computer technik, Nr. 23, 17.10.2015, Seite 120-121], dass Firefox in der Standardeinstellung sämtliche Pinning-Tests deaktiviert, wenn nachträglich ein Root-CA-Zertifikat auf dem System installiert wurde. Um die Pinning-Tests auch in diesem Fall zu erzwingen ist der unten genannte Parameter auf der Seite „about:config“ auf den Wert „2“ zu setzen.

security.cert_pinning.enforcement_level

Dieser Parameter kann die folgenden Werte annehmen:

  • 0 -> Schaltet die Pin-Prüfung komplett ab.
  • 1 -> Standardwert; Führt Pin-Prüfung durch, solange keine lokale Root-CA im Spiel ist.
  • 2 -> Strict; Erzwingt die Pin-Prüfung in jedem Fall.

Update vom 08.12.2015
Wie ich bei meinen Tests am vergangenen Wochenende herausgefunden habe, muss noch ein weiterer Parameter in der Firefox-Konfiguration angepasst werden, um das Public-Key-Pinning im Firefox bei Existenz eines Root CA Zertifikats zu aktivieren.

security.cert_pinning.process_headers_from_non_builtin_roots;true

Wir oben genannter Parameter auf „true“ gesetzt, führt der Firefox den Pinning Test auch durch, wenn zusätzliche Root-Zertifikate auf dem System installiert wurden.

Einen ausführlichen Bericht zum Thema findet ihr auch in „Certificate_Pinning_mit_NGINX (PDF)„.