Digitale Signaturen, Zertifikate und TLS

Die vorige Lektion ließ eine Frage offen: Asymmetrische Verschlüsselung erlaubt es Ihnen, jemandem, dessen öffentlichen Schlüssel Sie haben, ein Geheimnis zu senden — aber woher wissen Sie, dass dieser öffentliche Schlüssel tatsächlich dieser Person gehört, und nicht einem Angreifer dazwischen? Digitale Signaturen und Zertifikate beantworten das, und zusammen machen sie TLS möglich, das Protokoll hinter jeder https://-Adresse.

Digitale Signaturen: Herkunftsnachweis, keine Geheimhaltung

Eine digitale Signatur kehrt asymmetrische Verschlüsselung um. Statt eine Nachricht mit dem öffentlichen Schlüssel von jemandem zu verschlüsseln, damit nur diese Person sie lesen kann, signiert der Absender eine Nachricht mit seinem eigenen privaten Schlüssel, und jeder kann sie mit dem öffentlichen Schlüssel des Absenders überprüfen. Gelingt die Überprüfung, stehen zwei Dinge fest: Die Nachricht stammt von wem auch immer diesen privaten Schlüssel besitzt, und sie wurde danach nicht verändert — dieselbe Kollisionsresistenz-Eigenschaft aus der Hashing-Diskussion der vorigen Lektion macht Manipulation erkennbar. Eine Signatur beweist Echtheit und Integrität; sie hält die Nachricht für sich genommen nicht geheim.

Zertifikate: eine Signatur, die für einen öffentlichen Schlüssel bürgt

Ein digitales Zertifikat löst das Problem „wem gehört dieser öffentliche Schlüssel wirklich“. Wie das Cloudflare Learning Center erklärt, ist ein SSL/TLS-Zertifikat „eine Datendatei, die auf dem Ursprungsserver einer Website gehostet wird“ und den Domainnamen, den öffentlichen Schlüssel, ein Ablaufdatum und — entscheidend — „die digitale Signatur der Zertifizierungsstelle“ enthält. Eine Zertifizierungsstelle (CA) ist eine vertrauenswürdige dritte Partei, die prüft, ob eine Website die Domain kontrolliert, für die sie ein Zertifikat beantragt, und dieses Zertifikat dann mit ihrem eigenen privaten Schlüssel signiert. Ihr Browser wird mit einer eingebauten Liste vertrauenswürdiger CAs ausgeliefert, sodass er, wenn er ein von einer davon signiertes Zertifikat erhält, dem darin enthaltenen öffentlichen Schlüssel vertrauen kann, ohne je den Betreiber der Website getroffen zu haben. Ein selbstsigniertes Zertifikat — eines, das eine Website selbst signiert, statt es von einer CA zu beziehen — hat keine solche externe Bürgschaft, weshalb Browser es standardmäßig als nicht vertrauenswürdig behandeln.

TLS: beides zum Einsatz bringen

RFC 8446, die Spezifikation für TLS 1.3, beschreibt einen Handschlag in Phasen: Schlüsselaustausch, bei dem sich beide Seiten auf gemeinsames geheimes Material einigen; dann Authentifizierung, wobei, in den Worten des RFC, „die Serverseite des Kanals immer authentifiziert wird; die Client-Seite wird optional authentifiziert“ — normalerweise beweist nur die Website ihre Identität, nicht der Besucher. Der Server beweist, wer er ist, mithilfe seines Zertifikats und einer Signatur, die nur er mit seinem privaten Schlüssel erzeugen könnte. Sobald beide Seiten der Verbindung vertrauen, leiten sie schnelle symmetrische Schlüssel ab (typischerweise das AES der vorigen Lektion) für die eigentlichen Daten. RFC 8446 erklärt unmissverständlich, was das bringt: Vertraulichkeit und Integrität für die ausgetauschten Daten, und Authentifizierung des Servers. Ebenso unmissverständlich benennt es eine Grenze: „TLS verbirgt nicht die Länge der übertragenen Daten“, und Metadaten wie welcher Server kontaktiert wurde und wann bleiben für jeden sichtbar, der die Verbindung beobachten kann.

Was das Schloss-Symbol bedeutet und was nicht

Eine Phishing-Seite auf einer Nachahmer-Domain kann ein vollkommen gültiges Zertifikat besitzen: TLS authentifiziert die Domain, nicht die Absicht dessen, der sie registriert hat. Deshalb behandelt die frühere Lektion darüber, wie Angriffe ablaufen, eine gefälschte Login-Seite samt Schloss-Symbol als reale Bedrohung, nicht als Widerspruch.