Freitag, 17. Juli 2015
[*]

Certificate Pinning funktioniert nicht

, 14:13

Wenn Webseiten verschlüsselte Verbindungen benutzen (https), dann wird zu Beginn des Kontakts dem Browser vom Server ein Zertifikat gezeigt, mit dem der Server versichert, dass er auch der richtige Server ist (und nicht irgendein Angreifer, der auf der Leitung steht). Die Ausstellung und Überprüfung dieser Zertifikate folgt einem hierarchischen Ansatz („X.509“), und die Liste der als vertrauenswürdig betrachteten Herausgeber sieht gar nicht so vertrauenswürdig aus, wie man sich das wünschen würde (siehe hier). Es gab immer wieder Fälle, in denen sehr neugierige Menschen sich von einer der zwielichtigeren Zertifizierungsstellen der Liste ein Zertifikat für eine bekannte Webseite organisiert haben. Sie konnten dann alles mithören ohne dass den Benutzern aufgefallen wäre, dass sie nicht direkt mit z.B. Google reden.

Eine Gegenmaßnahme für dieses Problem ist das Certificate Pinning: der Browser merkt sich für alle Webseiten, mit denen er sich schon einmal verbunden hat, das Zertifikat und schlägt Alarm, wenn ihm später ein anderes vorgezeigt wird (funktioniert natürlich nur unter der Annahme, dass die Verbindung nicht schon von Anfang an infiltriert ist, aber das nehmen wir einfach mal an).

Genau zu diesem Zweck habe ich jetzt ein paar Monate lang das Firefox-Plugin Certificate Patrol benutzt. Das Plugin funktioniert auch super, aber es bringt trotzdem keinen Sicherheitsgewinn.

Das liegt daran, dass viele größere Webseiten ihre Daten über Content Delivery Networks ausliefern, und dass die es mit den Zertifikaten nicht so genau nehmen: die über die ganze Welt verteilten Server, die Dateien für dieselbe Webseite ausliefern, scheinen oft jeder ein anderes Zertifikat zu benutzen.

Certificate Patrol bietet sogar noch die Möglichkeit, nicht schon bei einem bloßen Zertifikatswechsel zu warnen sondern erst dann, wenn das geänderte Zertifikat auch von einem anderen Herausgeber stammt, aber selbst diese geringe Integritätsbedingung halten viele CDNs nicht ein.

Wenn ich also mit Certificate Pinning im Web unterwegs bin, muss ich ununterbrochen Warnmeldungen lesen und wegklicken, lesen und wegklicken, lesen und wegklicken, und irgendwann nur noch wegklicken…

Ich werde deshalb Certificate Patrol wieder deinstallieren, denn wenn es mich irgendwann mal vor einem tatsächlichen Lauschangriff warnen würde, würde ich es wahrscheinlich nicht einmal lesen. 🙁

Donnerstag, 29. August 2013
[*]

CloudFlare, fix your DNS

, 13:21

Ich habe den Feed von Very Important Pixels abonniert. Eine Menge andere Leute haben das auch getan — offensichtlich so viele, dass die Macher sich entschlossen haben, ein Content Delivery Network vorzuschalten. Vielleicht hat es auch andere Gründe, jedenfalls läuft die Seite über CloudFlare. Das ist durch eine DNS-Abfrage leicht nachzuprüfen:

dentaku@nyx:~$ host www.veryimportantpixels.com
www.veryimportantpixels.com is an alias for
    www.veryimportantpixels.com.cdn.cloudflare.net.
www.veryimportantpixels.com.cdn.cloudflare.net is an alias for
    cf-protected-www.veryimportantpixels.com.cdn.cloudflare.net.
cf-protected-www.veryimportantpixels.com.cdn.cloudflare.net has address 108.162.199.82
cf-protected-www.veryimportantpixels.com.cdn.cloudflare.net has address 108.162.198.82
dentaku@nyx:~$

Leider scheint CloudFlare seinen DNS-Server nicht ganz im Griff zu haben, deshalb sehe ich jetzt in meinem Syslog bei jeder Aktualisierung meines Feedreaders (also vier mal in der Stunde) mehrere solche Einträge:

nyx named[4191]: DNS format error from 213.133.99.99#53
    resolving www.veryimportantpixels.com.cdn.cloudflare.net/AAAA
    for client 127.0.0.1#60013:
    unrelated AAAA cf-protected-www.veryimportantpixels.com.cdn.cloudflare.net
    in cf-protected.veryimportantpixels.com.cdn.cloudflare.net authority section

Das nervt etwas.