SSL -> So funktioniert es [prontosystems.org]

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
===== SSL -> So funktioniert es =====

 >><fc #008000>SSL</fc><<((http://publib.boulder.ibm.com/tividd/td/TRM/SC23-4822-00/de_DE/HTML/user277.htm)) (Secure Socket Layer) ist ein Verschlüsselungsprotokoll und wird idR zum sicheren Übertragen von Daten in Netzwerken verwendet. >><fc #008000>SSL</fc><< wurde bis zur Version 3.1 entwickelt und danach in >><fc #008000>TLS</fc><< weiter entwickelt, wo es heute bei Version 1.2 angekommen ist. Eine bekannte Implementierung ist zB >><fc #008000>OpenSSL</fc><<((http://de.wikipedia.org/wiki/OpenSSL)).

==== Wozu und Wofür SSL ====
 >><fc #008000>SSL</fc><< findet häufig Verwendung bei der Verschlüsselung der Datenübertragung von Webseiten, wie zB bei der Eingabe von Login Informationen oder anderen sensiblen Daten. Mittlerweile wird aber auch ganz gewöhnlicher HTTP-Traffic verschlüsselt, unterstützt wird dies nicht zuletzt durch immer leistungsfähigere Rechnerhardware. Man erkennt eine verschlüsselte Webseite uA durch die Angabe des >><fc #008000>HTTP__S__</fc><< Protokolls in der >><fc #008000>URL</fc><<. Ein weiteres Einsatzgebiet mit zunehmender Verbreitung ist die Verschlüsselung des E-Mail Verkehrs >><fc #008000>SMTP</fc><<. >><fc #008000>SSL</fc><< ist jedoch nicht exklusiv für >><fc #008000>HTTP</fc><< oder >><fc #008000>SMTP</fc><< entwickelt, wird jedoch von diesen beiden Technologien am meisten benutzt. 

 >><fc #008000>SSL</fc><< zieht zwischen der >><fc #008000>Transportschicht</fc><< und der >><fc #008000>Anwendungsschicht</fc><< eine weitere Schicht ein, den >><fc #008000>Secure Socket Layer</fc><<, wodurch im Prinzip jedes höhere Protokoll >><fc #008000>SSL</fc><< nutzen könnte.

Warum wird verschlüsselt? Bei >><fc #008000>HTTP</fc><< und >><fc #008000>SMTP</fc><< ohne >><fc #008000>SSL</fc><< wird die gesamte Kommunikation unverschlüsselt in Plain Text übertragen. Ein Datenstrom durchläuft vom Sender zum Empfänger etliche Stationen, wo an jeder mitgehört bzw. mitgelesen werden kann ohne irgendeinen Aufwand betreiben zu müssen. Eine E-Mail zB kann unverschlüsselt mit einer Postkarte verglichen werden die jeder lesen kann, der sie in die Finger bekommt. Würde man sich unverschlüsselt über das Internet an irgendeiner Webseite anmelden (Ebay, Amazon, Banken etc) würde das Passwort ebenfalls unverschlüsselt übertragen werden.  Die Technik des meist unbefugten Mitlesens von Datenverkehr in Netzwerken nennt man >><fc #008000>Man-In-The-Middle-Angriff</fc><<((http://de.wikipedia.org/wiki/Man-In-The-Middle-Angriff)). Es liegt auf der Hand, dass dies kein erstrebenswerter Zustand sein kann.

Ein weiterer Bestandteil von >><fc #008000>SSL</fc><< ist die zertifikatsbasierte Server- und Clientauthentifizierung, wobei die Serverauthentifizierung sehr häufig und die Clientauthentifizierung eher in Ausnahmefällen zum tragen kommt. Damit sichergestellt werden kann, dass zB ein Server auch der ist für den er sich ausgibt, werden digitale Zertifikate verwendet. Diese Zertifikate werden von beglaubigten >><fc #008000>CAs</fc><< (Certification Authority) ausgestellt. Damit eine >><fc #008000>CA</fc><< ein Serverzertifikat ausstellt muss der Antragsteller beweisen, dass er derjenige ist für den er sich ausgibt. Das kann verschiedenste Maßnahmen mit sich bringen aber im Grunde weiß die >><fc #008000>CA</fc><< wem sie da für was ein Zertifikat ausstellt und beglaubigt das ausgestellte Zertifikat in dem es digital signiert, quasi unterschrieben wird. Ein Internet-Browser hat nun eine Liste vertrauenswürdiger >><fc #008000>CAs</fc><< und überprüft das Serverzertifikat, welches der Server dem Client beim Verbindungsaufbau zur Überprüfung sendet. Dadurch soll zB verhindert werden, dass jemand den Login Ihres Onlinebanking Portals auf seine eigene Seite umleitet die genau so aussieht wie die echte und sie ahnungslos Ihre Zugangsdaten eintippen, die der Angreifer dann abgreifen kann. Diesen Angriff nennt man >><fc #008000>Phishing</fc><<((http://de.wikipedia.org/wiki/Phishing)) und gehört heute zu einem der am häufigsten verwendeten Angriffen.

==== Was SSL nicht kann ====

Da >><fc #008000>SSL</fc><< eine Implementierung in das Netzwerk Subsystem ist kann es auch nur Daten verschlüsseln, welche diesen Stack durchlaufen. Sitzt der Angreifer entweder auf dem Client- oder auf dem Server-System selbst, können dort die Daten auch gestohlen werden. Gespeicherte Daten sind ohne weitere Maßnahmen ebenfalls unverschlüsselt abgelegt. Auch auf dem Transportweg zwischen zwei Rechnern kann der >><fc #008000>SSL</fc><< verschlüsselte Datenstrom entschlüsselt, abgegriffen, wieder verschlüsselt und weitergeleitet werden, was allerdings zu einer Zertifikatswarnung führt, was dem aufmerksamen Anwender sofort skeptisch werden lässt. Meine Experimente mit >><fc #008000>Man-In-The-Middel-Angriffen</fc><< sind nun schon eine Weile her aber schon damals war es zB mit >><fc #008000>Ettercap</fc><<((http://de.wikipedia.org/wiki/Ettercap)) möglich eine >><fc #008000>SSL</fc><< verschlüsselte Kommunikation zu belauschen, was zumindest damals aber eine Menge "Lärm" verursacht hat. Man blieb dabei nicht unbemerkt.

Des Weiteren kann >><fc #008000>SSL</fc><< nicht die Adresse Ihres Kommunikationspartners verschleiern. Das bedeutet, dass ein Angreifer der nur Ihren Netzwerkverkehr belauscht ohne dabei selbst aktiv einzugreifen, in der Lage ist festzustellen mit wem Sie verschlüsselt kommunizieren, was ja auch schon mal nützlich sein kann. Das liegt zum einen daran, dass >><fc #008000>SSL</fc><< erst nach der Transportschicht, also nach dem TCP-Protokoll Anwendung findet und im TCP-Header bereits ausreichend Informationen vorhanden sind um beide Kommunikationsendpunkte zu identifizieren und zum anderen an der Tatsache dass einem >><fc #008000>HTTPS</fc><< Verbindungsaufbau meist eine DNS Abfrage vorausgeht, welche per se ja nicht >><fc #008000>SSL</fc><< verschlüsselt wird. 

Durch das Design von >><fc #008000>SSL</fc><<, dass der >><fc #008000>HTTP-Header</fc><< vollständig verschlüsselt wird, resultiert zB die Problematik, das [[:tux:apache_vhost|Namens-basierte vHosts]] in Webservern nicht so ohne weiteres funktionieren bzw. nur einer pro Server IP-Adresse. Der Webserver kann den SSL Traffic keinem bestimmten vHost in Form eines >><fc #008000>FQDNs</fc><< zuordnen, weil dieser noch im verschlüsselten >><fc #008000>HTTP-Header</fc><< steht.  

==== 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))

<xterm>$ <fc #008000>openssl genrsa -out mykey.key 2048</fc>
Generating RSA private key, 2048 bit long modulus
................................................................................+++
...+++
e is 65537 (0x10001)</xterm>

Das oben stehende Kommando erzeugt einen privaten RSA Schlüssel mit einer Länge von 2048 Bit, der öffentliche Teil des Schlüssels ist darin bereits enthalten. Sie können sich mit folgendem Kommando den öffentlichen teil des Schlüssels anzeigen lassen:

<xterm>$ <fc #008000>openssl rsa -in mykey.key -pubout -text</fc></xterm>

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:

Ein Webserver steht idR Stand-By und wartet auf Clientanfragen, demzufolge wird auch der Wunsch zu einer verschlüsselten Verbindung idR vom Client initiiert. Häufig ist es jedoch so, dass der Server für bestimmte Dienste nur eine sichere Verbindung anbietet und den Client dann quasi zum Aufbau einer sicheren Verbindung zwingt.

  * **TCP-Handshake:** Da der SSL Layer erst oberhalb dem Transport Layer (ISO-OSI Layer 4) aufbaut, wird der TCP-Handshake noch auf herkömmliche Art abgearbeitet. Das >><fc #008000>SYN</fc><<, >><fc #008000>SYN-ACK</fc><< und >><fc #008000>ACK</fc><< wird noch unverschlüsselt gesendet.

  * **Client Hello:** Der Client leitet nun mit einer >><fc #008000>Client Hello</fc><< Nachricht den >><fc #008000>SSL-Handshake</fc><< ein. Diese Nachricht enthält idR Angaben zu den unterstützen SSL/TLS Versionen, eine zufällig generierte Zahl, einen Session Identifier (SessionID), eine Lister der unterstützten Verschlüsselungs-Algorithmen und ggf weitere von der Implementierung abhängige Metadaten, welche vom Server ausgewertet und ggf verwendet werden können.\\ <code|Client Hello>ClientVersion 3,1
ClientRandom[32]
SessionID: None (new session)
Suggested Cipher Suites:
   TLS_RSA_WITH_3DES_EDE_CBC_SHA
   TLS_RSA_WITH_DES_CBC_SHA
Suggested Compression Algorithm: NONE</code>

  * **Server Hello:** Der Server antwortet darauf mit einem >><fc #008000>Server Hello</fc><< was im Wesentlichen die gleichen Angaben wie das >><fc #008000>Client Hello</fc><< enthält: unterstützte Versionen, eine zufällig generierte Zahl welche in Verbindung mit der vom Client gesendeten Zufallszahl verwendet wird um das >><fc #008000>Master Secret</fc><< für diese Verbindung zu generieren, unterstützte Verschlüsselungsalgorithmen, unterstützte Kompressionsalgorithmen und ggf weitere sitzungsspezifische Angaben.\\ <code|Server Hello>Version 3,1
ServerRandom[32]
SessionID: 8869f0c62bd609767ebf7a6cffb0eb941ef58b1443bd0a77
Use Cipher Suite:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
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 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.

  * **