Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- signatur:ssl:start [2023/12/06 09:37] – Martin Pabst
+++ signatur:ssl:start [2023/12/11 09:59] (aktuell) – Martin Pabst
@@ Zeile 2: / Zeile 2: @@
 <WRAP center round info 80%>
 {{ :signatur:pasted:20231205-114734.png?300}}
-Immer dann, wenn wir eine Seite im Browser per https-Protokoll aufrufen, z.B. zur URL ''https://www.learnj.de/11'', zeigt uns dieser durch ein Vorhängeschloss-Symbol an, dass er das Zertifikat des Servers überprüft hat und dass die Kommunikation sicher sei. Dies sichert uns zweierlei zu:
+Immer dann, wenn wir eine Seite im Browser per https-Protokoll aufrufen, z.B. zur URL ''https://www.learnj.de/11'', zeigt uns dieser durch ein Vorhängeschloss-Symbol an, dass er das Zertifikat des Servers überprüft hat und dass die Kommunikation sicher ist. Dies sichert uns zweierlei zu:
-  * Der Server, der auf unsere Anfrage geantwortet hat, ist berechtigt, Webseiten für die angegebene URL auszuliefern. Es handelt sich also nicht um den Server eines Angreifers, der die Webseite imitiert.
+  * Der Server, der auf unsere Anfrage geantwortet hat, **ist berechtigt, Webseiten für die angegebene URL auszuliefern**. Es handelt sich also nicht um den Server eines Angreifers, der die Webseite imitiert.
-  * Die **Übertragung** der Daten vom Browser zum Server und umgekehrt erfolgt verschlüsselt.
+  * Die **Übertragung** der Daten vom Browser zum Server und umgekehrt erfolgt **verschlüsselt**.
 Es stellen sich folgende Fragen:
-  * Wie stellt der Browser sicher, dass der antwortende Server wirklich zur Domain www.learnj.de gehört und nicht ein man in the middle-Server die Anfrage beantwortet?
+  * Wie stellt der Browser sicher, dass der antwortende Server wirklich zur Domain www.learnj.de gehört und nicht ein [[https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff|man in the middle]]-Server die Anfrage beantwortet?
-  * Wie können sich der Browser und der Server auf eine Schlüssel zur Verschlüsselung einigen, ohne dass ein man in the middle diesen abgreifen und die nachfolgende Kommunikation dann belauschen kann?
+  * Wie können sich der Browser und der Server auf eine Schlüssel zur Verschlüsselung einigen, ohne dass ein "man in the middle" diesen abgreifen und die nachfolgende Kommunikation dann belauschen kann?
 **Lösungsansatz (vereinfachte Darstellung):** \\
@@ Zeile 23: / Zeile 23: @@
 **Inwiefern ist die Darstellung vereinfacht?**
   * Der Handshake ist in Wirklichkeit noch deutlich ausgefeilter, [[https://organicprogrammer.com/2019/02/22/https-handshake/|siehe beispielsweise hier]].
-  * Im Browser hinterlegt ist meist nicht direkt der public key der certificate authority, sondern der public-key von wenigen sogenannten root certificate authorities. Diese signieren die public-keys untergeordneter CAs, die wiederum die public-keys weiterer CAs signieren usw... \\ Man spricht von einer **[[https://en.wikipedia.org/wiki/Chain_of_trust|Zertifikatskette (chain of trust)]]**, durch die dann letztlich das Zertifikat des Webservers beglaubigt wird.
+  * Im Browser hinterlegt ist meist nicht direkt der public key der certificate authority, sondern der public-key von wenigen sogenannten root certificate authorities. Diese signieren die public-keys untergeordneter CAs, die wiederum die public-keys weiterer CAs signieren usw... \\ Man spricht von einer **[[https://en.wikipedia.org/wiki/Chain_of_trust|Zertifikatskette (chain of trust)]]**, durch die dann letztlich das Zertifikat des Webservers beglaubigt wird. [[signatur:chainoftrust:start|Details dazu im nachfolgenden Kapitel.]]
 </WRAP>