Skip to content

TLS-Bingo -- Wer bietet mehr?

Ich hatte heute den verwegenen Plan und wollte die Webseite des sächsischen Landtages per HTTPS aufrufen. Der Browser stoppte mich und zeigte eine schöne Fehlermeldung:

Edas
Fehlermeldung zum Zertifikat von edas.landtag.sachsen.de

Also dem Zertifikat traut der Browser nicht. Außerdem fehlen dem weitere Bestandteile. Das Zertifikat ist eigentlich für eine andere Domain und schon längst abgelaufen.

Hier frage ich mich, ob jemand schon mal eine Liste von Zertifikatsfehlern gesehen hat, die länger ist, als die obige. :-)

Securityheaders.io

Viele von euch kennen vielleicht die Seite SSLLabs.com, bei der sich die Einstellungen bezüglich TLS testen lassen. Wer wissen möchte, wie gut die Daten auf einer verschlüsselten Webseite geschützt sind, kann den Namen eingeben und SSLabs führt dann verschiedene Tests durch. Nach Beendigung gibt die Seite eine Einschätzung aus.

SSLLabs für kubieziel.de
SSL-Einstellungen für kubieziel.de im Dezember 2015

Nun ist TLS nicht die einzige Baustelle, was die Sicherheit im Web betrifft. Es gibt zahlreiche Schwachstellen, die ausgenutzt werden. Für einige dieser Schwachstellen wurden neue HTTP-Header eingeführt.

So gibt es beispielsweise einen, der dem Browser auffordert, die Seite ausschließlich über HTTPS aufzusuchen (HSTS). Die meisten aktuellen Browser unterstützen den Header. Daneben gibt es Header, die Schutz vor so genanntem Cross-Site-Scripting (XSS) bieten sollen sowie weitere mehr.

Die Seite securityheaders.io hat es sich zum Ziel gemacht, die Header der Webseiten zu testen und ein ähnliches Rating wie SSLLabs auszugeben. Auch hier erhaltet ihr einen schnellen Überblick über die Sicherungsmaßnahmen. Allerdings habe ich Einstellungen gefunden, wo das Rating aus meiner Sicht nicht gerechtfertigt ist. Die Seite hatte HSTS gesetzt und erhielt trotzdem nur ein sehr schlechtes Rating. Laut Aussage der Entwickler sind die aber dabei, das zu ändern. Testet die Seite doch mal aus!

Meine Seite hat derzeit folgendes Rating:

Bewertung der HTTP-Header bei kubieziel.de
Bewertung der HTTP-Header bei kubieziel.de

Wie ihr seht, fehlt derzeit CSP und das Key Pinning. Bei letzterem lässt sich aus meiner Sicht viel falsch machen. Da will ich erstmal noch ein paar Gedanken reinstecken, bevor ich den setze. Und CSP muss ich testen, inwieweit das mit dem Blog Probleme gibt. Wenn das passiert ist, steht einem A+ nichts mehr im Wege. :-)

Neues TLS-Zertifikat

Der Webserver hat seit heute ein neues Zertifikat. Ich bin jetzt von CAcert auf Let’s Encrypt umgestiegen. Bei den Übernauten ist die Einrichtung sehr einfach. Nachdem die Befehle uberspace-letsencrypt, letsencrypt certonly und uberspace-prepare-certificate eingegeben wurden, war alles fertig.

Wenn ihr das Zertifikat prüfen wollt, hier ist der SHA-256-Hash:

B8:8A:B3:34:0E:5F:97:6A:88:F0:A7:E7:91:73:F4:50:42:29:0A:73:07:54:68:2D:96:EB:36:29:BB:FC:58:A8

Browser gegen LogJam absichern

Der macht eine Meldung über die LogJam-Schwachstelle die Runde. Ein Besuch der Webseite WeakDH.org offenbarte auch bei meinen Browser-Einstellungen Schwächen. Doch wie sichere ich den gegen die Attacke?

Im Firefox ist das recht einfach: In die Adresszeile einfach about:config eingeben und dann in den Konfigurationseinstellungen nach dem Wert .dhe suchen. Der Punkt vor dhe ist wichtig, dass nur die relevanten Algorithmen gefunden werden. Alle Werte (je nach Version sind das zwei oder mehr) werden auf false gesetzt. WeakDH.org sollte nun keine Warnung mehr anzeigen.

Einstellungen im Tor Browser Bundle

Im Chrome oder Chromium gibt es keine Möglichkeit, die Einstellung über ein Menü zu machen. Der beste Weg, den ich fand, ist, zunächst die Cipher-Suite-Detail-Seite zu besuchen. Dort findet ihr eine Tabelle mit Algorithmen, die euer Browser unterstützt. In der Spalte Spec stehen Zahlen-/Buchstaben-Kombinationen. So findet sich bei mir beispielsweise der Eintrag: (00,0a). Sucht nun nach allen Einträgen, bei denen der Cipher-Suite-Name mit DHE (nicht ECHDE) beginnt und entfernt die Klammern und das Komma von der Spec. Nun fügt ihr noch ein 0x an den Anfang. Im obigen Beispiel wird also aus (00,0a) ein 0x000a. Diese unerwünschten Algorithmen werden als Option dem Chrome oder Chromium übergeben: google-chrome --cipher-suite-blacklist=0x009e,0x0033,0x0032,0x0039,0x0004,0x0005 ist das bei meinem Browser.

Wie sieht es bei anderen Browsern aus? Meines Wissens kann man den Internet Explorer nicht so detailliert steuern. Ich freue mich über Hinweise und nehme die gern mit in den Beitrag auf. Schließlich sollte das Ergebnis der Webseite dann wie unten aussehen. :-)

Keine Angriffsmöglichkeit durch LogJam

Lenovo-Laptops mit SuperFish-AdWare

Die aktuellen Nachrichten über Wanzen in Festplatten oder geknackte SIM-Karten hören sich auf der einen Seite sehr bedrohlich an, auf der anderen Seite werden viele dies abtun, als Verschwörungstheorie oder »Betrifft-mich-nicht«. Doch dann war von Barbies zu lesen, die alles mithören und ins Internet übertragen und Samsung warnt, vor seinen Fernsehgeräten nichts Privates zu erzählen. Im letzteren Fall werden die Daten im Klartext übertragen und damit kann jeder mithören, was vor dem gerät erzählt wird. Der große Lauschangriff mal ganz anders.

Ansicht des Zertifikats im Zertifikatsmanager
Detailansicht des Zertifikats von Chris Palmer (@fugueish)
Lenovo reiht sich nun ebenfalls in die Liste der Hersteller ein, die offensichtlich wenig auf die Privatsphäre der Käufer geben. Verschiedene Medien (The Next Web, Forbes, Heise, ZEIT Online, Golem u.a.) meldeten, dass Lenovo auf Laptops die Software SuperFish Visual Discovery vorinstalliert. Dies ist Adware, d. h. sie blendet Werbung auf Webseiten ein. Dies wird dadurch bewerkstelligt, indem ein Schnippsel JavaScript geladen wird und die unerwünschten Inhalte überträgt. Doch damit gaben sich die Hersteller der Software nicht zufrieden. In die vorab installierten und damit vertrauenswürdigen Zertifikate wurde auch ein Zertifikat eingefügt. Immer wenn nun eine verschlüsselte, sichere Webseite besucht wird, kommt das Zertifikat nicht von der ursprünglichen Webseite, sondern von der SuperFish-Software. Damit kann die Software den verschlüsselten Datenverkehr mitlesen und diese Daten auch manipulieren. Dieser so genannte Man-in-the-Middle-Angriff ist eine klassische Angriffstechnologie und dient in der Regel nicht guten Zwecken.
Code zur Installation des Zertifikats
Code, der versucht, das Zertifikat in verschiedenen Browsern zu installieren (via @supersat)

Die EFF beobachtet seit längerem den Status von Zertifikaten mit dem SSL Observatory und meldete, dass sie in dem Datensatz 44.000 dieser SuperFish-Mitm-Zertifikate fanden. Das Bild links zeigt ein wenig Quellcode. Demnach versucht die Software ihr Zertifikat in verschiedene Browser zu importieren. Das erklärt auch, warum u.a. auch Firefox betroffen ist. Denn im Gegensatz zu Google Chrome nutzt dieser nicht die Zertifikatsverwaltung von Windows.

Robert Graham hat neben anderen Forschern das Zertifikat aus der Software extrahiert und in kurzer Zeit das Passwort ermittelt (Das Passwort »komodia« liefert dann auch den Hinweis auf den Komodia SSL Digestor). Wie er schreibt, benötigte er keine Spezialkenntnisse. Ein geschickter Angreifer kann dies ebenfalls tun. Damit lässt sich dann auch für Dritte sämtliche verschlüsselte Kommunikation brechen. Aber der Superfish Software scheint auch der Status fremder Zertifikate egal zu sein. In einer Diskussion auf Hacker News berichtete jemand, dass die Software beliebige (auch ungültige) fremde Zertifikate akzeptiert. Ähnliches geht auch mit fakehost.lenovo.com oder CanIBesuperFished.com. Insgesamt reißt die Software damit ein riesengroßes Loch in die Sicherheit der Rechner. Mich erinnerte das spontan an den Fall von Sony, die auch Malware auf die Rechner installieren.

Was lässt sich nun gegen die Infektion tun? Die Software selbst ist in der Liste der installierten Programme von Windows zu finden und kann dort einfach deinstalliert werden. Allerdings bleiben eine Reihe von Einträgen in der Registry und das Zertifikat noch erhalten. Hier ist dann Handarbeit angesagt. Dazu müsst ihr den certmgr von Windows öffnen und das Zertifikat entfernen. Bei der EFF gibt es eine Schritt-für-Schritt-Anleitung, wie das zu tun ist.

Lenovo hat mittlerweile reagiert und einerseits ein schönes Statement bei Twitter abgegeben:

Daneben gibt es eine Veröffentlichung, die den Vorfall klar als Vulnerability mit hohem Impact benennt. Die Veröffentlichung hat auch eine Liste der Produkte, die betroffen sind.

Verschlüsselung im Thüringer Landtag -- Ein Versuch

Die 5. Wahlperiode des Thüringer Landtages neigt sich dem Ende zu. Einer der letzten Beschlüsse ist die Drucksache 5/7583 mit dem Titel Verschlüsselte Kommunikation ermöglichen und befördern. In der Endfassung enthält der Beschluss die Bitte an die Landesregierung:

  1. zukünftig Wege zu ermöglichen, welche die Vertraulichkeit des Inhalts elektronischer Kommunikation mit öffentlichen Stellen des Landes und der Nutzung ihrer elektronischen lnformationsdienste sowie des Inhalts elektronischer Kommunikation zwischen öffentlichen Stellen des Landes durch Angebote einer sicheren End-to-End-Verschlüsselung (Kryptografie) eröffnen,
  2. die Bürger des Freistaats Thüringen in geeigneter Weise über die Möglichkeiten der Verschlüsselung elektronischer Kommunikation, insbesondere auf den Web-Seiten der Landesregierung, zu informieren.

Der Versuch

Darin steckt der Wunsch, TLS für Webseiten und Ende-zu-Ende-Verschlüsselung vielleicht mit OpenPGP zu machen.

Ich entschied mich, denselben Weg wie Anna Biselli zu gehen. Sie versuchte, verschlüsselt mit einem Abgeordneten zu kommunizieren. Ich besuchte die Webseiten der Fraktionen im Landtag und die der Abgeordneten. Dabei wollte ich jede Seite mit https öffnen und suchte nach einer Möglichkeit für verschlüsselte E-Mail-Kommunikation. Konnte ich beides nicht finden, so schrieb ich die Abgeordneten an. Was kam dabei heraus?

Fraktionen

Die CDU-Fraktion im Landtag bietet keinerlei Unterstützung für SSL/TLS an und es gibt auch keine Möglichkeit zur verschlüsselten E-Mail-Kommunikation.

Die Webseite der SPD-Fraktion begrüßt mich mit der Meldung SSL peer has no certificate for the requested DNS name. Eine verschlüsselte Verbindung zu der Seite ist damit nicht möglich und ich fand auch keinen OpenPGP-Schlüssel auf der Seite.

Die Webseite der FDP-Fraktion scheitert zunächst an den Einstellungen in meinem Browser und sagt Peer attempted old style (potentially vulnerable) handshake. Wenn ich die Einstellungen lockere, so präsentiert die Seite ein Zertifikat, was für die Domain web6.online-now.de ausgestellt ist. Wenn ich dann auch noch dieses akzeptiere, so erhalte ich von der resultierenden Seite die Meldung Die Domain “www.thl-fdp.de” ist nicht über https verfügbar. Die Unterstützung von OpenPGP ist wie bei den anderen Parteien.

Die Webseite der Fraktion der Grünen hat ein Zertifikat, welches seit Ende 2013 abgelaufen ist. Ich hatte den Fakt im Juli 2014 gemeldet. Zum Zeitpunkt des Blogeintrages hat sich an dem ungültigen Zertifikat nichts geändert. Wird dies akzeptiert, so werden die Inhalte der Webseite angezeigt. OpenPGP sucht man jedoch vergeblich.

Einzig die Fraktion der LINKEn unterstützt SSL/TLS vom Start weg und die Servereinstellungen sind sehr gut. Hier wäre nur zu wünschen, dass die Webseite alle Anfragen standardmäßig auf die verschlüsselte Seite umleitet. Die positiven Nachrichten reißen aber noch nicht ab. Denn die Kontaktseite bietet einen OpenPGP-Schlüssel zum Download an und weist den Fingerprint aus. Damit ist die LINKE eindeutig der Spitzenreiter, was verschlüsselte Kommunikation betrifft.

Abgeordnete

Von den knapp 90 Abgeordneten im Landtag gibt es nur zwei, die einen OpenPGP-Schlüssel anbieten:

Beider Webseiten sind auch per HTTPS zu erreichen. Jedoch verwendet die Seite von Dirk Adams ein falsches Zertifikat und die Seite von Katharina König bzw. der Provider blockieren Verbindungen über Tor. Falls ihr also die Seite mit Tor ansurft, kann es sein, dass sich diese nicht öffnet. :-(

Uwe Barth (FDP) nutzt ein Wordpress-Blog als Webseite. Damit kann die Seite auch per HTTPS besucht werden. Die SPD-Abgeordneten David-Christian Eckardt, Uwe Höhn, Birgit Pelke und Claudia Scheerschmidt nutzen das Angebot von Sozinet. Das bietet ebenfalls HTTPS an.

Bei allen anderen Abgeordneten fand ich keine funktionierende Möglichkeit, per HTTPS auf die Seite zuzugreifen. Ebenfalls konnte ich keine Nennung von E-Mail-Verschlüsselung finden. Also schrieb ich E-Mails und fragte nach.

Die Abgeordneten der FDP haben das Wahlkampfmotto Wir sind dann mal weg wohl zu ernst genommen. Denn ich erhielt von keinem der angeschriebenen Abgeordneten eine Antwort.

Die CDU schien sich intern auf eine Antwort geeinigt zu haben. Alle Antworten hatten nahezu denselben Wortlaut und verwiesen darauf, dass der Beschluss eine Aufforderung an die Regierung enthält. Erst wenn diese eine Entscheidung getroffen hat, so werden die Abgeordneten diese umsetzen. Aus den Antworten wurde klar, dass vorher nichts zu erwarten ist.

Von der SPD antworteten einige wenige Abgeordnete. Allerdings treten diese nicht mehr zur Wahl an oder sind unsicher, ob sie wiedergewählt werden. Daher hatte das Thema keine Priorität.

Von den grünen Abgeordneten erhielt ich zwei Antworten. In einem Fall ist eine neue Webseite in Arbeit. Die neue Seite soll dann auch Verschlüsselung unterstützen. Im anderen Fall war die Meinung, dass Verschlüsselung nicht notwendig ist, da alle auf der Seite angebotenen Daten öffentlich sind.

Bei der Linken konnte ich einen interessanten Effekt beobachten. Anfangs erhielt ich von den Abgeordneten individuelle Antworten. Ab einem Zeitpunkt kamen eine Art Standardantworten mit ähnlichem Wortlaut. Ich vermute, dass sie sich intern auf eine Sprachregelung geeinigt haben. Bei den individuellen Antworten gab es Abgeordnete, die klar schrieben, dass sie sich mit dem Thema bisher noch nicht auseinandergesetzt haben und noch nicht wissen, wie sie damit umgehen. In einem Fall erhielt ich eine verschlüsselte E-Mail mit Schlüssel und hätte künftig verschlüsselt kommunizieren können.

Insgesamt gibt es bei den Abgeordneten noch viel zu tun. Natürlich verwiesen viele auf die bevorstehenden Sommerferien und Wahlen. Daher werde ich die Wahlen abwarten und später nochmal bei den Abgeordneten nachfragen. Vielleicht wird Thüringen der Verschlüsselungs-Standort Nr.1. :-)

Wie funktioniert eigentlich Heartbleed

Lest ihr regelmäßig Bugreports oder Meldungen über Schwachstellen bei SSL/TLS? Wie fühlt ihr euch so? Zur Erinnerung:

SSL added and removed here!
Ausschnitt aus einer Folie aus dem MUSCULAR-Programm der NSA

Das heißt, drei Monate in Folge gab es schwere Sicherheitslücken in Software zur Verschlüsselung. Ganz unwillkürlich fühlt man sich an die Folien aus dem NSA-Programm MUSCULAR erinnert.

Die letztgenannte Schwachstelle ist vermutlich die bislang schwerste. Denn damit ist es möglich, den Arbeitsspeicher eines Computers auszulesen. Dies funktioniert sowohl auf der Seite des Servers wie auch beim Clientprogramm. Dazu ist es notwendig, dass das Programm OpenSSL verwendet und eine Erweiterung von SSL namens Heartbeat aktiviert hat. Dies ist beispielsweise bei Android in der Version 4.1.1 der Fall. Mozilla Firefox hingegen nutzt die NSS-Bibliothek und ist nicht betroffen. Die Webserver nutzen hingegen recht oft die OpenSSL-Bibliothek und sind damit betroffen, falls die Version 1.0.1 bis 1.0.1f von OpenSSL verwendet wird. Sollte jemand von euch die Software nutzen, so upgraded auf mindestens 1.0.1g oder deaktiviert Heartbeat in OpenSSL. Gerade letzteres kann man aus meiner Sicht problemlos tun. Denn bisher fand ich keinen sinnvollen Anwendungsfall für Heartbeat.

Doch wie funktioniert diese Lücke eigentlich? Heartbeat (RFC 6520) ist eine Erweiterung für TLS. Ein Teilnehmer einer Verbindung sendet beliebige Daten an den Empfänger. Dieser antwortet mit einer Kopie dieser Daten und zeigt somit, dass die Verbindung noch steht und alles in Ordnung ist. Das Problem dabei ist, dass in einer Anfrage zwei Längenfelder vorhanden sind. Ein Angreifer sendet einfach ein Byte Daten und behauptet, er hätte 64 kB gesendet. OpenSSL liest nun die 64 kB aus dem eigenen Puffer und sendet die Daten zurück an den Angreifer. Der Angreifer kann den Angriff immer und immer wieder starten und erhält so eventuell immer wieder ein neues Stück Arbeitsspeicher (siehe Kommentar von Florian Diesch). Bruce Schneier hat mit seinen Worten vollkommen recht:

Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.
https://www.schneier.com/blog/archives/2014/04/heartbleed.html

Ich hatte in meinem 30C3-Vortrag schon ein OpenSSL-Beispiel reingenommen. Das sollte zeigen, wie kompliziert es sein kann, mit der Software sicheren Code zu schreiben. Auch andere sind, über die Codequalität gestolpert. Daher sind Leute gefragt, die einen detaillierten Blick auf OpenSSL werfen und die Software verbessern. Dazu zählt auch die bessere Lesbarkeit des Codes oder gute Dokumentation.

Wenn ihr wissen wollt, ob ihr betroffen seit, schaut lokal auf die OpenSSL-Version, nutzt die Zeile openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep ‘server extension “heartbeat” (id=15)’ || echo safe oder verwendet den Testservice von Lutz Donnerhacke oder Filippo Valsorda.

Weiterlesen:

Passwort und Nutzername im Dump der Daten von Yahoo! Mail

cronjob