SSL-Zertifikate – Grundlagen, Anbieter, Stolperfallen

Grün gewinnt

Michael Hamm, Jürgen Seeger

Zertifikate sollen die Identität einer Website sicherstellen und den Datenverkehr verschlüsseln. Das klappt aber nur, wenn Benutzer, Webadministratoren und Software fehlerfrei zusammenspielen.

Eigentlich ist es ganz einfach: HTTPS ersetzt HTTP, und das Web ist sicher. Doch die Tücken liegen wie immer im Detail, die Störfaktoren sitzen vor den Tastaturen – am Browser, in den Büros der Softwareentwickler und der Webadministratoren.

Welche Certificate Authorities der Browser unterstützt, lässt sich in den Einstellungen nachprüfen (Abb. 1).

HSTS: HTTP Strict Transport Security

HSTS ist in RFC6797 definiert. Es handelt sich um einen Mechanismus, der es zum einen einem Webserver erlaubt, dem Client mitzuteilen, dass er nur über einen sicheren Kanal zu erreichen ist. Er deklariert dies mittels des HTTP Response Header Field „Strict-Transport-Security“.

Zum anderen sollen Benutzer dem Browser durch entsprechende Konfiguration mitteilen können, dass er mit gegebenen Seiten nur über HTTPS kommunizieren soll.

Jeder TLS/SSL-Fehler wie ein abgelaufenes oder anderweitig ungültiges Zertifikat soll als fatal gelten und zum Abbruch der Verbindung führen. Das soll die Click-through-Rate deutlich verringern, da ein tumbes Weiterklicken nicht mehr möglich ist.

Google führt eine Liste, in die sich Sites eintragen können (siehe ix.de/ix1801064).

Doch alles der Reihe nach, zunächst ein paar Grundlagen: Hängt am in der Anwendungsschicht des IP-Stacks angesiedelten HTTP ein S für „secure“, resultiert diese Sicherheit aus einem im Schichtenmodell eine Ebene tiefer beheimateten Protokoll: TLS – Transport Layer Security. TLS liegt derzeit in Version 1.2 vor und ist im RFC 5246 spezifiziert (siehe ix.de/ix1801064, dort sind auch eine Reihe weiterer Onlinequellen und Hintergrundinformationen zu finden). Von der Nachfolgeversion 1.3 existiert bereits ein Entwurf, der voraussichtlich 2018 verabschiedet wird. TLS ist der Erbe des von Netscape entwickelten Secure Socket Layer (SSL). TLS in Version 1.0 gilt auch als SSL-Version 3.1, ist unsicher und sollte nicht mehr zum Einsatz kommen.

HPKP: Public Key Pinning Extension for HTTP

Bei HPKP handelt es sich um eine in RFC7469 definierte HTTP-Header-Erweiterung. Das neue Header-Feld „Public-Key-Pins“ erlaubt dem Server, den Browser anzuweisen, sich für einen gewissen Zeitraum an die kryptografische Identität des Servers zu erinnern. Und zwar soll der Browser sich mindestens einen, möglicherweise aber auch mehrere öffentliche Schlüssel der hierarchischen Zertifizierungskette merken. Wird die CA dann später kompromittiert und ein bösartiges Zertifikat für einen MITM-Angriff erzeugt, kann der Browser das erkennen und so verhindern.

HPKP ist nicht perfekt. Hat die Attacke bereits vor dem ersten Aufruf der Webseite stattgefunden, greift das Verfahren nicht und der Browser merkt sich das kompromittierte Zertifikat.

Zudem ist es für Websitebetreiber schwer zu implementieren und hat sich seit seiner Einführung 2015 kaum verbreitet. So sollen von den Top-1-Million-Sites von Alexa nur 375 HPKP nutzen. Google hat darum zu Chrome-Version 67, die Ende Mai 2018 kommen soll, das dynamische Pinning abgekündigt. Die im Browser eingebauten statischen Pins bleiben vorerst erhalten; sie sollen erst verschwinden, wenn alle Zertifikate via Certificate Transparency erfasst sind. Dabei handelt es sich um ein von Google präferiertes Verfahren, das die CAs dazu zwingen soll, ihre ausgestellten Zertifikate in einem manipulationssicheren öffentlichen Log zu protokollieren.

TLS dient zur Sicherung der Kommunikation von Client-Server-Anwendungen. Damit ist vor allem der Schutz vor dem Manipulieren, Fälschen und Abhören von Nachrichten innerhalb einer Sitzung (Session) gemeint. TLS soll also die Integrität und die Vertraulichkeit (Privacy) der einzelnen Nachrichten gewährleisten.

Der Selbsttest

Der Qualys-Test liefert Informationen über die SSL-Fähigkeiten von Server … (Abb. 2)

… und Webbrowser (Abb. 3).

Qualys SSL Labs bietet die auch von Auditoren gern genutzte Möglichkeit, seine eigene TLS/SSL-Installation auf Sicherheit zu überprüfen. Das Overall Rating vermittelt eine klare Übersicht über das Sicherheitsniveau des getesteten Servers.

Weiter unten folgen wesentlich detailliertere Informationen über das Zertifikat wie der „Common Name“, der Gültigkeitszeitraum, der „Issuer“, der verwendete Signaturalgorithmus und vieles mehr. Die vom Server unterstützten Protokolle und Cipher Suites werden aufgelistet, Handshakes mit Dutzenden von Clients simuliert und Eigenschaften wie Verwundbarkeiten gegen bekannte Angriffe getestet.

Doch nicht nur die Sicherheit des eigenen TLS-Servers lässt sich hier überprüfen. Der wissbegierige Anwender kann sich auch über den Zustand seines eigenen Browsers informieren lassen.

Erfüllt werden diese Anforderungen durch das „TLS Record Protocol“. Vertraulichkeit garantiert eine starke symmetrische Verschlüsselung wie AES oder Camellia, die Integrität der Nachrichten der Prüfsummenalgorithmus Message Authentication Code (MAC).

Serveridentität nachweisen

Doch was nützt es dem Client, wenn er zwar verschlüsselt, aber mit dem falschen Server kommuniziert? Der Server muss darum seine Identität nachweisen können. Und hier kommen Zertifikate ins Spiel. Sie sind ein Teil des X.509-Protokolls und binden die Identität des Servers an dessen öffentlichen Schlüssel, den Public Key. Die Zugehörigkeit von Schlüssel und Server attestiert eine (hoffentlich) vertrauenswürdige Zertifizierungsstelle, die Certificate Authority (CA), durch eine Signatur.