Netzwerk- und Datensicherheit

Transkript

1 Martin Kappes Netzwerk- und Datensicherheit Eine praktische Einführung Zusatz: SSL/TLS Handshake Protocol und SSL/TLS Sockets unter Java Martin Kappes Fachhochschule Frankfurt am Main - University of Applied Sciences Fachbereich 2: Informatik und Ingenieurwissenschaften kappes@fb2.fh-frankfurt.de

2

3 Inhaltsverzeichnis 13 Netzwerkanwendungen v 13.3 Das World Wide Web v SSL und TLS v SSL/TLS Handshake Protocol v SSL/TLS unter Java viii Server-Authentifikation viii Client-Authentifikation xiv Das Handshake Protocol bei der Arbeit xvi 13.5 Übungsaufgaben xix Wiederholungsfragen xix Weiterführende Aufgaben xx Literaturverzeichnis xxi Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz- Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

4

5 13 Netzwerkanwendungen 13.3 Das World Wide Web SSL und TLS SSL/TLS Handshake Protocol Wir wollen uns nun das beim Aufbau einer SSL/TLS-Verbindung zu durchlaufende Handshake- Protocol etwas genauer betrachten. Es besteht aus vier Schritten, wobei in jedem der Schritte ein oder mehrere vordefinierte Nachrichten ausgetauscht werden können. Einige dieser Nachrichten sind dabei optional. Die einzelnen Nachrichten haben folgende Bedeutung: ClientHello: Ist die erste Nachricht beim Handshake und enthält unter anderem folgende Bestandteile: Protocol Version: Gibt die vom Client verwendete Protokollversion an. Zeitstempel: Im Unix-Zeitformat. Kann von der Applikation verwendet und ausgewertet werden, wird von SSL/TLS aber nicht weiter verwendet. Client Server ClientHello ServerHello, [Certificate], [ServerKeyExchange], [CertificateRequest], ServerHelloDone [Certificate], ClientKeyExchange, [CertificateVerify] [ChangeCipherSpec], Finished [ChangeCipherSpec], Finished verschlüsselter Datenaustausch Abbildung 13.20: SSL/TLS Handshake Protocol nach [RFC 5246]. Optionale Nachrichten sind in eckige Klammern gesetzt.

6 vi 13 Netzwerkanwendungen SessionID: Hier kann die ID einer bereits bestehenden oder früheren Session zwischen Client und Server angegeben werden. Hierdurch können entweder weitere unabhängige Sessions aufgebaut werden oder eine frühere Session wiederaufgenommen werden, ohne dass nochmals der komplette Handshake durchlaufen werden muss. Cipher Suites: Der Client sendet eine nach Präferenz absteigend sortierte Liste der möglichen Kombinationen von Algorithmen, die zur Authentifikation, Verschlüsselung und Integritätssicherung verwendet werden können. Compression Method: Bietet die Möglichkeit, dem Server eine Liste mit Datenkompressionsverfahren vorzuschlagen. Der Client muss als eine mögliche Kompressionsmethode auch immer keine Kompression mitangeben, so dass der Server hier immer eine passende Methode findet. ServerHello: Die Antwort des Servers auf das ClientHello. Sofern der Server in der Liste der möglichen Cipher Suites des Client (mindestens) eine findet, die er auch unterstützt,wird diese Nachricht direkt als Antwort an den Client gesendet. Findet der Server keine akzeptable Cipher Suite, so bricht der Handshake mit einer Fehlermeldung ab. Das ServerHello beinhaltet Folgendes: Protocol Version: Der Server wählt als Protokollversion die höchste mögiche Protokollversion von SSL/TLS, die auf beiden Seiten möglich ist. Falls der Server die im ClientHello angegebene Protokollversion unterstützt, so wird diese verwendet, ansonsten die höchste vom Server unterstützte Protokollversion. Session ID: Der Server gibt die ID der Session zurück. Dies kann eine neue ID sein oder im Fall der Wiederaufnahme einer Session deren frühere ID. Cipher Suite: Das Element aus der Liste möglicher Cipher Suites des ClientHello, welches der Server zur Verwendung ausgewählt hat. Compression Method: Das Element aus der Liste möglicher Compression Methods des ClientHello, welches der Server zur Verwendung ausgewählt hat. (Server) Certificate (optional): Sofern die ausgehandelte Cipher Suite Zertifikate zur Authentifizierung einsetzt, muss der Server dem Client ein Zertifikat zur Authentifikation übermitteln. Nahezu alle Verwendungen von SSL/TLS, speziell im Kontext von Web- Applikationen, verwenden ausschließlich entsprechende Cipher Suites. Das Zertifikat muss mit den in der Cipher Suite ausgehandelten Algorithmen kompatibel sein (also beispielsweise einen öffentlichen RSA-Schlüssel beinhalten, wenn RSA als Public-Key-Verfahren ausgewählt wurde). Der Server kann dem Client nicht nur das Serverzertifikat, sondern die ganze Zertifikatskette schicken, also das Serverzertifikat und die Zertifikate aller beteiligten CAs bis zur Root-CA (wobei das Root-CA Zertifikat auch weggelassen werden darf). Die Zertifikate sind in der Regel im X.509-Format in Version 3 [X.509], siehe Abschnitt ServerKeyExchange (optional): In bestimmten Situationen reichen die in einem Zertifikat enthaltenen Informationen nicht aus, um ein Master Secret zu konstruieren, aus dem wiederum der Session Key für die Verbindung abgeleitet wird. In diesen Fällen oder wenn

7 13.3 Das World Wide Web vii kein Zertifikat verwendet wird (was wie gesagt in den üblichen Anwendungsfällen so gut wie nie vorkommt), werden in dieser Nachricht die notwendigen Daten übertragen, um später einen Session Key erzeugen zu können. CertificateRequest (optional): Falls der Server sich mit einem Zertifikat authentifiziert, kann er auch fordern, dass der Client dies ebenfalls tut und sendet in diesem Fall die CertificateRequest Nachricht. Sie entält eine Liste der vom Server in einem Zertifikat akzeptierten kryptographischen Verfahren zur Authentifikation und eine Liste der CAs, welcher der Server vertraut. Ist die Liste leer, kann der Client ein von einer beliebigen CA beglaubigtes Zertifikat zurücksenden. ServerHelloDone: Diese Nachricht sendet der Server am Ende des zweiten Schritts des Handshake und signalisiert so, dass nun der Client wieder an der Reihe ist. Sie beinhaltet keine weiteren Informationen. (Client) Certificate: Wenn der Server ein Zertifikat des Client angefordert hat, reagiert der Client mit dieser Nachricht und sendet, falls vorhanden, ein passendes Zertifikat zurück. Sofern der Client kein Zertifikat mit den geforderten kryptographischen Eigenschaften hat, sendet der Client die Nachricht ohne ein Zertifikat an den Server zurück. Der Server entscheidet dann, ob er den Handshake weiter durchführen oder mit einer Fehlermeldung abbrechen möchte. Genauso verfährt der Server, falls in der Zertifikatskette des Zertifikats keine CA enthalten ist, welcher der Server traut. ClientKeyExchange: Diese Nachricht entält entweder das mit dem öffentlichen Schlüssel des Servers verschlüsselte sogenannte Premaster Secret (aus dem dann das Master Secret generiert wird) oder aber andere Parameter, mittels derer der Server das Premaster Secret erzeugen kann. Nach Eintreffen dieser Nachricht beim Server verfügen in jedem Fall beide Seiten über das Premaster Secret. CertificateVerify (optional): Während die Authentizität des Servers durch Kenntnis des Premaster Secrets sichergestellt ist, verifiziert der Client dem Server gegenüber seine Authentizität durch diese Nachricht, sofern ein Zertifikat zur clientseitigen Authentifikation verwendet wird. Dies geschiet, indem beispielsweise ein Hash der bisher ausgetauschten Nachrichten des Handshake vom Client signiert und hier übertragen wird. ChangeCipherSpec: Diese Nachricht gehört zum ChangeCipherSpec Protocol und signalisiert, dass die weitere Kommunikation unmittelbar nach Erhalt der Nachricht mittels der gerade ausgehandelten kryptographischen Materialien und Algorithmen erfolgt. Diese Nachricht wird sowohl vom Client als auch vom Server übertragen. Finished: Diese Nachricht ist als erste durch die gerade ausgehandelten kryptographischen Algorithmen geschützt. Beide Seiten verifizieren den Inhalt der Finished-Nachricht und im Erfolgsfall kann die Session dann zum Datenaustausch verwendet werden. Das Handshake Protocol bildet den Kern der Aushandlung der kryptographischen Verfahren. Das Change Cipher Spec Protokoll ist das einfachste Protokoll, den Sie in diesem Buch begegnen, denn es besteht nur aus einer einzigen Nachricht, die Sie oben bereits kennengelernt haben, und das Alert Protocol dient ausschließlich der Signalisierung von Warnungen und Fehlern.

8 viii 13 Netzwerkanwendungen SSL/TLS unter Java Server-Authentifikation In Abschnitt hatten wir uns mit SSL/TLS als Protokoll zur Gewährleistung vertraulicher, authentifizierter und integritätsgeschützter Ende-zu-Ende-Datenübertragung auseinandergesetzt. Wir wollen nun kurz skizzieren, wie ein SSL-Server unter Java zum Einsatz gebracht werden kann. Hierzu wollen wir das in vorgestellte Java-Programm InfoSocketServer entsprechend modifizieren. InfoSocketServer wartet auf eingehende TCP-Verbindungen auf Port 80 und schickt einige Informationen über die Verbindung an den Client zurück. Wir modfizieren diese Klasse nun zur Klasse SSLInfoSocketServer, welche dieselbe Funktionalität besitzt, aber die TCP-Verbindung zusätzlich durch SSL schützt. Der entsprechend veränderte Quellcode sieht wie folgt aus: import java.net.*; import java.io.*; import javax.net.*; import javax.net.ssl.*; class SSLInfoSocketServer { public static void main(string[] arg) { try { // Erzeugen eines SSLServerSocket auf Port 443 unter Verwendung // der SSLServerSocketFactory ServerSocketFactory meinefactory = SSLServerSocketFactory.getDefault(); ServerSocket meinserversocket = meinefactory.createserversocket(443); // ServerSocket meinserversocket ist aktiv und // wartet auf Port 443 auf eingehende SSL-Verbindungen while (true) { try{ // Blockierendes Warten auf eingehende Verbindungen Socket meinsocket = meinserversocket.accept(); // Verbindung ist eingegangen und an den Socket meinsocket // gebunden // Ab hier identische Behandlung // wie im Code in Abschnitt // // // // bis zum Schlieÿen des Sockets meinsocket.close(); } catch (Exception e) { System.out.println("Problem bei eingehender Verbindungsanfrage: "+e); } } } catch (Exception e) { System.out.println("Problem beim Erzeugen des SSLServerSocket: "+e); }

9 13.3 Das World Wide Web ix } } Die notwendigen Änderungen im Quellcode gegenüber der Variante ohne SSL sind fast schon banal. Zum einen wurden die Statements import javax.net.*; import javax.net.ssl.*; ergänzt. javax.net.ssl ermöglicht eine sehr einfache Verwendung von SSL unter Java. Abgesehen von einem weiteren try/catch-block zur Ausnahmebehandlung bei Problemen beim Aufbau der Verbindung, der notwendig ist, da im Gegensatz zu gewöhnlichen TCP-Verbindungen beim Aufbau von SSL-Verbindung doch häufiger mit dem Auftreten von Ausnahmen zu rechnen ist, wurde eigentlich nur die ursprüngliche Codezeile ServerSocket meinserversocket=new ServerSocket(80) aus InfoSocketServer durch die beiden Zeilen ServerSocketFactory meinefactory = SSLServerSocketFactory.getDefault(); ServerSocket meinserversocket = meinefactory.createserversocket(443); ersetzt. Während wir also in der unverschlüsselten Version des Programms direkt einen ServerSocket instantiiert haben, verwenden wir in der SSL-Version Factory-Klassen, nämlich die Klassen ServerSocketFactory und SSLServerSocketFactory. Factory-Klassen ermöglichen eine einfache und vor allem flexible Instantiierung anderer Klassen. Wird eine Klasse direkt mittels new im Programmcode instantiiert, muss dem verwendeten Konstruktor oft eine Fülle von Informationen mitgegeben werden, die oft auch von der aktuellen Laufzeitumgebung und anderen Parametern des Programms abhängen. Anstatt sich um all diese Details bei der Instantiierung kümmern zu müssen, werden Factory-Klassen verwendet, die sich Hinter den Kulissen um die ganzen Details kümmern und dann eine entsprechende Instanz der gewünschten Klasse zurückliefern. Mit ServerSocketFactory meinefactory = SSLServerSocketFactory.getDefault() erhält man eine aktuelle Instanz von SSLServerSocketFactory, die dann in ServerSocket meinserversocket = meinefactory.createserversocket(443) benutzt wird, um die neue Instanz meinserversocket der Klasse ServerSocket zu erhalten. Genauer werden Instanzen der Klassen SSLServerSocket und SSLSocket verwendet, die jedoch Unterklassen von ServerSocket bzw. Socket sind und damit identisch benutzt werden können. Dies erlaubt die einfache Wiederverwendung des Codes aus dem Beispiel ohne SSL. Der neue ServerSocket wartet auf Port 443, also dem Standardport für HTTPS, auf eingehende Verbindungen. Die Factory-Klasse nimmt uns eine Menge an Arbeit ab, die eigentlich bei der Instantiierung eines SSL-Servers notwendig wäre. Beispielsweise muss dem Server ja mitgeteilt werden, welches Zertifikat (mit zugehörigem privaten Schlüssel) bei der Authentifikation gegenüber dem

10 x 13 Netzwerkanwendungen Client verwendet werden soll. Daneben gibt es noch eine ganze Fülle weiterer zu spezifizierender Parameter, wie etwa die zu verwendenden Verschlüsselungsalgorithmen. Um all das kümmert sich die Factory-Klasse im Hintergrund, deshalb ist die Veränderung des Programmcodes gegenüber der Variante ohne SSL so einfach. Allerdings wird diese Einfachhheit dadurch erkauft, dass man die entsprechenden Informationen über zu verwendende Schlüssel und Zertifikate und Ähnliches auf andere Weise zur Verfügung stellen muss, etwa als Parameter beim Start des Java-Programms in der Java Virtual Machine. Java bietet eine einfache Möglichkeit, wie entsprechende Schlüsselpaare und Zertifikate erstellt und verwaltet werden können, nämlich das keytool. Mittels dieses Dienstprogramms wollen wir nun die notwendigen Schlüssel und ein Zertifikat erzeugen, um im in Abbildung 7.2 gezeigten Szenario das Experiment aus Abschnit zu wiederholen, diesmal allerdings mit einer SSL-gesicherten Verbindung. Auf Rechner wollen wir obiges Java-Programm zum Einsatz bringen. Daher lassen wir es dort in Java Bytecode übersetzen. Allerdings können wir es noch nicht starten, da wir zunächst die entsprechenden Schlüssel und Zertifikate benötigen. Mit dem Befehl keytool -keystore unserkeystore -genkeypair -keyalg RSA starten wir die Erzeugung eines neuen RSA-Schlüsselpaares nebst zugehörigem selbst-signiertem Zertifikat, das in einem Schlüsselspeicher mit dem Namen unserkeystore abgelegt werden soll. Zunächst werden wir nach dem Passwort für diesen Schlüsselspeicher gefragt. Da es ihn noch nicht gibt, können wir ein beliebiges Passwort wählen, wir nehmen hier beispiel. Nun kommen die üblichen Fragen nach den für ein X.509-Zertifikat notwendigen Feldern (siehe Abschnitt ). Ebenso muss noch ein Passwort für den Schlüssel eingegeben werden, wir wählen dasselbe Passwort wie für den Schlüsselspeicher. Wenn man entsprechend vorgeht und alle Zertifikatsfelder leer lässt, sollte der Nutzerdialog ungefähr so aussehen: pc-y:~ # keytool -keystore unserkeystore -genkeypair -keyalg RSA Geben Sie das Keystore-Passwort ein: Geben Sie das Passwort erneut ein: Wie lautet Ihr Vor- und Nachname? [Unknown]: Wie lautet der Name Ihrer organisatorischen Einheit? [Unknown]: Wie lautet der Name Ihrer Organisation? [Unknown]: Wie lautet der Name Ihrer Stadt oder Gemeinde? [Unknown]: Wie lautet der Name Ihres Bundeslandes oder Ihrer Provinz? [Unknown]: Wie lautet der Landescode (zwei Buchstaben) für diese Einheit? [Unknown]: Ist CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown richtig? [Nein]: ja

11 13.3 Das World Wide Web xi Abbildung 13.21: Erste Anzeige des Browsers beim Aufruf des Dienstes auf Geben Sie das Passwort für <mykey> ein. (EINGABETASTE, wenn Passwort dasselbe wie für Keystore): pc-y:~ # Nun können wir loslegen und den SSLInfoSocketServer starten. Hierzu müssen wir aber über die Kommandozeile der JVM noch mitteilen, dass wir unseren gerade erzeugten privaten Schlüssel und das zugehörige Zertifikat zur Authentifikation bei den Clients verwenden wollen. Hierzu müssen wir das Zertitikat angeben und auch das gerade gewählte Passwort. Dies geschieht, indem wir das Programm mit dem Befehl java -Djavax.net.ssl.keyStore=unserkeystore -Djavax.net.ssl.keyStorePassword=beispiel SSLInfoSocketServer starten. Nun versuchen wir, von Rechner aus auf diesen Dienst zuzugreifen. Wir verwenden hierzu wieder den Webbrowser Firefox [Moz-Web]. Wir müssen dem Browser mitteilen,

12 xii 13 Netzwerkanwendungen Abbildung 13.22: Hinzufügen einer Ausnahmeregel. dass er sich per SSL mit dem Ziel verbinden soll. Da unser Server auf dem https-standardport läuft, reicht es, in der Adresszeile des Browsers einzugeben. Durch Beobachtung des Netzwerkverkehrs mittels Wireshark oder Ethereal können wir feststellen, dass tatsächlich SSL verwendet wird. Betrachten wir das Resultat unserer Bemühungen im Browser, so ist das Ergebnis schon recht erfreulich: Wir erhalten die in Abbildung gezeigte Fehlermeldung. Dieses Verhalten kommt nicht überraschend, denn wir verwenden ein selbsterstelltes und nicht von einer bekannten CA unterschriebenes Zertifikat ohne Informationen über die Identität des Besitzers. Trotzdem wollen wir diesem Zertifikat vertrauen und wählen deshalb die Option Ausnahmeregel hinzufügen. Nach weiteren und wie wir wissen durchaus berechtigten Warnmeldungen laden wir das Zertifikat nochmals und bestätigen wie in Abbildung gezeigt die Ausnahme. Anschließend funktioniert die Anwendung so, wie wir es auch schon von der unverschlüsselten Variante kennen. Abbildung zeigt einen entsprechenden Screenshot. Wenn das Zertifikat dauerhaft gespeichert wurde, kann es anschließend über den Menupunkt Zertifikate (unter Optionen/Erweitert) angesehen werden, siehe Abbildung Wählen wir dort Bearbeiten, so haben wir die Möglichkeit festzulegen, für welche Verwendungszwecke wir das Zertifikat als vertrauenswürdig erachten, siehe Abbildung Eine ganz ähnliche Meldung hatten wir uns beim Import von Zertifikaten in Thunderbird in Kapitel 3 schon einmal angesehen (siehe Abblidung 3.6). Legen wir dort fest, dass dieses Zertifikat zur Identifikation von Webseiten verwendet werden kann, so akzeptiert Firefox beim nächsten Aufruf unseres

13 13.3 Das World Wide Web xiii Abbildung 13.23: Erfolgreicher Aufruf des SSLInfoSocketServer auf von Client aus. Abbildung 13.24: Betrachten des Zertifikats im Zertifikatsspeicher des Browsers. SSL-Dienstes auf das verwendete Zertifikat klaglos und gelangen sofort und ohne Fehlermeldung oder Zertifikatsimport zur in Abbildung gezeigten Darstellung der Webseite im Browser. Die Verwendung und Verwaltung von Schlüsseln und Zertifikaten mit Java ist natürlich nicht an die Verwendung des keytool gekoppelt. Es ist auch möglich, auf anderem Wege erstelltes kryptographisches Material einzusetzen. Auch dies wollen wir nun anhand eines einfachen Beispiels praktisch ausprobieren. Zur Erstellung und Verwaltung der Zertifikate verwenden wir jetzt OpenSSL [OpenSSL-Web], das wir ja bereits in Abschnitt eingesetzt hatten. Genau wie dort beschrieben bauen wir eine einfache Certificate Authority auf und erzeugen ein von dieser CA unterschiebenes Zertifikat, allerdings diesmal nicht für Max Mustermann, sondern für unseren Server. Wir tragen also im Feld Common Name (CN) statt Max Mustermann den Wert ein. Als Passwort verwenden wir wie oben beispiel.

14 xiv 13 Netzwerkanwendungen Abbildung 13.25: Festlegung der Vertrauenswürdigkeit des Zertifikats für bestimmte Verwendungszwecke. Wenn wir ganz analog vorgehen, erhalten wir am Ende unserer Bemühungen eine Datei im PKCS #12-Format, welche den privaten Schlüssel und das zugehörige von der CA unterschriebene Zertifikat für beinhalten. Wir gehen im Folgenden davon aus, dass diese Datei den Namen server-credentials.p12 trägt. Außerdem benötigen wir noch das Zertifikat unserer CA ca-cert.der. Als erstes importieren wir dieses Zertifikat ca-cert.der als Root-CA-Zertifikat in Firefox auf dem Client , indem wir den Zertifikate-Manager aufrufen und unter Zertifizierungsstellen die Option Importieren wählen. Anschließend legen wir noch fest, dass wir dem neu importierten Zertifikat zur Identifizierung von Websites trauen. Nun starten wir auf den SSLInfoSocketServer, wobei wir über Parameter der JVM angeben müssen, dass Zertifikat und Schlüssel im PKCS #12-Format vorliegen und natürlich wieder Dateinamen und Passwort angeben. Dies geschieht durch den Aufruf java -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStore=server-credentials.p12 -Djavax.net.ssl.keyStorePassword=beispiel SSLInfoSocketServer Nun kontaktieren wir von aus den SSLInfoSocketServer, wiederum durch das Eingeben von in der Adresszeile des Browsers. Da wir das zugehörige Root-CA-Zertifikat bereits installiert haben und der Common Name des Zertifikats mit der aufgerufenen Webadresse übereinstimmt, erhalten wir diesmal sofort und ohne Fehlermeldung das in Abbildung gezeigte Ergebnis Client-Authentifikation Bisher hat sich zwar der Server beim Client authentifiziert, eine Authentifikation des Client gegenüber dem Server erfolgte aber nicht. Dies entspricht den derzeitigen typischen Gepflogenheiten im Internet, nach denen sich der Client erst nach Aufbau der Verbindung auf anderem Weg authentifiziert, beispielsweise durch Benutzernamen und Passwort. Es wurde ja schon erwähnt, dass SSL/TLS auch die Möglichkeit bietet, den Client ganz analog durch Verwendung von Zertifikaten zu authentifizieren. Wir wollen dies nun durchführen.

15 13.3 Das World Wide Web xv Als erstes müssen wir unser Programm SSLInfoSocketServer um eine weitere Zeile ergänzen. Sie legt fest, dass beim Verbindungsaufbau auch eine Authentifikation des Client erfolgen muss. Wir ergänzen sie direkt hinter der Instantiierung von meinserversocket: ((SSLServerSocket) meinserversocket).setneedclientauth(true); Wenn wir das Programm neu übersetzen und wie gewohnt starten, erhalten wir beim Verbindungsaufbau eine Fehlermeldung, da Firefox bisher noch nicht über geeignete Zertifikate und Schlüssel verfügt, um sich bei unserem Server zu authentifizieren. Diese wollen wir nun erzeugen. Hierzu verwenden wir wieder OpenSSL und erstellen eine neue CA. Nach den nun schon bekannten Schritten haben wir eine weitere Datei im PKCS #12-Format, in welcher sich der private Schlüssel und das zugehörige von der CA unterschriebene Zertifikat für den Client befinden. Wir gehen im Folgenden davon aus, dass diese Datei den Namen client-credentials.p12 trägt, und das Zertifikat der neuen CA ca2-cert.der. Wir importieren nun als erstes wieder das CA-Zertifikat in Firefox und legen fest, dass wir ihm für alle Zwecke trauen. Anschließend importieren wir das unterschiebene Zertifikat mit dem privaten Schlüssel, indem wir im Zertifikate-Menu unter Ihre Zertifikate auf Importieren gehen und dann die Datei client-credentials.p12 importieren. Hierbei muss das bei der Erstellung der Datei mit OpenSSL gewählte Passwort nochmals eingegeben werden. Nach Abschluss dieses Schrittes kann Firefox dieses Zertifikat zur Authentifikation bei Servern verwenden. Würden wir jetzt SSLInfoSocketServer starten und mit Firefox darauf zugreifen, käme allerdings wiederum eine Fehlermeldung. Sicherlich haben Sie dieses Verhalten erwartet, denn das von uns verwendete Zertifikat stammt von einer CA, die SSLInfoSocketServer bisher unbekannt ist. Das wollen wir nun ändern. Hierzu importieren wir zunächst das CA-Zertifikat ca2-cert.der mit keytool in einen für Java einfach zugänglichen Schlüsselspeicher mit dem Namen clientcertstore. Dies geschieht mit dem Befehl keytool -keystore clientcertstore -importcert -file ca2-cert.der Als Passwort für den Keystore nehmen wir wieder beispiel. Nun müssen wir nur dem SSLInfoSocketServer die Information liefern, wo sich die zur Authentifikation des Client zu verwendenden Zertifikate befinden. Dies geschieht wiederum durch Übergabe von Parametern beim Programmstart: java -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStore=server-credentials.p12 -Djavax.net.ssl.keyStorePassword=beispiel -Djavax.net.ssl.trustStore=clientcertstore -Djavax.net.ssl.trustStorePassword=beispiel SSLInfoSocketServer Nun greifen wir mit Firefox wieder auf den Server zu. Wir erhalten eine Meldung, dass der Server eine Authentifikation mittels Zertifikat fordert, siehe Abbildung Wenn wir mit OK bestätigen, findet nun eine erfolgreiche gegenseitige Authentifikation von Server und Client statt, und die Verbindung wird erfolgreich aufgebaut.

16 xvi 13 Netzwerkanwendungen Abbildung 13.26: Firefox-Meldung bei clientseitiger Authentifizierung über Zertifikate Das Handshake Protocol bei der Arbeit Abschließend wollen wir uns betrachten, was eigentlich genau beim Aufbau der SSL/TLS- Verbindung abläuft. Auch wenn wir selbst nicht eine Zeile Code hierzu geschrieben haben, so können wir doch den Klassen der anderen Programmierer, die uns diese Arbeit abgenommen haben, bei der Arbeit zuschauen. Das macht gleich doppelt Spaß. Wenn wir den SSLInfoSocketServer zusätzlich mit der Option -Djavax.net.debug=ssl:handshake:verbose starten, schalten wir den Debugging-Modus so ein, dass wir die beim SSL/TLS-Handshake ausgetauschten Daten beobachten können, allerdings natürlich nur indirekt. Im Debug-Modus gibt uns das Programm zurück, was der Programmierer für relevant hielt, nicht was wirklich ausgetauscht wurde. Trotzdem ist dies eine sehr gute Möglichkeit, sich einmal einen SSL/TLS- Handshake aus der Nähe zu betrachten. Im Folgenden betrachten wir einen erfolgreichen Versuch im gerade eben betrachteten letzten Szenario mit Clientauthentifikation. Nach dem Start des Programms (und bevor wir eine Verbindungsanfrage starten) erhalten wir zunächst Informationen über die verwendeten Schlüssel und Zertifikate. Auslassungen wurden wieder mit gekennzeichnet. keystore is : server-credentials.p12 keystore type is : pkcs12 keystore provider is : init keystore init keymanager of type SunX509 *** found key for : 1 chain [0] = [

17 13.3 Das World Wide Web xvii [ Version: V3 Subject: CN=Servercert, OU=TEST, O=FH Frankfurt TEST, ST=Some-State, C=DE Signature Algorithm: SHA1withRSA, OID = ] *** truststore is: clientcertstore truststore type is : jks truststore provider is : init truststore adding as trusted cert: Subject: CN=CA2, O="FH Frankfurt ", L=Frankfurt, ST=Hessen, C=DE Issuer: CN=CA2, O="FH Frankfurt ", L=Frankfurt, ST=Hessen, C=DE Algorithm: RSA; Serial number: 0xac53987c35a2dc14 Valid from Sun Feb 22 13:24:07 CET 2009 until Tue Mar 24 13:24:07 CET 2009 Wir wir also sehen, verwendet der Server die in der Kommandozeile angegebenen Credentials, um sich zu authentifizieren und akzeptiert vom Client Zertifikate, welche durch die von uns vorher in clientcertstore angegebene CA (CA2 FH Frankfurt) ausgestellt wurden. Beginnen wir nun von einen Verbindungsaufbau, so erhalten wir zunächst die Meldung, dass eine Verbindung eingegangen ist und erhalten anschließend die Daten der ClientHello- Nachricht: Accepted connection from / :53064 main, READ: SSLv3 Handshake, length = 111 *** ClientHello, SSLv3 RandomCookie: GMT: bytes = { 30, 217, 198, 112, 20, 175, 66, 30, 241, 221, 117, 145, 35, 107, 116, 169, 213, 215, 42, 105, 121, 32, 52, 72, 168, 184, 239, 152 } Session ID: {73, 249, 211, 97, 39, 143, 17, 228, 61, 42, 194, 29, 199, 11, 180, 51, 50, 15, 59, 246, 137, 238, 47, 5, 171, 132, 25, 77, 42, 196, 179, 76} Cipher Suites: [Unknown 0x0:0x88, Unknown 0x0:0x87, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, Unknown 0x0:0x84, TLS_RSA_WITH_AES_256_CBC_SHA, Unknown 0x0:0x45, Unknown 0x0:0x44, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, Unknown 0x0:0x41, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA] Compression Methods: { 0 } *** Wir sehen also, dass alle bereits in Abschnitt genannten Bestandteile im ClientHello enthalten sind. Der Server wählt, wie nachstehend zu sehen ist, TLS_DHE_RSA_WITH_AES_256_CBC_SHA als Ciphersuite und antwortet nun mit dem ServerHello. Ebenso wird das Server-Zertifikat an den Client gesendet, ein Diffie-Hellman Schlüsselaustausch eingeleitet und ein Zertifikat vom Client angefordert. Die im Diffie-Hellman Austausch übermittelten Daten werden vom Server mit

18 xviii 13 Netzwerkanwendungen dem privaten Schlüssel signiert, der zum im Zertifikat angegebenen öffentlichen Schlüssel passt. Hierdurch kann der Client überprüfen, ob das Zertifikat tatsächlich für diesen Server ausgestellt wurde. Sofern er der ausstellenden CA vertraut ist damit die Authentizität des Servers wie in Kapitel 3 beschrieben sichergestellt. Damit der Client weiss, welche CAs der Server akzeptiert, wird außerdem eine Liste der (aus Sicht des Servers) vertrauenswürdigen CAs übertragen. Diese beinhaltet nur ein Element, da ja nur ein Zertifikat in clientcertstore enthalten ist. %% Created: [Session-1, TLS_DHE_RSA_WITH_AES_256_CBC_SHA] *** ServerHello, SSLv3 RandomCookie: GMT: bytes = { 73, 98, 201, 36, 12, 196, 131, 5, 177, 23, 189, 109, 89, 92, 184, 34, 135, 224, 241, 197, 222, 82, 59, 196, 169, 107, 67, 101 } Session ID: {73, 249, 211, 250, 130, 193, 230, 35, 139, 236, 193, 73, 53, 146, 142, 15, 232, 109, 158, 0, 240, 251, 246, 128, 225, 92, 82, 138, 55, 9, 240, 174} Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA Compression Method: 0 *** Cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA *** Certificate chain chain [0] = [ [ Version: V3 Subject: CN=Servercert, OU=TEST, O=FH Frankfurt TEST, ST=Some-State, C=DE Signature Algorithm: SHA1withRSA, OID = Key: Sun RSA public key, 1024 bits Validity: [From: Fri Feb 20 09:57:26 CET 2009, To: Sat Feb 20 09:57:26 CET 2010] Issuer: OU=TEST, O=FH Frankfurt TEST, L=Frankfurt, ST=Some-State, C=DE SerialNumber: [ 01] *** *** Diffie-Hellman ServerKeyExchange Signed with a DSA or RSA public key *** CertificateRequest Cert Types: RSA, DSS Cert Authorities: <CN=CA2, O="FH Frankfurt ", L=Frankfurt, ST=Hessen, C=DE> *** ServerHelloDone Der Client sendet nun das Client-Zertifikat zurück. Ebenso sendet der Client die seinerseits erzeugten Elemente des Diffie-Hellman Schlüsselaustauschs, ebenfalls entsprechend signiert. *** Certificate chain chain [0] = [ [ Version: V3 Subject: CN=Martin Kappes Client, O="FH Frankfurt ", ST=Hessen, C=DE Signature Algorithm: SHA1withRSA, OID = Key: Sun RSA public key, 1024 bits

19 13.5 Übungsaufgaben xix Validity: [From: Sun Feb 22 13:27:55 CET 2009, To: Mon Feb 22 13:27:55 CET 2010] Issuer: CN=CA2, O="FH Frankfurt ", L=Frankfurt, ST=Hessen, C=DE SerialNumber: [ 01] ] *** Found trusted certificate: [ [ Version: V3 Subject: CN=CA2, O="FH Frankfurt ", L=Frankfurt, ST=Hessen, C=DE Signature Algorithm: SHA1withRSA, OID = Validity: [From: Sun Feb 22 13:24:07 CET 2009, To: Tue Mar 24 13:24:07 CET 2009] Issuer: CN=CA2, O="FH Frankfurt ", L=Frankfurt, ST=Hessen, C=DE SerialNumber: [ ac53987c 35a2dc14] ] *** ClientKeyExchange, DH SESSION KEYGEN: PreMaster Secret: CONNECTION KEYGEN: *** CertificateVerify *** Finished %% Cached server session: [Session-1, TLS_DHE_RSA_WITH_AES_256_CBC_SHA] Wie wir den Meldungen entnehmen können, kann der Server das vom Client vorgelegte Zertifikat erfolgreich überprüfen (die Signatur konnte mit dem im Zertifikat dort angegebenen öffentlichen Schlüssel erfolgreich überprüft werden und das Zertifikat ist von einer CA ausgestellt, welcher der Server vertraut) und der Verbindungsaufbau wird erfolgreich abgeschlossen. An dieser Stelle sei nochmals darauf hingewiesen, dass die hier dargestellten Meldungen nicht dem entsprechen, was tatsächlich zwischen Client und Server an Kommunikation stattfindet, sondern das darstellt, was durch die Debug-Option an Meldungen erzeugt wird Übungsaufgaben Wiederholungsfragen Aufgabe 13.14: Beschreiben Sie den Ablauf des Handshake Protocols bei SSL/TLS.

20 xx 13 Netzwerkanwendungen Aufgabe 13.15: Führen Sie das in Abschnitt skizzierte Experiment durch. Verwenden Sie dabei einmal die Option, dass der Client sich mit Zertifikat authentifiziert, und lassen Sie diese Option in weiteren Experimenten weg. Betrachten Sie die Ausgabe des Programms und vergleichen Sie sie Weiterführende Aufgaben Aufgabe 13.16: Bei Java gibt es die Möglichkeit, durch die Implementierung eines eigenen TrustManager beim Verbindungsaufbau erhaltene Zertifikate selbst zu validieren. Einige Webseiten schlagen vor, bei Problemen mit Zertifikaten einen eigenen Manager zu schreiben, der sämtliche Zertifikate klaglos akzeptiert. Was ist von diesem Vorgehen zu halten?