Zum Abschluss meiner kleinen Reihe zum Oberthema Kryptographie
widmen wir uns der Funktionsweise von HTTPS in der
einhundersechsundvierzigsten Episode des
Anwendungsentwickler-Podcasts. TL;DR Wenn du meine Website über
HTTPS aufrufst, prüft dein Browser das Serverzertifikat anhand
einer vertrauenswürdigen Zertifizierungsstelle. Im beschriebenen
Ablauf überträgt er anschließend einen zufälligen Sitzungsschlüssel
asymmetrisch verschlüsselt an den Webserver, damit beide Seiten
ihre Daten schnell symmetrisch verschlüsseln können. Für deine
eigene Website brauchst du ein Schlüsselpaar und ein passendes
Zertifikat, das du beispielsweise kostenlos bei Let's Encrypt
erhältst. Bei Zertifikatswarnungen solltest du die Ursache prüfen,
bevor du der Verbindung vertraust. Kapitelmarken [00:00:20] HTTPS
als Abschluss der Kryptografie-Reihe [00:01:03] Öffentliche und
private Schlüssel sowie digitale Signaturen [00:01:34]
Zertifizierungsstellen und die Vertrauenskette [00:03:00]
Rechenaufwand beim asymmetrischen Verschlüsseln [00:04:41] HTTPS
als hybrides Verfahren [00:05:33] HTTPS aufrufen und Port 443
[00:06:26] Serverzertifikat und öffentlichen Schlüssel prüfen
[00:09:09] Domain und Gültigkeitsdauer kontrollieren [00:09:59] Den
symmetrischen Sitzungsschlüssel übertragen [00:11:24] Kostenlose
Zertifikate von Let's Encrypt [00:12:55] HTTPS von Grund auf
einrichten [00:13:28] Root-Zertifikate und Vertrauen der
Browserhersteller [00:16:37] Intermediate-Zertifikate in der
Zertifikatskette [00:17:08] Schlüsselpaar erzeugen und CSR stellen
[00:18:20] Kontrolle über die Domain nachweisen [00:20:48]
Verschlüsselungsstärke und Extended Validation [00:22:53]
Zertifikat im Webserver hinterlegen [00:23:59] Zertifikat im
Browser prüfen und Sitzungsschlüssel austauschen [00:27:14] Die
fünf beteiligten Schlüssel [00:27:44] Zertifikatswarnungen und
abgelaufene Zertifikate [00:30:32] Abweichende Domains und
Wildcard-Zertifikate [00:33:29] Unbekannte CAs und selbstsignierte
Zertifikate [00:35:20] Interne CAs und Zertifikatsspeicher im
Unternehmen [00:36:49] Rückblick auf die Kryptografie-Reihe
[00:37:56] Praxis- und Prüfungsbezug für IT-Azubis [00:38:23]
Fragen und Shownotes Inhalt Wiederholung Für die elektronische
Signatur und die Verschlüsselung von Daten werden Paare aus
öffentlichen und privaten Schlüsseln benötigt. Um die Authentizität
öffentlicher Schlüssel zu gewährleisten, werden Zertifikate
verwendet, die von vertrauenswürdigen Zertifizierungsstellen
ausgegeben werden. Probleme Wie können wir bei Millionen
verschiedenen Websites sicherstellen, dass sie korrekte Schlüssel
nutzen, ohne dass wir alle Websitebetreiber persönlich kennen
müssen? Wie kann bei den großen Datenmengen im Internet eine
performante Verschlüsselung gewährleistet werden? HTTPS Um mit
einem Webserver verschlüsselt kommunizieren zu können, benötigt der
Webbrowser den öffentlichen Schlüssel des Webservers. Diesen kann
er einfach direkt vom Webserver selbst herunterladen. Aber wer
garantiert ihm die Echtheit dieses Schlüssels? Vielleicht wurde der
Server gehackt oder der private Schlüssel gestolen. Deswegen
liefert der Webserver nicht direkt den öffentlichen Schlüssel aus,
sondern ein von einer CA ausgestelltes Zertifikat, das den
öffentlichen Schlüssel des Webservers enthält, aber zusätzlich noch
die Signatur der CA, die dessen Echtheit bestätigt. Wenn dieses
Zertifikat gültig ist (die Prüfung erfolgt gegen die "eingebauten"
CAs im Browser), weiß der Browser sicher, dass er den korrekten
Schlüssel erhalten hat und kann ihn für die Verschlüsselung nutzen.
Dabei prüft der Browser auch, ob das Zertifikat zur aktuellen
Domain gehört. Der CN enthält bei HTTPS-Zertifikaten diese Domain.
Es gibt seit einiger Zeit auch eine kostenlose CA: Let's Encrypt.
Damit kann sich jeder Webserverbetreiber gültige Zertifikate
erzeugen, indem er technisch nachweist, dass die Domain und der
Server wirklich ihm gehören. Der Datenverkehr wird bei HTTPS
symmetrisch verschlüsselt, da die Schlüssellängen hierbei deutlich
kürzer sind, was deutliche Performancevorteile hat. Um diesen
Schlüssel zwischen Browser und Webserver auszutauschen wird das
obige asymmetrische Verfahren genutzt. Deswegen ist HTTPS ein
hybrides Verfahren. Technischer Ablauf CA CA generiert privaten und
öffentlichen Schlüssel. CA erstellt selbstsigniertes
Root-Zertifikat: ihr eigener öffentlicher Schlüssel signiert mit
ihrem privaten Schlüssel. CA-Root-Zertifikat wird in Browser
eingebaut. Webserver Webserver generiert privaten und öffentlichen
Schlüssel. Webserver lässt öffentlichen Schlüssel von CA mit ihrem
privaten Schlüssel signieren. Webserver installiert dieses
Zertifikat und konfiguriert HTTPS. Browser Browser öffnet Website
auf dem Webserver. Webserver liefert sein Zertifikat aus. Browser
prüft das Zertifikat mit dem öffentlichem Schlüssel der CA aus
seinem eingebautem Root-Zertifikat und erhält den öffentlichen
Schlüssel des Webservers. Browser generiert einen zufälligen
temporären Sitzungsschlüssel und verschlüsselt ihn mit dem
öffentlichen Schlüssel des Webservers. Browser sendet den
verschlüsselten Sitzungsschlüssel an den Webserver, der ihn mit
seinem privaten Schlüssel entschlüsselt. Nun kennen Browser und
Webserver den Sitzungsschlüssel und können damit symmetrisch den
Datenverkehr verschlüsseln. Mögliche Probleme mit
HTTPS-Zertifikaten Das Zertifikat ist abgelaufen. Das Zertifikat
passt nicht zur Domain. Das Zertifikat wurde von einer nicht
vertrauenswürdigen CA ausgestellt. Links Permalink zu dieser
Podcast-Episode RSS-Feed des Podcasts Hypertext Transfer Protocol
Secure Wie funktioniert https? Einführung inOpenSSL und
X.509-Zertifikate Let's Encrypt Certificate Signing Request
Zusammenfassung Welche Schlüssel bei HTTPS zusammenarbeiten Wenn du
meine Website über https:// aufrufst, beginnt zwischen deinem
Browser und meinem Webserver ein Ablauf, der asymmetrische und
symmetrische Verfahren kombiniert. HTTPS steht für HTTP Secure und
verwendet Port 443. Auch eine Weiterleitung auf dem Webserver kann
deinen Browser zu HTTPS führen. Bei asymmetrischen Verfahren
gehören ein öffentlicher und ein privater Schlüssel zusammen. Mit
dem öffentlichen Schlüssel des Webservers lassen sich Daten
verschlüsseln, die der Server mit seinem privaten Schlüssel
entschlüsselt. Dadurch bleibt der Inhalt vertraulich. Digitale
Signaturen ermöglichen es, die Echtheit und mithilfe eines
Hashwerts auch die Unversehrtheit von Daten zu prüfen. Für den
beschriebenen Ablauf sind fünf Schlüssel beteiligt: Der private
Schlüssel der Zertifizierungsstelle dient dazu, Zertifikate zu
signieren. Mit dem öffentlichen Schlüssel der Zertifizierungsstelle
prüft der Browser diese Signaturen. Der öffentliche Schlüssel des
Webservers steht im Serverzertifikat und dient dazu, den
Sitzungsschlüssel verschlüsselt zu übertragen. Den privaten
Schlüssel des Webservers braucht der Server, um den übertragenen
Sitzungsschlüssel zu entschlüsseln. Der symmetrische
Sitzungsschlüssel verschlüsselt anschließend die Daten zwischen
Browser und Server. Wie der Browser einem Serverzertifikat vertraut
Damit dein Browser den öffentlichen Schlüssel meiner Website
zuordnen kann, lässt eine Zertifizierungsstelle, auch Certificate
Authority oder CA genannt, ihn durch ein Zertifikat bestätigen.
Dein Browser vertraut bestimmten CAs, deren Root-Zertifikate
bereits hinterlegt sind. Dieses Vertrauen erstreckt sich über die
Zertifikatskette auf das Serverzertifikat. Am Anfang dieser Kette
erzeugt die CA ein eigenes Schlüsselpaar und stellt sich ein
selbstsigniertes Root-Zertifikat aus. Browserhersteller prüfen die
CA und hinterlegen ihr Root-Zertifikat als vertrauenswürdig. Diese
Prüfung entscheidet darüber, welchen ausgestellten Zertifikaten der
Browser später vertraut. Zwischen dem Root-Zertifikat und dem
Serverzertifikat können Intermediate-Zertifikate liegen. Über deren
Signaturen lässt sich die Kette bis zum bekannten Root-Zertifikat
prüfen. Root-Zertifikate haben häufig eine lange Laufzeit, damit
sie seltener ausgetauscht werden müssen. Weshalb HTTPS beide
Verfahren kombiniert Wenn ich große Datenmengen über meinen
Webserver ausliefere, kostet asymmetrisches Verschlüsseln
Rechenzeit. Symmetrische Verfahren arbeiten schneller und eignen
sich deshalb für den laufenden Datenverkehr. Als Beispiele werden
symmetrische Schlüssel mit 128 Bit und asymmetrische Schlüssel mit
4096 Bit genannt. HTTPS arbeitet als hybrides Verfahren: Zu Beginn
wird asymmetrisch ein symmetrischer Schlüssel sicher übertragen.
Anschließend verschlüsseln beide Seiten die eigentlichen Inhalte
symmetrisch. Dafür müssen Browser und Server denselben
Sitzungsschlüssel kennen. Was ich für HTTPS auf meinem Webserver
einrichte Ein Schlüsselpaar erzeugen: Ich erstelle den öffentlichen
und den privaten Schlüssel für meinen Webserver. Den privaten
Schlüssel bewahre ich geschützt auf. Ein Zertifikat beantragen: Den
öffentlichen Schlüssel übermittle ich mit einem Certificate Signing
Request, kurz CSR, an eine CA. Dazu kommen die erforderlichen
Angaben zur Domain und gegebenenfalls zu mir als Betreiber:in. Die
Kontrolle über die Domain nachweisen: Die CA prüft beispielsweise,
ob ich eine bestimmte Datei über die Domain ausliefern oder eine
E-Mail an eine zugehörige administrative Adresse empfangen kann.
Das Zertifikat im Server hinterlegen: Nach der Prüfung signiert die
CA die Zertifikatsdaten mit ihrem privaten Schlüssel. Die erhaltene
Zertifikatsdatei hinterlege ich auf meinem Webserver. Die Dateien
konfigurieren: Bei einem Apache-Webserver trage ich ein, wo das
Zertifikat liegt. Der Server braucht außerdem Zugriff auf den
passenden privaten Schlüssel. Kostenlose Zertifikate und die
Prüfung der Identität Für meine Website verwende ich Let's Encrypt.
Diese CA stellt kostenlose Zertifikate aus und ermöglicht es, den
Ablauf zu automatisieren. Beispielsweise wird eine Datei mit einem
vorgegebenen Inhalt über die beantragte Domain ausgeliefert....
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.