iX 1/2018
S. 64
Report
Websicherheit
Aufmacherbild

SSL-Zertifikate – Grundlagen, Anbieter, Stolperfallen

Grün gewinnt

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).

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.

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.

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.

Kommentieren