nicht angemeldet
Hallo,
- Server erhält von Zertifizierungsstelle ein öffentliches Zertifikat, indem auch ein public-key enthalten ist.
Das stimmt. Wobei man sich so eine Zertifizierungsstelle zu Testzwecken auch selbst einrichten kann und das Zertifikat selbst signieren kann. Der Browser würde hier allerdings eine Warnung ausgeben, was auch klar ist, denn wie vertrauensvoll ist für den Kunden eines Webshops wohl ein Zertifikat, das selbst ausgestellt wurde.
- Client hat ein private-key (Wird evtl. selber erzeugt oder von Zertifizierungsstelle
geholt?)
Kommuniziert der Client mit einem Server über SSL, dann wird nur der Public Key des Servers vom Client benötigt (Zertifikat), damit dieser die Nachrichten verschlüsseln kann, die nur der Server mit seinem private Key wieder entschlüsseln kann.
In Wirklichkeit ist es etwas komplizierter, da SSL ein hybrides Verfahren ist, aber vom Prinzip her funktioniert die asymmetrische Verschlüsselung so.
- Client schickt bei erster Anfrage Zufallszahlen mit und erhält vom Server das Zertifikat, eine Session und eine ID.
Das Zertifikat kann durch Verbindung zur Zertifizierungsstelle überprüft werden.
Wann genau die Session nun aufgebaut wird, und vom wem die ID geliefert wird, kann ich jetzt nicht sagen. Wurde das Zertifikat von einer der großen registrierten Zertifizierungsstellen ausgestellt, weiß der Browser, dass diese vertrauenswürdig ist, da Zertifizierungsstellen wie VeriSign dem Browser von Haus aus bekannt sind. Sämtliche Zertifikatdaten sind im Zertifikat "kodiert" wenn man so will. Diese Daten kann der Browser auch überprüfen, zB die Gültigkeitsdauer. Das Zertifikat ist lediglich eine einfache Datei, mehr nicht. Der Benutzer überprüft das Zertifikat beim ersten Mal, wo es vom Browser angefordert wird. Er kann dieses Zertifikat akzeptieren oder nicht. Sonst passieren keine Online-Überprüfungen oder dgl, da sämtliche wichtige Daten, die der Browser benötigt, ja bereits im Zertifikat vermerkt sind.
Ausnahmen sind Zertifikat von Zertifizierungsstellen wie zB VeriSign. Da der Browser diese Zertifizierungsstellen ja bereits "von Geburt an" kennt, muss das Zertifikat nicht erst durch den Benutzer akzeptiert werden.
- Beim Client wird mit den Daten (Session, ID und dem davor geschickten Zufallszahl) ein Schlüssel generiert.
(Nennen wir es Premaster-Schlüssel)
Der Premaster-Schlüssel wird mit dem öffentlichen Schlüssel (public-key) verschlüsselt und an den Server geschickt.
Ich glaube, dass das so richtig ist. Allerdings muss ich zugeben, dass ich mich mit den technischen Details noch nicht auseinandergesetzt habe, da man fürs Verständnis im Prinzip nur wissen muss, wie das asymmetrische, bzw hybride Verschlüsselungsverfahren funktioniert.
- (???) Wie erhält der Server nun den Premaster-Schlüssel?
Das ist im Protokoll definiert.
Wie entschlüsselt er zurück. Laut Wiki mit einem
eigenen Privaten-Schlüssel.
Das ist richtig.
Wo kommt der Private Schlüssel her? Wie konnte der Client den Privaten Schlüssel berücksichtigen?
Bevor ein Server überhaupt man ein Zertifikat von einer Zertifizierungsstelle signieren lassen kann, muss dieses erst erzeugt werden. Davor muss aber der Server einmalig erst mal ein Schlüsselpaar (Public, Private) generieren, wobei der Public Key für den Certificate Signing Request (CSR) (= Zertifikatantrag an die Zertifizierungsstelle) benötigt wird. Dieser Public Key wird in diesen CSR hineinkodiert. Der von der Registrierungsstelle signierte CSR ist dann das Zertifikat. Dadurch ist die Übermittlung des Public Keys an den anfragenden Client ja erst möglich. Wie denn sonst käme der Client zu dem Public Key des Servers.
Der Private Key wird irgendwo auf dem Server sicher abgespeichert und der Pfad dem Webserver bekanntgegeben. Da diese beiden Schlüssel immer zusammengehören, ist es möglich, dass der Server nur mit diesem einen Private Key genau nur Nachrichten, die mit diesem einen Public Key generiert wurden, wieder entschlüsseln kann. Warum das so funktioniert, ist einfach nur Mathematik. Beschäftige dich ggf. mit dem Verfahren der RSA-Verschlüsselung, wenn du tiefer in die Materie eintauchen willst.
Der Client braucht, bzw darf den Private Key des Server gar nicht kennen. Ist der Private Key erst mal öffentlich bekannt, ist die Sicherheit der Verschlüsselung hinüber.
- Server generiert dann mit dem Premaster-Schlüssel ein Master-Schlüssel und es geht auf dem gleichen Weg
zurück zum Client. Jetzt haben beide den Master-Schlüssel.
Dazu kann ich nichts sagen.
- Dies wäre jetzt das SSL-Handschake und assymetrisch.
Der SSL-Handshake ja, aber asymmetrisch jein. Das asymmetrische Verschlüsselungsverfahren wird benötigt, um die Kommunikationspartner zu identifizieren. (idR Server identifiziert sich beim Client mittels Zertifikat)
Wie ich schon erwähnte, ist SSL ein hybrides Verfahren, sowohl asymmetrisch, als auch symmetrisch. Während der Verbindung wird aber nur symmetrisch ver- und entschlüsselt.
- Da wir jetzt einen gemeinsamen Master-Schlüssel haben läuft der restliche eigentliche Datenaustausch dann
mit dem Master-Schlüssel symetrisch ab.
Ja.
(Hat der Master-Schlüssel nun einen öffentlichen und privaten Teil???)
Du darfst den Sitzungsschlüssel nicht mit dem Public und Private Key des Servers verwechseln. Das Master Secret wird mit dem Public Key des Servers erzeugt, woraufhin der Sitzungsschlüssel generiert wird, den der Server wieder entschlüsseln kann, weil er ja den Private Key hat, der zu dem Public Key gehört, mit dem das Master Secret erzeugt wurde.
Ich würde dir raten, am Anfang nicht so ins Detail zu blicken, sondern dir muss erst mal klar werden, wie die asymmetrische Verschlüsselung funktioniert. Alles andere sind fürs erste technische Details, die nur zur Verwirrung beitragen.
Damit ich nun das folgende checke, muss ich die Punkte bis hierhin kapieren:
Client verschlüsselt Anfrage mit seinem privaten Key, welches der Server mit dem öffentlichen Key wieder
entschlüsseln kann. die Antwort kann er mit dem öffentlichen Schlüssen wieder entschlüsseln, wo anschließend nur
der Client mit dem privaten Schlüssel entschlüsseln kann.
Nein. Wie ich bereits sagte, beschäftige dich zuerst mit der asymmetrischen und symmetrischen Verschlüsselung und nicht mit Protokollen wie SSL. Das ist vom Verständnis her sonst zu kompliziert.
Der Client braucht bei der Kommunikation mit dem Server überhaupt keine eigenen Schlüsseln.
Es funktioniert immer nach dem selben Prinzip, wie zB bei verschlüsselten E-Mails:
Wenn Person A Person B etwas verschlüsselt übertragen will, benötigt Person A im Prinzip nur den Public Key von Person B. Mit diesem kann er die Nachricht verschlüsseln, die nur Person B wieder entschlüsseln kann, da nur Person B den dazugehörenden Private Key besitzt.
Wenn allerdings Person B Person A etwas verschlüsselt zurückschicken will, kommt jetzt das Schlüsselpaar von Person A ins Spiel. Jetzt benötigt nämlich Person B den Public Key von Person A, um Person A etwas verschlüsselt zu übertragen, wobei wieder nur Person A diese Nachricht entschlüsseln kann, da nur Person A den private Key besitzt, mit dem das möglich ist.
(In Wirklichkeit ist es etwas komplizierter, wegen des hybriden Verfahrens. Aus Effizienzgründen wird nämlich nicht die gesamte Nachricht asymmetrisch verschlüsselt, sondern es wird diese zuerst symmetrisch verschlüsselt, und dieser symmetrische Schlüssel wird dann asymmetrisch verschlüsselt. Wenn jetzt noch eine digitale Signatur dazu kommt, wird's für den Anfang etwas kompliziert, wodurch ich es besser unerwähnt lasse, um dich ev. nicht noch mehr zu verwirren.)
Falls es dir vom Verständnis hilft, kann ich dir noch eine Textdatei zukommen lassen oder posten, in der ich SSL bei einem Apache auf Linux eingerichtet habe, angefangen von der Schlüsselerzeugung bishin zum Test.
Ich schreibe mir solche Dinge immer gerne auf, da man die einzelnen Schritte schnell wieder vergisst.
Markus
