nicht angemeldet
HTTPS und Zertifikate/Schlüssel
Hallo Forum,
wünsche allen zuerst mal schöne und erholsame Feiertage.
Hatte letztens ein Thread gestartet, was ein Login betrifft:
http://forum.de.selfhtml.org/?t=181122&m=1197620
Befasse mich zurzeit etwas mit Sessions und hab auch viel über Https gelesen. Das ganze verwirrt mich aber
einwenig, da ich nicht so ganz fit bin mit den Fachbegriffen.
Kann man mir das so grob bestätigen oder Schrittweise etwas besser ausbauen:
1. Server erhält von Zertifizierungsstelle ein öffentliches Zertifikat, indem auch ein public-key enthalten ist.
2. Client hat ein private-key (Wird evtl. selber erzeugt oder von Zertifizierungsstelle
geholt?)
3. 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.
4. 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.
5. (???) Wie erhält der Server nun den Premaster-Schlüssel? Wie entschlüsselt er zurück. Laut Wiki mit einem
eigenen Privaten-Schlüssel. Wo kommt der Private Schlüssel her? Wie konnte der Client den Privaten Schlüssel
berücksichtigen?
6. 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.
7. Dies wäre jetzt das SSL-Handschake und assymetrisch.
8. Da wir jetzt einen gemeinsamen Master-Schlüssel haben läuft der restliche eigentliche Datenaustausch dann
mit dem Master-Schlüssel symetrisch ab. (Hat der Master-Schlüssel nun einen öffentlichen und privaten Teil???)
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.
Wie man sieht, bin ich etwas verwirrt ;)
-
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
--
-
hey markus, wirklich voll voll lieb von dir, dir so viel mühe zu machen.
nochmals danke.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.)oki, ich schaue mir morgen früh nochmal assymetrie an, bevor ich mit vielen Fragen um mich herschmeiße.
Nur eine kurze Frage zu dem oberen Beispiel, weil mich das bei SSL interessiert hatte. Wenn ich Person B (Server) wie oben an PErson A (Client) wieder etwas verschlüsselt zurückschicken muss, kommt ja Private und Public-Key von Clienten ins Spiel. Die Frage ist, woher er die beiden Schlüsselpaare (?) herkriegt?
Erhält er die dann auch von der Zertifizerungsstelle oder wird es beim SSL-Handshake irgendwie generiert?Wie dem auch sei. Ich schau mir nochma assymetrie an ;)
Grüße
-
Hallo,
Nur eine kurze Frage zu dem oberen Beispiel, weil mich das bei SSL interessiert hatte. Wenn ich Person B (Server) wie oben an PErson A (Client) wieder etwas verschlüsselt zurückschicken muss, kommt ja Private und Public-Key von Clienten ins Spiel. Die Frage ist, woher er die beiden Schlüsselpaare (?) herkriegt?
Erhält er die dann auch von der Zertifizerungsstelle oder wird es beim SSL-Handshake irgendwie generiert?Bei Client-Server-Verbindungen identifiziert sich i.d.R. der Server beim Client mittels Zertifikat. Wie ich schon angesprochen habe, ist das "asymmetrische" bei der Client-Server-Kommunikation im Prinzip das Verschlüsseln des pre-master-secrets mit diesem Server-Public-Key, woraufhin ein Master Secret und daraus der symmetrische Sitzungsschlüssel generiert wird, über den dann die eigentliche Kommunikation stattfindet.
Bei der Client-Server-Kommunikation könnte man es auch so einrichten, dass sich der Client beim Server ebenfalls authentifizieren kann. Hier hat der Client ebenfalls ein Zertifikat, vor dem wiederum Schlüsselpaare einmalig zu generieren gewesen sind. Andernfalls könnte man ja auch kein Zertifikat erstellen lassen. Das Zertifikat muss natürlich wieder von einer Zertifizierungsstelle ausgestellt werden.Ich habe bewusst das Beispiel der E-Mail-Kommunikation gewählt, weil das Ganze bei der E-Mail-Kommunikation leichter zu verstehen ist. Hier gibt es kein derartiges Zertifikat, wie dir vll. schon mal aufgefallen ist, wenn du E-Mails verschlüsselt überträgst.
Und wenn du dich fragst, woher die Partner dann jeweils die öffentlichen Schlüsseln von dem anderen bekommen, ist das ganze einfach beantwortet.
Ist zB OpenSSL im Mail-CLient installiert, sucht er den Public Key automatisch auf einem Schlüsselserver, auf dem man den Public Key einmalig hochgeladen hat.
Dieses Schlüsselpaar wurde davor natürlich auch wieder einmalig generiert.
Die Schlüsseln sind sozusagen immer die Grundvoraussetzung für das verschlüsselte Übertragen von Daten.Markus
--
-
-
Moin!
- 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.
Gegenfrage: Wie vertrauenswuerdig sind die im Browser vorinstallierten Trustcenter? :)
Man kann fuer einige dieser Firmen mittlerweile behaupten, dass sie ihren Job schon mindestens einmal nicht richtig gemacht und Zertifikate unterschrieben haben, die bei sorgfaeltiger Pruefung niemals haetten unterschrieben werden duerfen. Sowas faellt natuerlich nur auf, wenn es bekannte Firmen trifft. Ein faelschlich ausgestelltes Zertifikat fuer "microsoft.com" ist mir noch so in Erinnerung.
Wie auffaellig wird das wohl sein, wenn man das Zertifikat irgendeines unbekannten Webshops falsch unterschreiben laesst?
- Sven Rautenberg
-
Hallo,
Gegenfrage: Wie vertrauenswuerdig sind die im Browser vorinstallierten Trustcenter? :)
Man kann fuer einige dieser Firmen mittlerweile behaupten, dass sie ihren Job schon mindestens einmal nicht richtig gemacht und Zertifikate unterschrieben haben, die bei sorgfaeltiger Pruefung niemals haetten unterschrieben werden duerfen. Sowas faellt natuerlich nur auf, wenn es bekannte Firmen trifft. Ein faelschlich ausgestelltes Zertifikat fuer "microsoft.com" ist mir noch so in Erinnerung.
Davon wusste ich gar nichts. Bei derart teuren Zertifikaten wie von VeriSign bin ich immer davon ausgegangen, dass die ihren Job absolut gewissenhaft machen.
Für ein neues Projekt im nächsten Jahr muss ich ebenfalls ein Zertifikat verwenden. Dabei werde ich um ein A-TRUST, VeriSign, CACert, usw.. auch nicht herum kommen, denn Zertifikate über den Webspace-Provider ausstellen zu lassen ist zwar möglich, aber dummerweise kommt dabei wieder diese Sicherheitsmeldung, die den einen oder anderen Besucher verwirren könnte.
Ärgerlicherweise sieht diese Sicherheitsmeldung in den neuen Firefoxen so dämlich aus, dass man auf den ersten Blick glaubt, es sei mit der Webseite irgend ein Fehler aufgetreten.Markus
--
-
Hi,
Ein faelschlich ausgestelltes Zertifikat fuer "microsoft.com" ist mir noch so in Erinnerung.
gerade vor ein paar Tagen hat sich jemand ein Zertifikat für mozilla.com geholt ;-)
Gruß,
Andreas.