Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
|
it:ssl [2014/06/14 17:01] wikisysop [Funktionsweise] |
it:ssl [2014/06/16 09:23] (aktuell) wikisysop [Funktionsweise] |
||
|---|---|---|---|
| Zeile 22: | Zeile 22: | ||
| ==== Funktionsweise ==== | ==== Funktionsweise ==== | ||
| - | Im Prinzip besteht >><fc #008000>SSL</fc><< aus drei Hauptkomponenten, dem privaten und öffentlichen Schlüsselpaar sowie dem digitalen Zertifikat. Bei der Generierung eines >><fc #008000>SSL Schlüssels</fc><< wird ein zweiteiliger Schlüssel erzeugt, der einen privaten und einen öffentlichen Schlüssel enthält. Um mit jemanden verschlüsselte Daten auzutauschen muss auch dieser solch ein Schlüsselpaar besitzen. Meine Nachricht wird nun mit meinem privaten und dem öffentlichen Schlüssel des Empfängers verschlüsselt. Der öffentliche Schlüssel meines Kommunikationspartners muss mir bekannt sein. Der Empfänger entschlüsselt nun die Daten wieder mit seinem privaten und meinem öffentlichen Schlüssel. Somit ist sichergestellt dass zum einen die Nachricht nur vom richtigen Empfänger gelesen werden kann und sie auch nur vom autorisierten Sender stammen kann. In der Praxis kann sich der private und öffentliche Teil eines Schlüssel auch in nur einen Schlüssel befinden, >>OpenSSL verfährt zB in dieser Art. Als Verschlüsselungsalgorithmen wird häufig >>RSA<<((http://de.wikipedia.org/wiki/RSA-Kryptosystem)) und >>DSA<<((http://de.wikipedia.org/wiki/Digital_Signature_Algorithm)) verwendet.((http://de.wikipedia.org/wiki/Public-Key-Verschl%C3%BCsselungsverfahren)) | + | Im Prinzip besteht >><fc #008000>SSL</fc><< aus drei Hauptkomponenten, dem privaten und öffentlichen Schlüsselpaar sowie dem digitalen Zertifikat. Bei der Generierung eines >><fc #008000>SSL Schlüssels</fc><< wird ein zweiteiliger Schlüssel erzeugt, der einen privaten und einen öffentlichen Schlüssel enthält. Um mit jemanden verschlüsselte Daten auzutauschen muss auch dieser solch ein Schlüsselpaar besitzen. Meine Nachricht wird nun mit meinem privaten und dem öffentlichen Schlüssel des Empfängers verschlüsselt. Der öffentliche Schlüssel meines Kommunikationspartners muss mir bekannt sein. Der Empfänger entschlüsselt nun die Daten wieder mit seinem privaten und meinem öffentlichen Schlüssel. Somit ist sichergestellt dass zum einen die Nachricht nur vom richtigen Empfänger gelesen werden kann und sie auch nur vom ausgewiesenen Sender stammen kann. In der Praxis kann sich der private und öffentliche Teil eines Schlüssel auch in nur einen Schlüssel befinden, >><fc #008000>OpenSSL</fc><< verfährt zB in dieser Art. Als Verschlüsselungsalgorithmen wird häufig >><fc #008000>RSA</fc><<((http://de.wikipedia.org/wiki/RSA-Kryptosystem)) und >><fc #008000>DSA</fc><<((http://de.wikipedia.org/wiki/Digital_Signature_Algorithm)) verwendet.((http://de.wikipedia.org/wiki/Public-Key-Verschl%C3%BCsselungsverfahren)) |
| <xterm>$ <fc #008000>openssl genrsa -out mykey.key 2048</fc> | <xterm>$ <fc #008000>openssl genrsa -out mykey.key 2048</fc> | ||
| Zeile 34: | Zeile 34: | ||
| <xterm>$ <fc #008000>openssl rsa -in mykey.key -pubout -text</fc></xterm> | <xterm>$ <fc #008000>openssl rsa -in mykey.key -pubout -text</fc></xterm> | ||
| + | ==== SSL Handshake ==== | ||
| Um nun wieder auf das Beispiel mit der >><fc #008000>SSL</fc><< verschlüsselten Webseite zurück zu kommen, schauen wir uns so eine Verbindung mal in seiner Entstehung genau an: | Um nun wieder auf das Beispiel mit der >><fc #008000>SSL</fc><< verschlüsselten Webseite zurück zu kommen, schauen wir uns so eine Verbindung mal in seiner Entstehung genau an: | ||
| Zeile 55: | Zeile 56: | ||
| Compression Algorithm: NONE</code> | Compression Algorithm: NONE</code> | ||
| - | * **Server Certificate:** In der >><fc #008000>Server Certificate</fc><< Nachricht sendet der Server dem Client eine Kopie seines digitalen Zertifikats. Dieses Zertifikat enthält neben diversen Angaben zur Identifizierung des Zertifikatsinhabers den >><fc #008000>Public Key</fc><<, also den öffentlichen Teil des Schlüssels des Servers. Der Client nutzt diesen Schlüssel um den Server zu authentifizieren, vor allem ob der >><fc #008000>FQDN</fc><< (zB <nowiki>www.prontosystems.org</nowiki>) der aufgerufenen >><fc #008000>URL</fc><< mit dem im Zertifikat hinterlegten >><fc #008000>FQDN</fc><< übereinstimmt. Des Weiteren nutzt der Client den öffentlichen Schlüssel des Servers zum Verschlüsseln des >><fc #008000>PreMaster Secret</fc><< | + | * **Server Certificate:** In der >><fc #008000>Server Certificate</fc><< Nachricht sendet der Server dem Client eine Kopie seines digitalen Zertifikats. Dieses Zertifikat enthält neben diversen Angaben zur Identifizierung des Zertifikatsinhabers auch den >><fc #008000>Public Key</fc><<, also den öffentlichen Teil des Schlüssels des Servers. Der Client nutzt diesen Schlüssel um den Server zu authentifizieren, vor allem ob der >><fc #008000>FQDN</fc><< (zB <nowiki>www.prontosystems.org</nowiki>) der aufgerufenen >><fc #008000>URL</fc><< mit dem im Zertifikat hinterlegten >><fc #008000>FQDN</fc><< übereinstimmt. Des Weiteren nutzt der Client den öffentlichen Schlüssel des Servers zum Verschlüsseln des >><fc #008000>PreMaster Secret</fc><< |
| + | |||
| + | * **Server Key Exchange:** Die >><fc #008000>Server Key Exchange</fc><< Nachricht ist optional und wird idR zB dann verwendet, wenn der Server kein Zertifikat besitzt mit dem der Premaster Key verschlüsselt werden darf. Manche Zertifikate enthalten öffentliche Schlüssel mit denen nur digitale Signaturen überprüft werden dürfen. In so einem Fall wird der öffentliche Schlüssel in der >><fc #008000>Server Key Exchange</fc><< Nachricht übermittelt. | ||
| + | |||
| + | * **Server Hello Done:** Schließt den Nachrichtenblock des Servers ab. | ||
| + | |||
| + | * **Client Key Exchange:** Der Client kennt nun den öffentlichen Schlüssel des Servers und generiert bei Verwendung von >><fc #008000>RSA</fc><< ein >><fc #008000>Premaster Secret</fc><<, verschlüsselt es mit dem öffentlichen Schlüssel des Servers oder dem temporär erzeugten Schlüssel aus der >><fc #008000>Server Key Exchange</fc><< Nachricht und sendet dies dem Server in einer >><fc #008000>Client Key Exchange</fc><< Nachricht. Alternativ dazu kann der >><fc #008000>Premaster Key</fc><< auch mit einer >><fc #008000>Diffie-Hellman-Schlüsselvereinbarung</fc><<((http://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch)) ausgehandelt werden. | ||
| + | |||
| + | * **Change Cipher Spec:** Das >><fc #008000>Premaster Secret</fc><< wandeln die beiden Kommunikationspartner mit Hilfe diverser Verschlüsselungsoperationen in ein >><fc #008000>Master Secret</fc><< um. Beide Kommunikationspartner teilen mit der nur ein Byte langen >><fc #008000>Change Cipher Spec</fc><< Nachricht((http://www.pierobon.org/ssl/ch2/ccs.htm)) dem jeweils anderen mit, dass das >><fc #008000>Master Secret</fc><< erfolgreich berechnet wurde. Das >><fc #008000>Master Secret</fc><< wird für den Rest der Session verwendet um die kryptografischen Schlüssel zu berechnen. | ||
| + | |||
| + | * **Encrypted Handshake Message:** Der erfolgreiche abgeschlossene >><fc #008000>SSL-Handshake</fc><< wird von beiden Kommunikationspartnern mit der >><fc #008000>Encrypted Handshake Message</fc><< quittiert. Danach wird die eigentliche Kommunikation mit den ausgehandelten Parametern ver- und entschlüsselt. | ||
| + | |||
| + | //''It's just that simple''// | ||
| + | //''<fc #800000>prontosystems.org - we are connecting more than computers</fc>''// | ||
| + | |||
| + | **Verwandte Artikel:** | ||
| + | [[:tux:root_ca|(Linux) Erstellen und Anwenden einer RootCA]] | ||
| + | [[:win:exc2010_assign_certificate_service|(Windows) Exchange 2010: Zuweisen von Diensten zu einem Zertifikat]] | ||
| + | |||
| + | --- //pronto 2014/06/14 20:54// | ||
| + | {{keywords>tls Secure Socket Layer Master Secret Server Key Exchange Certificate Change Cipher Spec CA}} | ||
