Die Fortsetzung zum Oberthema Kryptographie mit Zertifikaten und
Zertifizierungsstellen gibt es in der einhunderfünfundvierzigsten
Episode des Anwendungsentwickler-Podcasts. TL;DR Wenn ich eine
verschlüsselte Verbindung zu einem Webserver aufbaue, brauche ich
einen öffentlichen Schlüssel, dessen Herkunft ich prüfen kann.
Zertifikate verbinden diesen Schlüssel mit Angaben zu seinem/seiner
Inhaber:in und einer digitalen Signatur der Zertifizierungsstelle
(CA). Dein Browser prüft die Signaturen entlang einer
Vertrauenskette, die bei einem als vertrauenswürdig hinterlegten
Root-Zertifikat endet. Werden CAs angegriffen, können gefälschte
Zertifikate gültig erscheinen; Sperrlisten und zeitnahe
Browser-Updates helfen dabei, entzogenes Vertrauen technisch
durchzusetzen. Kapitelmarken [00:00:01] Einstieg: Zertifikate und
Zertifizierungsstellen [00:00:47] Grundlagen: Hashes und
Schlüsselpaare [00:02:00] Digitale Signaturen, Authentizität und
Integrität [00:03:51] Öffentliche Schlüssel und
Man-in-the-Middle-Angriffe [00:05:57] Zertifikate und die Rolle der
CA [00:08:14] Wie Zertifizierungsstellen Angaben prüfen [00:09:20]
Vertrauensketten und Root-Zertifikate [00:10:51] Zertifikate auf
dem Webserver [00:12:08] Vertrauenswürdige CAs im Browser
[00:14:16] Zertifikate sperren mit einer CRL [00:16:50] Inhalt und
technische Form eines Zertifikats [00:17:50] Signaturen von
Zertifikaten prüfen [00:19:13] Welche Zertifikatsdaten die CA
signiert [00:21:02] Selbstsignierte Root-Zertifikate als
Vertrauensanker [00:23:52] Eigene Zertifikate und interne
Unternehmens-CAs [00:24:54] X.509, Attribute und Common Name
[00:27:27] Ablauf am Beispiel einer Verbindung zum Webserver
[00:29:28] Risiken durch angegriffene Zertifizierungsstellen
[00:31:13] Browser-Updates und das Beispiel DigiNotar [00:34:13]
Feedback und Shownotes [00:35:06] Ausblick auf HTTPS Inhalt
Wiederholung: Für die elektronische Signatur und die
Verschlüsselung von Daten werden Paare aus öffentlichen und
privaten Schlüsseln benötigt. Probleme Wer garantiert dem Absender,
dass ein öffentlicher Schlüssel auch wirklich dem angegebenen
Empfänger gehört? Wie kann sichergestellt werden, dass ein
öffentlicher Schlüssel nicht von einem Angreifer durch seinen
eigenen ausgetauscht wurde? Zertifikat Mit einem Zertifikat
bestätigt eine unabhängige dritte Partei die Echtheit des
öffentlichen Schlüssels des Empfängers. Diese dritte Partei wird
Zertifizierungsstelle genannt. Die Zertifizierungsstelle (englisch
Certificate Authority, abgekürzt CA) bestätigt die Authentizität
des Schlüssels des Empfängers, indem sie z.B. dessen Adresse und
Identität prüft. Das kostet meistens Geld, je nachdem wie intensiv
diese Prüfung gemacht wird. Das geht von "muss eine E-Mail-Adresse
mit dieser Domain abrufen können" bis hin zu "das Unternehmen
existiert tatsächlich unter der postalischen Adresse". Wenn Alice
statt dem öffentlichen Schlüssel von Bob ein Zertifikat erhält,
kann sie es wiederum mit dem Zertifikat der CA prüfen. Sie weiß nun
sicher, dass sie den korrekten öffentlichen Schlüssel nutzt und
nicht einen kompromittierten. Alice muss dafür allerdings dem
Zertifikat der Zertifizierungsstelle selbst vertrauen, da auch
diese kompromittiert werden kann. Es entsteht also eine
Vertrauenskette, die irgendwo in einem Root-Zertifikat endet. Und
diesem Zertifikat muss manuell vertraut werden. Das "Urvertrauen"
in die verschiedenen CAs wird hergestellt, indem sie z.B. in
Browser wie Firefox oder Chrome vom Hersteller fest "eingebaut" und
als vertrauenswürdig gekennzeichnet werden. Sollte ein Zertifikat
kompromittiert werden, gibt es sog. Certificate Revocation Lists
(CRL), in die die nicht mehr validen Zertifikate eingetragen werden
können. Dafür müssen diese Listen aber natürlich bei jeder Prüfung
eines Zertifikats kontrolliert werden, was sehr aufwändig ist.
Technische Umsetzung Zertifikate sind (Plain-Text-)Dateien, die
verschiedene technische Informationen enthalten wie z.B. den Namen
des Ausstellers, den zertifizierten öffentlichen Schlüssel des
Empfängers, ein Ablaufdatum, die elektronische Signatur der
ausstellenden CA. Vereinfacht (!) gesagt, ist das Zertifikat der
mit dem privaten Schlüssel der CA signierte öffentliche Schlüssel
des Empfängers. Nur mit dem öffentlichen Schlüssel der CA kann
diese Signatur geprüft werden. Und dieser öffentliche Schlüssel ist
für alle wichtigen CAs im Browser hinterlegt. Genauer gesagt werden
alle Inhalte des Zertifikats signiert und vom öffentlichen
Schlüssel des Empfängers nur der Hash. Und im Browser sind auch
nicht nur die öffentlichen Schlüssel der CAs hinterlegt, sondern
wiederum Zertifikate, die wiederum zertifizert sind usw. Die
Root-Zertifikate am Ende dieser Kette werden dann von der CA selbst
signiert und heißen selbstsignierte Zertifikate. Dabei garantiert
quasi die CA selbst, dass sie wirklich diese CA ist. Der Aufbau der
Dateien ist standardisiert, z.B. im Format X.509. Aussteller und
Zertifikatinhaber werden durch eine Reihe von Attributen
beschrieben, z.B. den sog. Common Name (CN), Land und Ort. Links
Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts
Public-Key-Zertifikat X.509 Zertifikatsperrliste Zusammenfassung
Hashes und digitale Signaturen Wenn ich einen Hash über Daten
bilde, entsteht ein Fingerabdruck mit fester Länge. Die
Ausgangsdaten können beliebig lang sein. Schon ein verändertes Bit
sollte den Hash deutlich verändern, sodass sich Änderungen an den
Daten erkennen lassen. Bei einer digitalen Signatur signiere ich
den Hash der Daten mit meinem privaten Schlüssel. Du kannst die
Signatur mit meinem öffentlichen Schlüssel prüfen und selbst einen
Hash über die empfangenen Daten bilden. Stimmen die Hashwerte
überein, lassen sich zwei Schutzziele prüfen: Authentizität: Die
Signatur stammt von der Person, die den passenden privaten
Schlüssel besitzt. Integrität: Die signierten Daten sind
unverändert angekommen. Die signierten Inhalte bleiben lesbar. Für
vertrauliche Daten braucht es zusätzlich ein Verfahren, das sie
verschlüsselt. Warum ein öffentlicher Schlüssel ein Zertifikat
braucht Für eine Nachricht an einen Webserver kann ich dessen
öffentlichen Schlüssel verwenden. Der Server entschlüsselt sie mit
dem dazugehörigen privaten Schlüssel. Dabei muss ich sicher sein,
dass der öffentliche Schlüssel zum gewünschten Server gehört. Ein:e
Angreifer:in kann einen Schlüssel auf einem übernommenen Server
ersetzen oder ihn unterwegs bei einem Man-in-the-Middle-Angriff
austauschen. Wenn ich anschließend mit diesem ausgetauschten
Schlüssel verschlüssele, kann die angreifende Person meine
Nachricht entschlüsseln. Bei einer persönlich bekannten
Kontaktperson kann ich den Schlüssel direkt vergleichen oder seinen
Fingerprint prüfen. Für einen bisher unbekannten Webserver
übernimmt eine Zertifizierungsstelle, auf Englisch Certificate
Authority (CA), die Rolle einer vertrauenswürdigen dritten Partei.
Sie bestätigt mit ihrer Signatur, wem der öffentliche Schlüssel
zugeordnet ist. Was eine CA prüft Bevor eine CA ein Zertifikat
ausstellt, prüft sie die Angaben des/der Antragsteller:in. Wie
umfangreich sie dabei vorgeht, hängt vom angebotenen Verfahren ab.
Ein möglicher Nachweis ist der Zugriff auf E-Mails einer Domain.
Weitergehende Prüfungen können Angaben zur Person oder zum
Unternehmen einbeziehen, etwa einen Ausweis oder die Firmenadresse.
Die genannten Angebote reichen von kostenlosen Zertifikaten
beziehungsweise etwa zehn Dollar pro Jahr bis zu mehreren hundert
Dollar jährlich für umfangreichere Prüfungen. Zertifikate gelten
für einen begrenzten Zeitraum und müssen erneuert werden.
Vertrauenskette und Browser Zwischen dem Zertifikat eines
Webservers und einer Root-CA können weitere CA-Zertifikate liegen.
Jede beteiligte CA signiert das nachfolgende Zertifikat. Dein
Browser prüft diese Vertrauenskette, bis er ein Zertifikat
erreicht, dem er bereits vertraut. Browser-Anbieter:innen
hinterlegen dafür CA-Zertifikate in ihrer Software und kennzeichnen
sie als vertrauenswürdig. Darin stehen die öffentlichen Schlüssel,
mit denen der Browser weitere Signaturen prüfen kann. In den
Sicherheitseinstellungen deines Browsers kannst du dir die
hinterlegten Zertifikate ansehen. Weltweit gibt es mehrere hundert
CAs. Zu den genannten Beispielen gehören Microsoft und die Telekom.
Durch die hinterlegten Zertifikate hängt das Vertrauen deines
Browsers auch davon ab, welche CAs die Browser-Anbieter:innen
akzeptieren. Inhalt und Signatur eines Zertifikats Ein Webserver
liefert seinem Client eine Zertifikatsdatei mit dem öffentlichen
Schlüssel und zusätzlichen Angaben. Zertifikate begegnen dir häufig
als Base64-kodierte Textdateien; daneben gibt es binäre Formate. Zu
den enthaltenen Informationen gehören: Angaben zur ausstellenden CA
und zum/zur Zertifikatsinhaber:in der öffentliche Schlüssel des/der
Inhaber:in das Datum, an dem das Zertifikat ausgestellt wurde,
sowie sein Ablaufdatum Angaben zu den verwendeten Hash-Verfahren
die digitale Signatur der CA Die CA bildet einen Hash über die zu
signierenden Zertifikatsdaten und signiert ihn mit ihrem privaten
Schlüssel. Dadurch sind auch die Angaben geschützt, die den
Schlüssel begleiten. Wenn mein Browser dieses Zertifikat erhält,
prüft er die Signatur mit dem öffentlichen Schlüssel der
ausstellenden CA. Dazu gehört der Vergleich mit einem selbst
berechneten Hash der Zertifikatsdaten. So lässt sich feststellen,
ob die CA das Zertifikat signiert hat und ob seine Inhalte
unverändert geblieben sind. Bei mehreren beteiligten CAs wiederholt
sich diese Prüfung entlang der Kette. Root-Zertifikate und eigene
Zertifikate Am Ende der Kette steht ein Root-Zertifikat, das die
Root-CA selbst signiert. Das Vertrauen in dieses Zertifikat wird
ausdrücklich festgelegt, beispielsweise durch die
Browser-Anbieter:innen. Ab diesem Vertrauensanker lassen sich die
nachfolgenden Signaturen technisch prüfen. Für meinen eigenen
Webserver kann ich ebenfalls ein selbstsigniertes Zertifikat
erstellen....
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.