Netzwerk- und Datensicherheit

Größe: px
Ab Seite anzeigen:

Download "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

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 https:// 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 https:// 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?

IT-Sicherheit Kapitel 11 SSL/TLS

IT-Sicherheit Kapitel 11 SSL/TLS IT-Sicherheit Kapitel 11 SSL/TLS Dr. Christian Rathgeb Sommersemester 2014 1 Einführung SSL/TLS im TCP/IP-Stack: SSL/TLS bietet (1) Server-Authentifizierung oder Server und Client- Authentifizierung (2)

Mehr

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Übersicht Internetsicherheit Protokoll Sitzungen Schlüssel und Algorithmen vereinbaren Exportversionen Public Keys Protokollnachrichten 29.10.2003 Prof.

Mehr

SSL/TLS und SSL-Zertifikate

SSL/TLS und SSL-Zertifikate SSL/TLS und SSL-Zertifikate Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 16.06.10 KvBK Wolfgang Hüttenhofer sethur_blackcoat@web.de Motivation Sichere, verschlüsselte End-to-End Verbindung

Mehr

Denn es geht um ihr Geld:

Denn es geht um ihr Geld: Denn es geht um ihr Geld: [A]symmetrische Verschlüsselung, Hashing, Zertifikate, SSL/TLS Warum Verschlüsselung? Austausch sensibler Daten über das Netz: Adressen, Passwörter, Bankdaten, PINs,... Gefahr

Mehr

Rosa Freund SSL/TLS 26.10.2005 SSL/TLS 26.10.2005. Institut für Mathematik, TU Berlin. Rosa Freund -- rosa@pool.math.tu-berlin.de

Rosa Freund SSL/TLS 26.10.2005 SSL/TLS 26.10.2005. Institut für Mathematik, TU Berlin. Rosa Freund -- rosa@pool.math.tu-berlin.de 1 SSL/TLS 26.10.2005 Institut für Mathematik, TU Berlin Rosa Freund -- rosa@pool.math.tu-berlin.de 2 Übersicht Einführung SSL vs. TLS SSL: Anwendung und PKI SSL Protokoll: Record Protocol und Handshake

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

Digitale Signatur. Digitale Signatur. Anwendungen der Kryptographie. Secret Sharing / Splitting. Ziele SSL / TLS

Digitale Signatur. Digitale Signatur. Anwendungen der Kryptographie. Secret Sharing / Splitting. Ziele SSL / TLS Digitale Signatur Digitale Signatur kombiniert Hash Funktion und Signatur M, SIGK(HASH(M)) wichtige Frage: Wie wird der Bithaufen M interpretiert Struktur von M muss klar definiert sein Wie weiss ich,

Mehr

Hacken von implementierungsspezifischen! SSL-Schwachstellen

Hacken von implementierungsspezifischen! SSL-Schwachstellen Hacken von implementierungsspezifischen! SSL-Schwachstellen Basic-Constraints-Schwachstelle Null-Präfix-Attacke Thomas Konrad, FH St. Pölten, Studiengang IT Security, is072033@fhstp.ac.at Wozu SSL? Authentizität

Mehr

IT-Sicherheit - Sicherheit vernetzter Systeme -

IT-Sicherheit - Sicherheit vernetzter Systeme - IT-Sicherheit - Sicherheit vernetzter Systeme - Kapitel 12: Netzsicherheit - Schicht 4: Transport Layer / TLS 1 Inhalt Transport Layer Funktionen Secure Socket Layer (); Transport Layer Security (TLS)

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

Secure Socket Layer v. 3.0

Secure Socket Layer v. 3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer v. 3.0 (SSLv3) Zheng Yao 05.07.2004-1 - 1. Was ist SSL? SSL steht für Secure Socket Layer, ein Protokoll zur Übertragung

Mehr

Seminar Neue Techologien in Internet und WWW

Seminar Neue Techologien in Internet und WWW Seminar Neue Techologien in Internet und WWW Sicherheit auf der Anwendungsschicht: HTTP mit SSL, TLS und dabei verwendete Verfahren Christian Raschka chrisra@informatik.uni-jena.de Seminar Neue Internettechnologien

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

objectif Installation objectif RM Web-Client

objectif Installation objectif RM Web-Client objectif RM Installation objectif RM Web-Client Bei Fragen nutzen Sie bitte unseren kostenlosen Support: Telefon: +49 (30) 467086-20 E-Mail: Service@microTOOL.de 2014 microtool GmbH, Berlin. Alle Rechte

Mehr

Beweisbar sichere Verschlüsselung

Beweisbar sichere Verschlüsselung Beweisbar sichere Verschlüsselung ITS-Wahlpflichtvorlesung Dr. Bodo Möller Ruhr-Universität Bochum Horst-Görtz-Institut für IT-Sicherheit Lehrstuhl für Kommunikationssicherheit bmoeller@crypto.rub.de 12

Mehr

Ausarbeitung zum Vortrag. Secure Socket Layer. von Jelle Hellmann im Rahmen der Vorlesung Sicherheit in Datennetzen von Herrn Prof.

Ausarbeitung zum Vortrag. Secure Socket Layer. von Jelle Hellmann im Rahmen der Vorlesung Sicherheit in Datennetzen von Herrn Prof. Ausarbeitung zum Vortrag Secure Socket Layer von Jelle Hellmann im Rahmen der Vorlesung Sicherheit in Datennetzen von Herrn Prof. Schäfer an der im WS 2004/2005 Inhaltsverzeichnis: INHALTSVERZEICHNIS:...

Mehr

Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009. IT-Security. Teil 4: SSL/TLS Dr. Erwin Hoffmann

Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009. IT-Security. Teil 4: SSL/TLS Dr. Erwin Hoffmann Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009 IT-Security Teil 4: SSL/TLS Dr. Erwin Hoffmann E-Mail: it-security@fehcom.de Secure Socket Layer (SSL) Tranport Layser Security (TLS)

Mehr

Einführung in OpenSSL und X.509-Zertifikate. Martin Kaiser http://www.kaiser.cx/

Einführung in OpenSSL und X.509-Zertifikate. Martin Kaiser http://www.kaiser.cx/ Einführung in OpenSSL und X.509-Zertifikate Martin Kaiser http://www.kaiser.cx/ Über mich Elektrotechnik-Studium Uni Karlsruhe System-Ingenieur UNIX und IP-Netze (2001-2003) Embedded Software-Entwicklung

Mehr

Seminar Internet-Technologie

Seminar Internet-Technologie Seminar Internet-Technologie Zertifikate, SSL, SSH, HTTPS Christian Kothe Wintersemester 2008 / 2009 Inhalt Asymmetrisches Kryptosystem Digitale Zertifikate Zertifikatsformat X.509 Extended-Validation-Zertifikat

Mehr

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

Secure Socket Layer V.3.0

Secure Socket Layer V.3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer V.3.0 (SSLv3) Zheng Yao 05.07.2004 1 Überblick 1.Was ist SSL? Bestandteile von SSL-Protokoll, Verbindungherstellung

Mehr

Netzwerksicherheit Übung 5 Transport Layer Security

Netzwerksicherheit Übung 5 Transport Layer Security Netzwerksicherheit Übung 5 Transport Layer Security Tobias Limmer, Christoph Sommer, David Eckhoff Computer Networks and Communication Systems Dept. of Computer Science, University of Erlangen-Nuremberg,

Mehr

Verschlüsselung der Kommunikation zwischen Rechnern

Verschlüsselung der Kommunikation zwischen Rechnern Verschlüsselung der Kommunikation zwischen Rechnern Stand: 11. Mai 2007 Rechenzentrum Hochschule Harz Sandra Thielert Hochschule Harz Friedrichstr. 57 59 38855 Wernigerode 03943 / 659 0 Inhalt 1 Einleitung

Mehr

IT-Sicherheit: Übung 6

IT-Sicherheit: Übung 6 IT-Sicherheit: Übung 6 Zertifikate, Kryptographie (Diffie-Hellman), Sicherheitsprotokolle (SSL/TLS) Zertifikate! Problem: Woher weiß Bob, dass K E Alice zu Alice gehört?! Persönlicher Austausch des öffentlichen

Mehr

1 Was ist SSL? 3 1.1 SSL im OSI-Modell... 3 1.2 Der SSL-Verbindungsaufbau... 3

1 Was ist SSL? 3 1.1 SSL im OSI-Modell... 3 1.2 Der SSL-Verbindungsaufbau... 3 SSL und Zertifikate INHALTSVERZEICHNIS INHALTSVERZEICHNIS Inhaltsverzeichnis 1 Was ist SSL? 3 1.1 SSL im OSI-Modell.................................... 3 1.2 Der SSL-Verbindungsaufbau...............................

Mehr

Stammtisch 04.12.2008. Zertifikate

Stammtisch 04.12.2008. Zertifikate Stammtisch Zertifikate Ein Zertifikat ist eine Zusicherung / Bestätigung / Beglaubigung eines Sachverhalts durch eine Institution in einem definierten formalen Rahmen 1 Zertifikate? 2 Digitale X.509 Zertifikate

Mehr

Anforderungen an elektronische Signaturen. Michel Messerschmidt

Anforderungen an elektronische Signaturen. Michel Messerschmidt Anforderungen an elektronische Signaturen Michel Messerschmidt Übersicht Kryptographische Grundlagen Rechtliche Grundlagen Praxis Michel Messerschmidt, 2006-03-16 2 Kryptographische Grundlagen Verschlüsselung

Mehr

Terravis - Hinweise zur Implementierung der SSL-Verbindung

Terravis - Hinweise zur Implementierung der SSL-Verbindung Terravis - Hinweise zur Implementierung der -Verbindung Version: 1.0 Datum: 19.04.2013 Autoren: Claude Eisenhut -Hinweise.docx 19.04.2013 Seite 1/8 Verzeichnis: Einführung... 3 Kontaktpersonen 3 Allgemeines...

Mehr

BEKO-Forum Juni 2007 Server-Zertifikate an der Uni Bern

BEKO-Forum Juni 2007 Server-Zertifikate an der Uni Bern BEKO-Forum Juni 2007 Server-Zertifikate an der Uni Bern Informatikdienste Gruppe Security Universität Bern Agenda Demo: Ein bisschen Kryptologie für Sie und Ihn Aufgaben und Nutzen von Server-Zertifikaten

Mehr

Allgemeine Erläuterungen zu

Allgemeine Erläuterungen zu en zu persönliche Zertifikate Wurzelzertifikate Zertifikatssperrliste/Widerrufsliste (CRL) Public Key Infrastructure (PKI) Signierung und Verschlüsselung mit S/MIME 1. zum Thema Zertifikate Zertifikate

Mehr

Abruf und Versand von Mails mit Verschlüsselung

Abruf und Versand von Mails mit Verschlüsselung Bedienungstip: Verschlüsselung Seite 1 Abruf und Versand von Mails mit Verschlüsselung Die folgende Beschreibung erklärt, wie man mit den üblichen Mailprogrammen die E- Mailabfrage und den E-Mail-Versand

Mehr

Attribut Kürzel Beispiele Bemerkungen Country Name C DE bitte Großbuchstaben State or Province Name ST Nordrhein-Westfalen

Attribut Kürzel Beispiele Bemerkungen Country Name C DE bitte Großbuchstaben State or Province Name ST Nordrhein-Westfalen Erzeugen eines externen Schlüssels außerhalb des Browsers für Nutzerzertifikate Sollten bei Ihnen Abhängigkeiten zwischen ihrem privaten Schlüsselteil und verwendeter Hardware und oder Software bestehen,

Mehr

IT-Sicherheit WS 2012/13. Übung 5. zum 28. November 2012

IT-Sicherheit WS 2012/13. Übung 5. zum 28. November 2012 Prof. Dr. C. Eckert Thomas Kittel IT-Sicherheit WS 2012/13 Übung 5 zum 28. November 2012 Institut für Informatik Lehrstuhl für Sicherheit in der Informatik 1 X.509-Zertifikate Zertifikate nach dem X.509-Standard

Mehr

Benutzerzertifikate für Java Webstart

Benutzerzertifikate für Java Webstart Benutzerzertifikate für Java Webstart Benutzerdokumentation Wien 5. Dezember 2011 Florian Bruckner, Florian Heinisch 3kraft IT GmbH & Co KG Wasagasse 26/2 1090 Wien Österreich Tel: +43 1 920 45 49 Fax

Mehr

Handbuch für Nutzer von Zertifikaten der Zertifizierungsstellen (CAs) des Bayerischen Behördennetzes (BYBN) zur Authentifizierung im Web Teil W4:

Handbuch für Nutzer von Zertifikaten der Zertifizierungsstellen (CAs) des Bayerischen Behördennetzes (BYBN) zur Authentifizierung im Web Teil W4: Handbuch für Nutzer von Zertifikaten der Zertifizierungsstellen (CAs) des Bayerischen Behördennetzes (BYBN) zur Authentifizierung im Web (Bernhard Wager) München 30.01.2008 1 1 Besonderheiten beim Einsatz

Mehr

Installation Anleitung für JTheseus und MS SQL Server 2000

Installation Anleitung für JTheseus und MS SQL Server 2000 Installation Anleitung für JTheseus und MS SQL Server 2000 Inhaltsverzeichnis 1 Installation der Datenbank 3 1.1 Erstellen der Datenbank 3 1.2 Tabellen und Minimal Daten einlesen 4 1.3 Benutzer JTheseus

Mehr

Signieren und Verschlüsseln mit Outlook 2013

Signieren und Verschlüsseln mit Outlook 2013 Anleitung: Von Tobias Neumayer (support@thi.de) MAIL-VERSCHLÜSSELUNG / SIGNIERUNG Einführung Die meisten Mailprogramme unterstützen den Umgang mit S/MIME-Zertifikaten zur Verschlüsselung bzw. Signierung

Mehr

Sicherheitskonzept und Sicherheitspru fung. Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR

Sicherheitskonzept und Sicherheitspru fung. Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR Sicherheitskonzept und Sicherheitspru fung Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR Einführung Die Firma MVZ Labor PD Dr. Volkmann und Kollegen GbR, nachstehend als Labor

Mehr

Ein Überblick über Security-Setups von E-Banking Websites

Ein Überblick über Security-Setups von E-Banking Websites Ein Überblick über Security-Setups von E-Banking Websites Stefan Huber www.sthu.org Linuxwochen Linz 2015 31. Mai 2015 Basierend auf Testergebnissen vom 28.03.2015 aus https://www.sthu.org/blog/11-tls-dnssec-ebanking/

Mehr

SSL Algorithmen und Anwendung

SSL Algorithmen und Anwendung SSL Algorithmen und Anwendung Stefan Pfab sisspfab@stud.uni-erlangen.de Abstract Viele Anwendungen erfordern nicht nur eine eindeutige und zuverlässige Identifizierung der an einer Kommunikation beteiligten

Mehr

Emailverschlüsselung mit Thunderbird

Emailverschlüsselung mit Thunderbird Emailverschlüsselung mit Thunderbird mit einer kurzen Einführung zu PGP und S/MIME Helmut Schweinzer 3.11.12 6. Erlanger Linuxtag Übersicht Warum Signieren/Verschlüsseln Email-Transport Verschlüsselung

Mehr

im DFN Berlin 18.10.2011 Renate Schroeder, DFN-Verein

im DFN Berlin 18.10.2011 Renate Schroeder, DFN-Verein VoIP-Verschlüsselung Verschlüsselung im DFN Berlin 18.10.2011 Renate Schroeder, DFN-Verein Einordnung VoIP in DFNFernsprechen VoIP seit 5 Jahren im DFN verfügbar VoIP ist Teil des Fernsprechdienstes DFNFernsprechen

Mehr

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo.

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo. 1 Von 10-16.04.07 Virtuelle Netze Simon Knierim & Benjamin Skirlo für Herrn Herrman Schulzentrum Bremen Vegesack Berufliche Schulen für Metall- und Elektrotechnik 2 Von 10-16.04.07 Inhaltsverzeichnis Allgemeines...

Mehr

Hierarchische Authentifizierung mit SSL/TLS

Hierarchische Authentifizierung mit SSL/TLS Hierarchische Authentifizierung mit SSL/TLS Wolfgang Hüttenhofer 21.07.2010 Seminararbeit für Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 Friedrich-Alexander Universität Erlangen-Nürnberg

Mehr

Internet Security: Verfahren & Protokolle

Internet Security: Verfahren & Protokolle Internet Security: Verfahren & Protokolle 39 20 13 Vorlesung im Grundstudium NWI (auch MGS) im Sommersemester 2003 2 SWS, Freitag 10-12, H10 Peter Koch pk@techfak.uni-bielefeld.de 30.05.2003 Internet Security:

Mehr

Installationsanleitung für die h_da Zertifikate

Installationsanleitung für die h_da Zertifikate Zentrale Serverdienste Installationsanleitung für die h_da Zertifikate Dokumentennummer: IT-ZSD-008 Version 1.3 Stand 23.05.2013 Historie Version Datum Änderung Autor 1.0 22.10.2008 Dokument angelegt tbo

Mehr

X.509v3 Zertifizierungsinstanz der Universität Würzburg

X.509v3 Zertifizierungsinstanz der Universität Würzburg X.509v3 Zertifizierungsinstanz der Universität Würzburg Markus Krieger Rechenzentrum Uni Würzburg ca@uni-wuerzburg.de 22.01.06 1 Notwendigkeit von Zertifikaten Steigende Anzahl von Kommunikationsbeziehungen

Mehr

Rainbow Technologies GmbH. Bedeutung von SSL in Ihrem Unternehmen

Rainbow Technologies GmbH. Bedeutung von SSL in Ihrem Unternehmen Rainbow Technologies GmbH Markus Kahmen Bedeutung von SSL in Ihrem Unternehmen Thursday, April 19, 2001 http://europe.rainbow.com 1 Das Internet Die Internet-Ära verspricht für die nächsten 10 Jahre mehr

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

Einführung in die symmetrische und asymmetrische Verschlüsselung

Einführung in die symmetrische und asymmetrische Verschlüsselung Einführung in die symmetrische und asymmetrische Verschlüsselung Enigmail Andreas Grupp grupp@elektronikschule.de Download der Präsentation unter http://grupp-web.de by A. Grupp, 2007-2010. Dieses Werk

Mehr

Installationsanleitung

Installationsanleitung 1 Inhalt 1 Inhalt 1 2 Sicherheitshinweise 2 2.1 Allgemeine Richtlinien und Empfehlungen 2 2.2 Allgemeine Sicherheitskriterien 2 3 Zugriffsmöglichkeiten 3 3.1 Browserbasierte Zugriffe auf Dienste im BVN

Mehr

1. IKEv2 zwischen Windows 7 und Gateway mit Zertifikaten (PKCS#12)

1. IKEv2 zwischen Windows 7 und Gateway mit Zertifikaten (PKCS#12) 1. IKEv2 zwischen Windows 7 und Gateway mit Zertifikaten (PKCS#12) 1.1 Einleitung Im Folgenden wird die Konfiguration einer IPSec-Verbindung mit IKEv2 von einem Windows 7 Rechner zum bintec IPSec-Gateway

Mehr

Installation des Zertifikats am Beispiel eines WWW-Servers unter Windows2003. Voraussetzungen

Installation des Zertifikats am Beispiel eines WWW-Servers unter Windows2003. Voraussetzungen HS-Anhalt (FH) Fachbereich EMW Seite 1 von 8 Stand 04.02.2008 Installation des Zertifikats am Beispiel eines WWW-Servers unter Windows2003 Voraussetzungen Es ist keinerlei Zusatzsoftware erforderlich.

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

Internet Security: Verfahren & Protokolle

Internet Security: Verfahren & Protokolle Internet Security: Verfahren & Protokolle 39 20 13 Vorlesung im Grundstudium NWI (auch MGS) im Sommersemester 2003 2 SWS, Freitag 10-12, H10 Peter Koch pk@techfak.uni-bielefeld.de 20.06.2003 Internet Security:

Mehr

SSL/TLS: Ein Überblick

SSL/TLS: Ein Überblick SSL/TLS: Ein Überblick Wie funktioniert das sichere Internet? Dirk Geschke Linux User Group Erding 28. März 2012 Dirk Geschke (LUG-Erding) SSL/TLS 28. März 2012 1 / 26 Gliederung 1 Einleitunng 2 Verschlüsselung

Mehr

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Secure Socket Layer (SSL) Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Inhalt 1) Allgemeiner Überblick 2) Kurzer geschichtlicher Rückblick 3) Vorteile

Mehr

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Das E-Mail-Programm Outlook 98 von Microsoft bietet Ihnen durch die Standard- Integration des E-Mail-Protokolls S/MIME (Secure/MIME) die Möglichkeit,

Mehr

(HTTPS) Hypertext Transmission Protokol Secure

(HTTPS) Hypertext Transmission Protokol Secure (HTTPS) Hypertext Transmission Protokol Secure HTTPS steht für HyperText Transfer Protocol Secure (dt. sicheres Hypertext- Übertragungsprotokoll) und ist ein Verfahren, um Daten im WWW abhörsicher zu übertragen.

Mehr

Datenübertragungsportal

Datenübertragungsportal Datenübertragungsportal seite zwei Inhalt Inhalt seite zwei Datenübertragungsportal seite drei Erreichte Schutzziele seite acht seite drei Datenübertragungsportal Die Firmengruppe Melter stellt Ihren Kunden

Mehr

USB-Tokens. Technik und Einsatzgebiete

USB-Tokens. Technik und Einsatzgebiete USB-Tokens Technik und Einsatzgebiete Vortrag im Rahmen der Lehrveranstaltung Chipkartensysteme und E-Payment im SS05 an der Fachhochschule Bonn-Rhein-Sieg Outline Passwortmanager PKI Smartcards USB-Tokens

Mehr

Netzwerk- und Datensicherheit

Netzwerk- und Datensicherheit Martin Kappes Netzwerk- und Datensicherheit Eine praktische Einführung Zusatz: OpenVPN Martin Kappes Fachhochschule Frankfurt am Main - University of Applied Sciences Fachbereich 2: Informatik und Ingenieurwissenschaften

Mehr

Internet Datasafe Sicherheitstechnische Herausforderungen

Internet Datasafe Sicherheitstechnische Herausforderungen ERFA-Tagung 14.9.2010 Internet Datasafe Sicherheitstechnische Herausforderungen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte Wissenschaften

Mehr

ViMP 3.0. SSL Einrichtung in Apache 2.2. Verfasser: ViMP GmbH

ViMP 3.0. SSL Einrichtung in Apache 2.2. Verfasser: ViMP GmbH ViMP 3.0 SSL Einrichtung in Apache 2.2 Verfasser: ViMP GmbH Inhaltsverzeichnis Voraussetzungen...3 Eigene Zertifikate mit OpenSSL erstellen...4 Selbst-signiertes Zertifikat erstellen...4 Zertifikat mit

Mehr

Vorab: Anlegen eines Users mit Hilfe der Empfängerbetreuung

Vorab: Anlegen eines Users mit Hilfe der Empfängerbetreuung Seite 1 Einrichtung der Verschlüsselung für Signaturportal Verschlüsselung wird mit Hilfe von sogenannten Zertifikaten erreicht. Diese ermöglichen eine sichere Kommunikation zwischen Ihnen und dem Signaturportal.

Mehr

Daten-Kommunikation mit crossinx

Daten-Kommunikation mit crossinx Daten-Kommunikation mit Datenübertragung.doc Seite 1 von 8 Inhaltsverzeichnis 1 Einführung... 3 1.1 Datenübertragung an... 3 1.2 Datenversand durch... 3 2 X.400... 4 3 AS2... 4 4 SFTP (mit fester Sender

Mehr

Technische Universität München

Technische Universität München Kapitel 12 Kryptographische Protokolle Ziel: Anwendung der kryptographischen Bausteine Protokoll: Vereinbarung zwischen Kommunikationspartnern über Art, Inhalt und Formatierung der ausgetauschten Nachrichten

Mehr

Secure Socket Layer (SSL) - Zertifikate

Secure Socket Layer (SSL) - Zertifikate e Einführung Zur Übertragung sensibler Daten über das Internet wurde das SSL-Protokoll entwickelt. SSL steht für Secure Socket Layer (dt. "sichere Sockelschicht") das von der Firma Netscape und RSA Data

Mehr

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure)

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Unterrichtseinheit 5: Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Verschlüsselung mit öffentlichen Schlüsseln ist eine bedeutende Technologie für E- Commerce, Intranets,

Mehr

E-Mails versenden aber sicher!

E-Mails versenden aber sicher! E-Mails versenden aber sicher! Sichere E-Mail mit Secure E-Mail - Kundenleitfaden - S Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

Vorlesung IT-Sicherheit FH Frankfurt Sommersemester 2007

Vorlesung IT-Sicherheit FH Frankfurt Sommersemester 2007 Vorlesung IT-Sicherheit FH Frankfurt Sommersemester 2007 Dr. Volker Scheidemann Digitale Zertifikate Public Key Infrastrukturen (PKI) Sicherheitsprozesse Seite: 2 Gefahr bei PKC: Die Man in the Middle-Attacke

Mehr

fãéçêíáéêéå=éáåéë=`äáéåíjwéêíáñáâ~íë= áå=çéå=_êçïëéê=

fãéçêíáéêéå=éáåéë=`äáéåíjwéêíáñáâ~íë= áå=çéå=_êçïëéê= fãéçêíáéêéå=éáåéë=`äáéåíjwéêíáñáâ~íë= áå=çéå=_êçïëéê= = i t=^ëëéí=j~å~öéãéåí=fåîéëíãéåíöéëéääëåü~ñí=ãäe= Inhaltsverzeichnis 2 Inhaltsverzeichnis Inhaltsverzeichnis...2 Abbildungsverzeichnis...3 1 Einführung...4

Mehr

UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover

UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover Sicherheitstage WS 04/05 Birgit Gersbeck-Schierholz, RRZN Einleitung und Überblick Warum werden digitale Signaturen

Mehr

E-Mails versenden aber sicher! Secure E-Mail

E-Mails versenden aber sicher! Secure E-Mail E-Mails versenden aber sicher! Secure E-Mail Leitfaden S Kreisparkasse Verden 1 Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

Knowledge Base Importieren von Zertifikaten

Knowledge Base Importieren von Zertifikaten Datum 25.02.10 14:50 Hersteller Fortinet, Seppmail, Watchguard, Mailfoundry Modell Type(n) n/a Firmware Copyright Boll Engineering AG, Wettingen Autor Tech-Abteilung Dokument-Version 1.1 Situation: In

Mehr

Anlage 3 Verfahrensbeschreibung

Anlage 3 Verfahrensbeschreibung Anlage 3 Verfahrensbeschreibung Stand September 2015 1 INHALTSVERZEICHNIS 1 EINLEITUNG... 2 2 SYSTEMVORAUSSETZUNGEN... 3 2.1 Technische Voraussetzung beim Kunden... 3 2.2 Ausstattung des Clients... 3 3

Mehr

Public-Key-Infrastrukturen

Public-Key-Infrastrukturen TECHNISCHE UNIVERSITÄT DARMSTADT FACHGEBIET THEORETISCHE INFORMATIK PROF. DR. J. BUCHMANN DR. A. WIESMAIER 9. Übung zur Vorlesung Public-Key-Infrastrukturen Sommersemester 2011 Aufgabe 1: Indirekte CRL

Mehr

emails digital signieren und verschlüsseln mit Zertifikaten

emails digital signieren und verschlüsseln mit Zertifikaten emails digital signieren und verschlüsseln mit Zertifikaten Martin Heinold, Andreas Hirsch Werdenfels-Gymnasium, Garmisch-Partenkirchen GAPONLINE Bürgernetzverein für den Landkreis Garmisch-Partenkirchen

Mehr

Problem: keine sichere Verbindung zwischen öffentlichen Schlüssel und der tatsächlichen Identität des Erstellers der Signatur.

Problem: keine sichere Verbindung zwischen öffentlichen Schlüssel und der tatsächlichen Identität des Erstellers der Signatur. Referat im Proseminar Electronic Commerce Thema: Anwendungen von Kryptographie für E-Commerce Betreuer: Michael Galler Stoffsammlung/Grobgliederung Problem der Sicherheit des E-Commerce - nötig für Sicherheitsgarantie:

Mehr

Variablen manipulieren per JDI

Variablen manipulieren per JDI Variablen manipulieren per JDI Zusammenfassung Jede moderne Java IDE verfügt über eine mächtige und dennoch meist einfach zu bedienende Benutzeroberfläche die das finden von Fehlern in lokalen oder entfernt

Mehr

Datenempfang von crossinx

Datenempfang von crossinx Datenempfang von crossinx Datenempfang.doc Seite 1 von 6 Inhaltsverzeichnis 1 Einführung... 3 2 AS2... 3 3 SFTP... 3 4 FTP (via VPN)... 4 5 FTPS... 4 6 Email (ggf. verschlüsselt)... 5 7 Portalzugang über

Mehr

E-Mail-Verschlüsselung mit S/MIME und Microsoft Outlook

E-Mail-Verschlüsselung mit S/MIME und Microsoft Outlook E-Mail-Verschlüsselung mit S/MIME und Microsoft Outlook E-Mail-Verschlüsselung mit S/MIME und Windows Live Mail von Andreas Grupp ist lizenziert unter einer Creative Commons Namensnennung - Weitergabe

Mehr

1 Praktikum Protokolle SS2007 Fachhochschule OOW 15.05.2007. VPN Dokumentation. Erstellt von: Jens Nintemann und Maik Straub

1 Praktikum Protokolle SS2007 Fachhochschule OOW 15.05.2007. VPN Dokumentation. Erstellt von: Jens Nintemann und Maik Straub 1 Praktikum Protokolle SS2007 Fachhochschule OOW VPN Dokumentation 1 2 Praktikum Protokolle SS2007 Fachhochschule OOW Inhaltsverzeichnis Thema Seite 1. Einleitung 3 2. Unsere Aufbaustruktur 3 3. Installation

Mehr

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software FTP Übersicht Was ist FTP? Übertragungsmodi Sicherheit Öffentliche FTP-Server FTP-Software Was ist FTP? Protokoll zur Dateiübertragung Auf Schicht 7 Verwendet TCP, meist Port 21, 20 1972 spezifiziert Übertragungsmodi

Mehr

Elliptische Kurven und ihre Anwendungen in der Kryptographie

Elliptische Kurven und ihre Anwendungen in der Kryptographie Elliptische Kurven und ihre Anwendungen in der Kryptographie Heiko Knospe Fachhochschule Köln heiko.knospe@fh-koeln.de 29. März 2014 1 / 25 Weierstraß-Gleichung Elliptische Kurven sind nicht-singuläre

Mehr

Verteilte Systeme. Übung 10. Jens Müller-Iden

Verteilte Systeme. Übung 10. Jens Müller-Iden Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt

Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt April 2011 Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt 1. Einleitung E-Mails lassen sich mit geringen Kenntnissen auf dem Weg durch die elektronischen Netze leicht mitlesen oder verändern.

Mehr

Digitales Zertifikat für die Authentifizierung

Digitales Zertifikat für die Authentifizierung Single Sign On Waisenhausgasse 36-38a 50676 Köln Tel.: +49 221 4724-1 Fax +49 221 4724-444 posteingang@dimdi.de www.dimdi.de Ansprechpartner: Helpdesk Technik Tel: +49 221 4724-270 helpdesk@dimdi.de Digitales

Mehr

Sichere Abwicklung von Geschäftsvorgängen im Internet

Sichere Abwicklung von Geschäftsvorgängen im Internet Sichere Abwicklung von Geschäftsvorgängen im Internet Diplomarbeit von Peter Hild Theoretische Grundlagen der Kryptologie Vorhandene Sicherheitskonzepte für das WWW Bewertung dieser Konzepte Simulation

Mehr

Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009. IT-Security. Teil 2: Zertifikate, X.509, PKI Dr.

Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009. IT-Security. Teil 2: Zertifikate, X.509, PKI Dr. Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009 IT-Security Teil 2: Zertifikate, X.509, PKI Dr. Erwin Hoffmann E-Mail: it-security@fehcom.de Einsatz von Zertifikaten Ein Zertifikat

Mehr

SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen

SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen Immo FaUl Wehrenberg immo@ctdo.de Chaostreff Dortmund 16. Juli 2009 Immo FaUl Wehrenberg immo@ctdo.de (CTDO) SSL/TLS Sicherheit

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 13.07.2011 Dokumentenart: Anwenderbeschreibung Version: 3.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3

Mehr

Digitale Signatur - Anleitung zur Zertifizierung der eigenen Email-Adresse

Digitale Signatur - Anleitung zur Zertifizierung der eigenen Email-Adresse 1 Digitale Signatur - Anleitung zur Zertifizierung der Digitale Signatur - Anleitung zur Zertifizierung der Website Nutzerzertifikat https://pki.pca.dfn.de/htw-dresden-ca/cgi-bin/pub/pki Auf dieser Seite

Mehr

Schritt 1: Auswahl Schritt 3 Extras > Konten Schritt 2: Konto erstellen Konto hinzufügen klicken

Schritt 1: Auswahl Schritt 3 Extras > Konten Schritt 2: Konto erstellen Konto hinzufügen klicken In diesem Tutorial zeigen wir Ihnen, wie Sie im Mozilla Thunderbird E-Mailclient ein POP3-Konto einrichten. Wir haben bei der Erstellung des Tutorials die Version 2.0.0.6 verwendet. Schritt 1: Auswahl

Mehr

Sicherheit in Netzen Modul 5: TLS Transport Layer Security

Sicherheit in Netzen Modul 5: TLS Transport Layer Security Sicherheit in Netzen Modul 5: TLS Transport Layer Security 1. TLS-Einordnung (OSI-Referenzmodell, Geschichte) 2. TLS-Datenübertragung 3. TLS Schlüssel und Algorithmen 4. TLS-Handshake 5. TLS-Implementierung

Mehr

Smartcard-Authentifizierung mit Oracle-Forms

Smartcard-Authentifizierung mit Oracle-Forms Smartcard-Authentifizierung mit Oracle-Forms Teil 1: Theoretisches zur 2-Faktor Authentifizierung Das Smartcard-Projekt der Nordrheinischen Ärzteversorgung Irisstrasse 45 11. November 2004 1 Inhalt Kurzvorführung

Mehr

SSL-Zertifikate. Dr. Christopher Kunz

SSL-Zertifikate. Dr. Christopher Kunz SSL-Zertifikate Dr. Christopher Kunz Ihr Referent _ Dr. Christopher Kunz _ CEO Hosting filoo GmbH / TK AG _ Promotion IT Security _ X.509 / SSL _ Vorträge auf Konferenzen _ OSDC 2012: SSL-Hacks _ OSDC

Mehr

SSL Sicherheit. Hinweise zur Sicherheit der SSLverschlüsselten. 2014-04-04 Rainer Meier Mühlistr. 4 6288 Schongau skybeam@skybeam.ch.

SSL Sicherheit. Hinweise zur Sicherheit der SSLverschlüsselten. 2014-04-04 Rainer Meier Mühlistr. 4 6288 Schongau skybeam@skybeam.ch. SSL Sicherheit Hinweise zur Sicherheit der SSLverschlüsselten Datenübermittlung Meier Informatik Rainer Meier Mühlistr. 4 6288 Schongau skybeam@skybeam.ch by Rainer Meier Sicherheitshinweise Seite 2 1.

Mehr