Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung
Vorhergehende Überarbeitung
ef:kryptographie:tls [2025/09/29 16:15] – angelegt lehmannref:kryptographie:tls [2025/09/29 16:44] (aktuell) lehmannr
Zeile 1: Zeile 1:
 +~~NOTOC~~
 +<WRAP center 1200px>
 ====== VI. Konkrete Verschlüsselung im Internet (SSL/TLS) ====== ====== VI. Konkrete Verschlüsselung im Internet (SSL/TLS) ======
  
Zeile 9: Zeile 11:
 Der Client (mein Browser z.B. Google Chrome/Safari/Firefox) verbindet sich mit dem Server von Instagram und sendet ein sogenanntes „Client Hello“. Dies ist eine Startmeldung, die dem Server zu verstehen gibt, dass sich jemand mit ihm verschlüsselt „unterhalten will“. Nun müssen sich Chrome und der Instagram-Server darauf verständigen, welche Verschlüsselungsmethode und welcher Schlüssel verwendet werden. Theoretisch könnte der Server einfach seinen öffentlichen Schlüssel senden und der Client verschlüsselt die gesamten Daten mit diesem öffentlichen Schlüssel und schickt sie dem Server, doch bei grösseren Datenmengen ist dies ineffizient, da es aufwändig ist, viele Daten mit dem RSA-Verfahren auszutauschen. Der Client (mein Browser z.B. Google Chrome/Safari/Firefox) verbindet sich mit dem Server von Instagram und sendet ein sogenanntes „Client Hello“. Dies ist eine Startmeldung, die dem Server zu verstehen gibt, dass sich jemand mit ihm verschlüsselt „unterhalten will“. Nun müssen sich Chrome und der Instagram-Server darauf verständigen, welche Verschlüsselungsmethode und welcher Schlüssel verwendet werden. Theoretisch könnte der Server einfach seinen öffentlichen Schlüssel senden und der Client verschlüsselt die gesamten Daten mit diesem öffentlichen Schlüssel und schickt sie dem Server, doch bei grösseren Datenmengen ist dies ineffizient, da es aufwändig ist, viele Daten mit dem RSA-Verfahren auszutauschen.
  
-Es wird daher von beiden Seiten ein symmetrisches Verfahren verwendet, welches zunächst abgemacht wird (früher DES, heute AES, 3DES, Idea und RC4). Welches Verfahren verwendet wird, hängt davon ab, welche Verschlüsselung der Client und der Server beherrschen. Bevor aber symmetrisch verschlüsselt werden kann, muss zunächst ein Schlüssel (Session-Key) ausgetauscht werden. Dieser Schlüsseltausch geschieht mit dem RSA- oder mit dem Diffie-Hellman Verfahren. Sobald beiden Parteien den  Schlüssel haben wird der gesamte Nachrichtenverkehr mit diesem Schlüssel verschlüsselt und bei jeder Neuverbindung wird ein neuer Schlüssel gewählt.+Es wird daher von beiden Seiten ein symmetrisches Verfahren verwendet, welches zunächst abgemacht wird (früher DES oder 3DES, heute AES oder ChaCha9). Welches Verfahren verwendet wird, hängt davon ab, welche Verschlüsselung der Client und der Server beherrschen. Bevor aber symmetrisch verschlüsselt werden kann, muss zunächst ein Schlüssel (Session-Key) ausgetauscht werden. Dieser Schlüsseltausch geschieht mit dem RSA- oder mit dem Diffie-Hellman Verfahren. Sobald beiden Parteien den Schlüssel habenwird der gesamte Nachrichtenverkehr mit diesem Schlüssel verschlüsselt und bei jeder Neuverbindung wird ein neuer Schlüssel gewählt
 + 
 +Konkret geschieht das Folgende: 
 +  * Im Handshake machen Client und Server die Protokolle aus, welche verwendet werden sollen. 
 +  * Der Client sendet eine ClientHello-Meldung, in der er angibt, welche Verschlüsselungs-Algorithmen er beherrscht und er sendet Zufallszahlen und den öffentlichen Teil für den Diffie-Hellman Schlüsseltausch. 
 +  * Der Server antwortet mit der ServerHello-Nachricht. Er entscheidet, welche Verschlüsselungs-Algorithmen verwendet werden und seinen öffentlichen Teil für Diffie-Hellman. Damit können beide einen geheimen Schlüssel generieren (Diffie-Hellman mit elliptischen Kurven ECDH) 
 +  * Der Server schickt sein Zertifikat, welches über eine Trusted-Chain von einer Root-Zertifizierungsstelle signiert wurde. Der Client prüft das Zertifikat und weiss nun, dass er tasächlich mit der gewünschten Domain kommuniziert. 
 +  * Der Handshake wird mitprotokolliert und gehashed und in einer Finished-Nachricht mit einem MAC übertragen. Dadurch können der Server und der Client sicher sein, dass sie denselben Handshake abgemacht haben (Schutz vor Man-in-the-middle-Attacke). 
 +  * Aus dem gemeinsam erstellten Schlüssel generieren Server und Client die verschiedenen Schlüssel (für MAC des Handshakes und die konkreten Schlüssel für die Blockchiffre) 
 +  * Nun werden alle Daten mit dem abgemachten AEAD-Algorithmus verschlüsselt übertragen (AES-GCD oder ChaCha20-Poly1305). Dieser AEAD-Algorithmus sorgt für die Verschlüsselung und die Integrität und Authentizität der Daten
  
-Damit der Client sicher ist, dass er tatsächlich mit Instagram verbunden ist, schickt der Server noch ein Zertifikat, welches als Digitale Signatur dient. Dieses Zertifikat ist ausserdem bei einer Zertifizierungsstelle registriert, sodass man sicher ist, dass der entsprechende private Schlüssel auch tatsächlich Instagram gehört. 
  
 <WRAP nicebox green> <WRAP nicebox green>
Zeile 28: Zeile 38:
 Hier sieht man, welche Verschlüsselungsverfahren der Browser beherrscht. Die Abkürzungen enthalten sowohl die Methode, wie der Schlüssel ausgetauscht wird, als auch welche Symmetrische Verschlüsselung danach verwendet wird. Z.B. ECDHE = Elliptic Curve Diffie-Hellman (Schlüsseltausch) Hier sieht man, welche Verschlüsselungsverfahren der Browser beherrscht. Die Abkürzungen enthalten sowohl die Methode, wie der Schlüssel ausgetauscht wird, als auch welche Symmetrische Verschlüsselung danach verwendet wird. Z.B. ECDHE = Elliptic Curve Diffie-Hellman (Schlüsseltausch)
 Komplette Informationen z.B hier: https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256/ Komplette Informationen z.B hier: https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256/
 +
 +**Beispiel: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 **
 +
 +  * Für den Schlüsseltausch wird ECDHE verwendet, also Diffie-Hellman mit Elliptischen Kurven
 +  * Für das Zertifikat wird das asymmetrische RSA-Verfahren verwendet.
 +  * Es wird der AEAD-Algorithmus AES256_GCM vewendet (AES Blockchiffre mit GCM-MAC zur Authentifizierung und Integrität)
 +  * Die Hashes (z.B. Hash der Finished-Nachricht beim Handshake) wird SHA384 verwendet.
 +
 +
 +[[ef:start|Zurück zur Übersicht]]
 +
 +</WRAP>
  • ef/kryptographie/tls.1759155306.txt.gz
  • Zuletzt geändert: 2025/09/29 16:15
  • von lehmannr