Seminararbeit zu SSL/TLS

Größe: px
Ab Seite anzeigen:

Download "Seminararbeit zu SSL/TLS"

Transkript

1 Lehrstuhl für Softwaretechnik Universität Augsburg Seminararbeit zu SSL/TLS im Seminar Internetsicherheit Michael Hübschmann Betreuung: Dipl. Inf Kuzman Katkalov Studiengang: Bachelor Informatik Datum:

2 Abstract. Egal was man im Internet tut, Verschlüsselung ist omnipräsent. Das Protokoll dafür ist SSL/TLS. Wie das Protokoll aufgebaut ist und funktioniert wird in dieser Arbeit genauso betrachtet, wie bisherige Angriffe auf das Protokoll und welche Änderungen sich daraus für SSL/TLS ergaben. 2

3 Abbildungsverzeichnis Fig. 1. Einordnung von TLS in das Schichtenmodell des Internets, angelehnt an Figure 4.1 aus [4]... 7 Fig. 2. Die Operationen und Datenstrukturen des TLS Record Protokoll... 9 Fig. 3. Der Ablauf des TLS Handshake Protokoll

4 Inhaltsverzeichnis 1 Einleitung und Motivation Von SSL zu TLS, die Geschichte der sicheren Datenübertragung im Internet 5 3 Funktionsweise von SSL/TLS TLS Record Protokoll TLS Handshake Protokoll TLS Public Key Infrastructure TLS Change Cipher Spec Protokoll TLS Alert Protokoll TLS Application Data Protokoll Kryptographie und Hash Verfahren Implementierungen des Protokolls Angriffsmöglichkeiten und Sicherheitslücken Verwundbarkeiten im Protokoll TLS-Kompression: CRIME, TIME und BREACH Renegotiation und Triple-Handshake Probleme Verschlüsselungsverfahren RC4: RC4 biases attack Sichere Zertifikate? Angriffe auf die Public Key Infrastruktur Fehler in Implementierungen Heartbleed Bug in OpenSSL Zusammenfassung und Ausblick Literaturverzeichnis

5 1 Einleitung und Motivation Die jüngsten Entwicklungen haben der Kryptographie zu einem Boom verholfen. Staaten, die die eigenen Bürger abhören und ausländischen Firmen Geheimnisse entlocken, haben das Sicherheitsbewusstsein der Öffentlichkeit gestärkt. Dabei fällt auf, dass ein Begriff immer wieder Thema ist: SSL/TLS. s sollen verschlüsselt werden, der inländische Datenverkehr sowieso, und jede Website, die mit keinem Schloss-Symbol in der Browser-Leiste aufwarten kann, wird kritisch beäugt [1]. Doch was bedeutet eigentlich SSL/TLS und wie funktioniert es? Die Presse wird zudem oft von Angriffen auf SSL/TLS beherrscht, ist SSL/TLS überhaupt noch sicher? SSL/TLS ist ein sehr umfangreiches Themengebiet und betrachtet man SSL/TLS, müssen viele Themengebiete der Kryptographie angerissen werden. In dieser Arbeit wird das wichtigste Wissen zu SSL/TLS soweit wie möglich zusammengefasst und erläutert. Nach einem kurzen Abriss über die Geschichte von SSL/TLS wird in Kapitel 3 das Protokoll im Detail inspiziert und Grundlagen für die im nächsten Kapitel folgenden Angriffe geschaffen. Kritische und bekannte Angriffe auf SSL/TLS werden nachvollzogen und entsprechende Lösungen erläutert. 2 Von SSL zu TLS, die Geschichte der sicheren Datenübertragung im Internet Die Anfangsjahre des Internets dominierte ein Browser, Mosaic oder später Netscape Navigator genannt. Vor allem aufgrund seiner Fähigkeit, als erster Browser überhaupt auf Internetseiten Bilder anzuzeigen, erfuhr er eine massive Verbreitung [2]. Die Entwickler dieses Browsers der Firma Netscape erkannten ebenso früh die Bedeutung des Internets für Unternehmen und die Möglichkeiten für E-Commerce. Um diesen Geschäftszweig in einem Internet, in dem theoretisch jede Kommunikation zwischen den Teilnehmern irgendwo mitgehört werden konnte, überhaupt erst möglich zu machen, begannen sie daher mit der Entwicklung eines Protokolls für die sichere und verschlüsselte Übertragung im Internet SSL (Secure Sockets Layer). Da das Protokoll von Haus aus mit dem Netscape Browser nutzbar war, der lange Jahre einen Marktanteil von weit über 50% hatte, wurde es schon gleich nach Einführung von SSL zum einzigen und damit de facto Standard (SSL 1.0 wurde aufgrund von Sicherheitslücken nie veröffentlicht). Zusätzlich sollte durch das Format die Webserver-Software der Firma, der zu Beginn als Einziger sichere SSL Verbindungen beherrschte, verkauft werden [3]. Den endgültigen Siegeszug jedoch trat SSL an, als Netscape Sicherheitsexperten von anderen Firmen und von Universitäten einlud, das Protokoll zu verbessern und Fehler zu finden. Dadurch wurde der Weg geebnet, SSL als Industriestandard für sichere Kommunikation im Internet zu nutzen. Netscape zementierte diesen Anspruch durch 5

6 öffentlich nutzbare Patente und wandte sich letztendlich an die IETF 1. Diese übernahm große Teile der aktuellsten SSL Version (SSL 3.0), erweiterte das Protokoll um zusätzliche Fehlermeldungen und tauschte einige kryptografische Verfahren gegen Sicherere aus. Da Sockets von Secure Sockets Layer kein eigentlicher Teil der standardisierten Internetprotokolle waren und außerdem SSL stark mit der Firma Netscape verbunden war, benannte die IETF SSL zu TLS (Transport Layer Security) um und der erste internationale Standard für sichere Datenübertragung im Internet war geschaffen [3]. Aufgrund dieser Standardisierung stellte der Hauptkonkurrent Microsoft für seinen Browser Internet Explorer bisherige eigene Bemühungen ein, und implementierte TLS als Sicherheitsprotokoll, was ob der baldigen marktbeherrschenden Stellung des Internet Explorers entscheidend war. Die IETF entwickelt TLS seither stetig weiter, sodass 2006 TLS 1.1 und 2008 die bis heute aktuelle Version 1.2 mit dem RFC 5246 spezifiziert wurde. Trotz der Umbenennung wird vielfach noch der Begriff SSL verwendet, auch im TLS-Protokoll gibt sich beispielsweise TLS 1.0 als SSL 3.1 aus [4]. SSL wurde ursprünglich entwickelt, um Daten des Hyper Text Transfer Protocols (HTTP) gesichert zu übertragen. Da SSL damals aber grundsätzlich unabhängig von darüber liegenden Protokollen wie eben HTTP konzipiert wurde, kann es von beliebigen Anwendungsschicht-Protokollen verwendet werden. Fast alle Protokolle haben inzwischen entsprechende sichere Pendanten, die mit TLS gesichert sind, und teilweise an einem angehängten S für Secure erkennbar sind. Sehr bekannt ist HTTPS, aber auch das Dateiübertragungsprotokoll FTPS und für Kommunikation SMTPS sind weit verbreitet. 3 Funktionsweise von SSL/TLS Über TLS werden mehrere Aspekte der Kommunikation im Internet zwischen zwei Partnern, meistens Server und Client, gesichert. Die drei klassischen Ziele der Informationssicherheit - Authentizität, Vertraulichkeit und Integrität werden vom TLS Protokoll umgesetzt. TLS stellt sicher, dass sowohl Server als auch Client sich eindeutig gegenüber dem jeweils Anderen authentifizieren, dass die anschließende Kommunikation gesichert und für Dritte unlesbar ist 2 und zuletzt auch, dass die übertragenen Daten auf dem Weg zwischen den Kommunikationspartnern nicht verändert wurden. Dabei verwendet TLS für die Authentifikation asymmetrische Verschlüsselungsverfahren, für die Sicherung der eigentlichen Kommunikation wird jedoch ein symmetrischer Schlüssel erzeugt. Alle im Protokoll verwendeten Methoden sind nicht festgelegt, sondern können ausgetauscht werden (siehe Kapitel 3.7). 1 Internet Engineering Taskforce: forciert als lose internationale Vereinigung von Internetnutzern und -betreibern die Standardisierung von Protokollen im Internet 2 Da Integrität bei der ersten Version SSL 1.0 nicht gewährleistet werden konnte, wurde erst SSL 2.0, bei dem diese Sicherheitslücke geschlossen war, veröffentlicht. 6

7 Die Einordnung von SSL/TLS in das Schichtenmodell des Internets, das TCP/IP- Referenzmodell(siehe Abbildung 1) ist schwierig. Es bekommt Daten von Anwendungsschicht Protokollen wie HTTP und versendet sie gesichert per Transport- Protokoll wie TCP. Hierbei übernimmt es Aufgaben und Eigenschaften aus beiden Schichten, daher ist SSL/TLS irgendwo zwischen der Anwendungsschicht (Application layer) und der Transportschicht (Transport layer) einzuordnen. Im ISO/OSI Modell mit sieben Schichten kann man TLS eindeutiger den Schichten vier und fünf, also Sitzungs- und Transportschicht zuordnen. Fig. 1. Einordnung von TLS in das Schichtenmodell des Internets, angelehnt an Figure 4.1 aus [4] Betrachtet man den Aufbau des SSL/TLS Protokolls, lässt sich die Einordnung nachvollziehen: TLS besteht wiederum aus zwei Schichten, das Record Protokoll als untere Schicht sorgt für Verschlüsselung, Integrität und Authentizität bei allen darauf aufbauenden Protokollen und ist sitzungsbasiert. Unterstützt vom ChangeCipherSpec Protokoll wird mit dem Handshake Protokoll eine sichere Verbindung ausgehandelt, das Alert Protokoll sorgt für verständliche Fehlermeldungen und über das Application Data Protokoll werden letztendlich die Daten der Anwendungsschicht gesichert übertragen. In den folgenden Kapiteln werden die Protokolle eingehender betrachtet. 3.1 TLS Record Protokoll Die Basis für die anderen TLS Protokolle stellt das TLS Record Protokoll bereit. Eingehende Daten durchlaufen mehrere Schritte, für die jeweils eine Operation und eine resultierende Datenstruktur vorgegeben sind. Diese Algorithmen sind austauschbar, und die Operationen des TLS Record Protokolls verwenden die in der aktiven CipherSuite spezifizierten Algorithmen. Für jede Verbindung wird mithilfe des TLS Handshake Protokolls eine solche CipherSuite festgelegt. Sie besteht aus mehreren Algorithmen. Es wird aufgeführt, 7

8 welcher Key Exchange Algorithmus für den Schlüsselaustausch 3 und welcher generelle Verschlüsselungsalgorithmus zur Verschlüsselung der Daten eingesetzt werden soll, sowie mit welchem Hash-Algorithmus ein Message Authentication Code erzeugt werden soll. Ist kein Key Exchange Algorithmus angegeben, spricht man von einer CipherSpec. Am Ende gibt das TLS Record Protokoll die Daten als SSL/TLS Record an ein verbindungsorientiertes Transportprotokoll aus. Aber auch verbindungslose oder unsichere Transportprotokolle können mit entsprechenden Anpassungen verwendet werden, beispielsweise wurde für UDP eine TLS Version namens Datagram Transport Layer Security (DTLS) entwickelt, das mit Paketverlust und unsicherer Paketreihenfolge umgehen kann. Der Ablauf des TLS Record Protokolls wird im Folgenden detailliert beschrieben, eine Übersicht ist in Abbildung 2 zu finden. Erhält eine Implementierung des TLS Record Protokolls Anwendungs-Daten von einer darüberliegenden Schicht des TLS Protokolls, wie dem Application Data Protokoll, so werden diese zuerst fragmentiert, also in Blocks (mit einer Maximalgröße von 2 14 Bytes) unterteilt. Jeder resultierende Block wird in eine Datenstruktur gepackt, die im Protokoll TLSPlaintext genannt wird, und zusätzlich Nachrichten-Typ, SSL/TLS- Version und Nachrichten-Länge enthält. Einzelne Nachrichtenblöcke der höherliegenden Protokolle werden hier zusammengefasst, sodass zum Beispiel auch mehrere Application Data Nachrichten in einem TLS Record landen können. Dieser TLSPlaintext wird als nächstes mit einem Kompressionsverfahren komprimiert, welches bestimmte Konditionen erfüllen muss 4. Häufig wird allerdings keine Kompression verwendet - in SSL 3.0 wurden beispielsweise gar keine Kompressionsalgorithmen spezifiziert. An die resultierende Datenstruktur TLSCompressed (die die 3 Attribute von TLSPlaintext übernimmt) wird nun ein Message Authentication Code (MAC) angehängt. 3 4 wird für das TLS Record Protokoll nicht benötigt Das Kompressionsverfahren für das TLS Record Protokoll darf den Datenblock nicht um mehr als 1024 Bytes vergrößern. Vor allem bei sehr kleinen Datenblöcken ist das relevant. 8

9 Fig. 2. Die Operationen und Datenstrukturen des TLS Record Protokoll Durch den MAC wird die Integrität der übertragenen Daten, also der Anwendungsdaten mitsamt der Attribute, garantiert. Falls auf dem Übertragungsweg Daten verändert würden oder verloren gingen, würde der MAC nicht mehr zur Nachricht passen. Bei SSL wurde der MAC mithilfe eines zweistufigen Hash-Algorithmus aus dem Mastersecret 5, der Sequenznummer der Nachricht und den Anwendungsdaten generiert. Während die zu verwendenden Hash-Algorithmen hier fest vorgegeben waren (die mittlerweile unsicheren MD5 oder SHA-1), wurde für TLS das Verfahren komplett überarbeitet und auf Keyed-Hash Message Authentication Code (H-MAC) umgestellt. Dieses erlaubt es jetzt theoretisch, einen beliebigen Hash-Algorithmus zu verwenden 6. Wie auch bei SSL wird ein H-MAC Geheimnis aus dem Mastersecret erstellt und zusammen mit den TLSCompressed Daten in die H-MAC Funktion eingespeist, weitere Daten sind nicht nötig. Der Block aus TLSCompressed-Daten und angehängtem (H)MAC wird nun zu TLSCiphertext verschlüsselt. Welche Verschlüsselung verwendet werden soll, ist in der CipherSpec festgesetzt. Grundsätzlich können Stromchiffren oder Blockchiffren verwendet werden, wobei für Blockchiffren entsprechend ein Padding angehängt werden muss, um die Datenlänge auf ein Vielfaches der Block-Länge zu bringen. Außerdem kann für manche Blockchiffren ein Initialisierungsvektor nötig sein, um 5 6 Das Mastersecret wird zwischen den Kommunikationspartnern mithilfe des Handshake Protokolls ausgemacht. Praktisch wird die Auswahl an Hash Algorithmen durch die Verfügbarkeit in CipherSpecs eingeschränkt. Diese werden allerdings durch das IETF kontinuierlich erweitert. 9

10 den ersten Datensatz zu verschlüsseln. Dieser wird mithilfe des Sitzungsidentifikators des TLS Handshake Protokolls gewonnen. Wurden die Daten erfolgreich verschlüsselt, wird zuletzt vorne an den TLSCiphertext ein Record Header angefügt. Dieser besteht wie bei den Datenstrukturen TLSCompressed und TLSPlaintext aus Nachrichten-Typ, SSL/TLS Version sowie der ursprünglichen Länge der Daten. Zusammen ergeben Header und Ciphertext einen TLS Record, der jetzt versendet wird. Jede dieser Operationen ist optional, wodurch das TLS Record Protokoll sehr flexibel von allen höheren TLS-Protokollen angesprochen werden kann. Für die initiale Kommunikation kommt beispielsweise kaum eine der Operationen zum Einsatz - bis ein gemeinsames Mastersecret und die CipherSpec festgelegt wurden, ist Verschlüsselung oder das Erstellen eines MAC schließlich nicht möglich [4] [5]. 3.2 TLS Handshake Protokoll Als zweites wichtiges Protokoll sorgt das TLS Handshake Protokoll dafür, dass sich die Kommunikationspartner authentifizieren, sich auf eine CipherSuite einigen und schließlich ein gemeinsames Mastersecret vereinbaren. Diese Daten spezifizieren den Sitzungszustand, daher ist das Protokoll zustandsbehaftet. Der prinzipielle Ablauf ist auch in Abbildung 3 nachzuverfolgen. Im ersten Schritt sendet der Client eine ClientHello Nachricht an den Server. Diese ist natürlicherweise noch unverschlüsselt und besteht im Wesentlichen aus Zeitstempel, Zufallszahl, Sitzungsidentifikator, CipherSuites sowie Komprimierungsmethoden. Als CipherSuites sowie Komprimierungsmethoden gibt der Client alle von ihm unterstützten Methoden mit. Erhält der Server die ClientHello Nachricht, überprüft er zuerst den Record Header. Als SSL/TLS Version für die Verbindung nimmt er die Version aus dem Header, falls er allerdings nur eine niedrigere Version unterstützt, wählt er diese (aber immer höchstmöglich). Da der Client immer die höchste von ihm unterstützte SSL/TLS Version im ClientHello versendet, wird für die Kommunikation somit die höchstmögliche Version etabliert. In diesem zweiten Schritt nun verifiziert der Server die Parameter der ClientHello Nachricht, wählt aus den CipherSuites sowie den Komprimierungsmethoden jeweils eine aus, die von ihm unterstützt wird. Diese Daten versendet der Server nun an den Client, durch das TLS Record Protokoll wird außerdem die SSL/TLS Version mit zurückgegeben. Client und Server haben dadurch für die Verbindung die bestmöglichen Protokollversionen und Algorithmen festgelegt, die auch für künftige Sitzungen verwendet werden. Um sich nun gegenüber dem Client zu authentifizieren, kann der Server zusätzlich noch in Schritt zwei des Protokolls ein Zertifikat mitsenden. Dieses Zertifikat besteht aus mehreren öffentlichen Schlüsseln - dem öffentlichen Schlüssel des Servers sowie der übergeordneten Authorities (dazu mehr in Kapitel 3.3) - und wird in einer Certificate Nachricht gesendet.. Alternativ kann der Server einen temporären öffentlichen Schlüssel per Server- KeyExchange Nachricht übermitteln. 10

11 Möchte der Server auch den Client authentifizieren (was im Internet sehr selten praktiziert wird) sendet er noch eine CertificateRequest Nachricht zum Client, der dann seinerseits im nächsten Schritt mit einem Zertifikat aufwarten muss. Hat der Server diese Nachrichten alle abgeschlossen, folgt ein ServerHelloDone, um zu signalisieren, dass alle Nachrichten des Schrittes gesendet wurden. Diese Nachrichten können meist alle gesammelt in einen TLS Record gepackt werden, da die Länge aller Nachrichten die Fragmentgröße nicht übersteigt. Fig. 3. Der Ablauf des TLS Handshake Protokoll Der Client überprüft in Schritt 3 zunächst die Nachrichten. Falls alle Werte von ihm akzeptiert werden, und das Server Zertifikat gültig ist, sendet er falls gefordert sein Zertifikat, und daran anschließend eine ClientKeyExchange Nachricht. Diese enthält die entscheidenden Daten um serverseitig Daten zu verschlüsseln. Je nach ausgehandeltem Key Exchange Algorithmus kann das ein Pre-Master-Secret sein, das mithilfe des öffentlichen Schlüssels des Servers verschlüsselt wird, oder ein Datenblock für den Diffie-Hellmann Algorithmus. Muss sich auch der Client authentifizieren, sendet er eine mit seinem geheimen Schlüssel signierte Nachricht namens CertificateVerify an den Server, sodass dieser überprüfen kann, dass der Client das Zertifikat auch wirklich besitzt. Bevor der Client mit einer Finished Nachricht an den Server meldet, dass alle Nachrichten des Schrittes drei gesendet wurden, sendet er noch eine ChangeCipherSpec 11

12 Nachricht. Sie signalisiert dem Empfänger, dass ab jetzt die ausgehandelte CipherSuite verwendet wird. Da diese allerdings nicht mehr zum TLS Handshake Protokoll gehört, sondern ihr eigenes Protokoll hat, wird sie in Kapitel 3.4 genauer betrachtet. Wie durch die ChangeCipherSpec angekündigt, wird die Finished Nachricht als Erste Nachricht mit den ausgehandelten Verschlüsselungsalgorithmen und Schlüsseln geschützt. Dies wird im darunterliegenden TLS Record Protokoll umgesetzt [6]. Der Server sendet, nach optionaler Überprüfung des Client Zertifikats, ebenfalls eine ChangeCipherSpec gefolgt von einer Finished Nachricht. Client und Server haben dank des Key Exchange Algorithmus jetzt beide das gleiche pre-master-secret und berechnen aus Diesem und den Zufallszahlen der HelloMessages unabhängig voneinander das MasterSecret. Mithilfe des MasterSecret werden die Schlüssel für HMAC, Verschlüsselung und den eventuell für Blockchiffren benötigten Initialisierungsvektor generiert. Alle Parameter des TLS Record Protokolls sind jetzt vorhanden und der Status für das TLS Record Protokoll wechselt daher von pending auf current. Die Kommunikation in beide Richtungen ist damit gesichert und die Übertragung von Anwendungsdaten mithilfe des Application Data Protokolls kann beginnen [3] [4]. 3.3 TLS Public Key Infrastructure TLS nutzt für die eindeutige Identifizierung eines Kommunikationspartners Zertifikate. Diese Zertifikate beinhalten im Wesentlichen den öffentlichen Schlüssel des Inhabers, dessen Name und einen Gültigkeitszeitraum. Außerdem muss das Zertifikat von einer Certificate Authority (CA), also einer Zertifizierungsstelle mit deren geheimen Schlüssel signiert sein. Diese Zertifizierungsstellen befinden sich in einer Hierarchie, in der übergeordnete Zertifizierungsstellen die Zertifikate der untergeordneten Zertifizierungsstellen signieren, und garantieren, dass die untergeordnete Zertifizierungsstelle geeignet und vertrauenswürdig ist. Somit muss jeder Benutzer nur wenigen übergeordneten Zertifizierungsstellen vertrauen und kann für jedes Zertifikat die Hierarchie nach oben durchgehen und überprüfen, ob eine Zertifizierungsstelle auf dem Weg liegt, der vertraut wird. Im Detail nimmt man jeweils den öffentlichen Schlüssel der angegebenen Zertifizierungsstelle und prüft, ob das zu prüfende Zertifikat korrekt, also mit dem zum öffentlichen Schlüssel passenden geheimen Schlüssel, signiert wurde [7]. Man nenn diese Konstellation die Public Key Infrastructure (PKI) von TLS. Ob ein Kommunikationspartner bei TLS wirklich der ist, für den er sich ausgibt, und ob dem Kommunikationspartner vertraut werden kann, hängt also allein davon ab, welchen Zertifizierungsstellen man vertraut. In der Praxis findet sich in Browsern eine Liste von vertrauenswürdigen Root CAs, also CAs die sich selbst ein Zertifikat ausgestellt haben, und damit an der Spitze der Hierarchie stehen. Damit wirdallen Zertifikaten die valide von diesen oder untergeordneten CAs vergeben wurden, automatisch vertraut. Das Überprüfen der Kette von CAs übernimmt meist der Browser. 12

13 3.4 TLS Change Cipher Spec Protokoll Das Change Cipher Spec Protokoll beschreibt eine einzige, ein Byte lange Nachricht die ChangeCipherSpec Nachricht. Durch diese Nachricht wird beim Handshake Protokoll signalisiert, dass ab jetzt die verhandelte CipherSuite angewendet wird. Die Nachricht ist als eigenes Protokoll spezifiziert, da im TLS Record Protokoll eingehende Nachrichten des gleichen Typs, also Protokolle zusammengefasst werden können. Wäre die ChangeCipherSpec Nachricht also Teil des Handshake Protokolls, könnte innerhalb eines Fragmentes für das TLS Record Protocol die Notwendigkeit bestehen, die vorige Nachricht (z.b. CertificateVerify, siehe Abbildung 4) nicht zu verschlüsseln, die Nachfolgende (z.b. Finished) wegen des Wechsels zur CipherSuite aber zu verschlüsseln. Da aber das TLS RecordProtokoll ein Fragment entweder verschlüsseln kann, oder eben nicht, wurde ein eigenes Protokoll eingeführt. Somit wird die Nachricht im TLS Record Protokoll einzeln verarbeitet [3]. 3.5 TLS Alert Protokoll Für jegliche Fehler oder Warnmeldungen ist bei TLS das Alert Protokoll zuständig. Mit dem Protokoll kann dem Kommunikationspartner mitgeteilt werden, was für ein Problem aufgetreten ist. Dazu enthält es 2 Bytes: Eines zur Einordnung der Schwere des Fehlers (in TLS 1.2 entweder Warnung oder fataler Zustand welcher zum Abbruch der Verbindung führt), und ein Byte für die Alarmsituation. Mit den SSL/TLS Versionen wurde die Anzahl der Fehlermeldungen kontinuierlich erhöht. Ein Beispiel ist der handshake_failure, der dem Kommunikationspartner mitteilt, dass mit den gegebenen Optionen keine passenden Sitzungsparameter gefunden werden konnten. Er ist ein fataler Zustand und führt also zum Verbindungsabbruch. Allerdings kann die Schwere des Fehlers auch vom Kommunikationspartner interpretiert werden, wenn es kein fataler Zustand ist. Warnungen können also beispielsweise trotzdem zum Abbruch führen. 3.6 TLS Application Data Protokoll Wurde eine Verbindung zwischen Server und Client mithilfe des Handshake Protokolls erfolgreich hergestellt, werden alle weiteren eingehenden Daten des darüberliegenden Protokolls (z.b. HTTP) vom Application Data Protokoll behandelt. Nach dem Protokoll werden die eingehenden Daten ohne Veränderung dem TLS Record Protokoll übergeben, welches für die Sicherung sorgt. 3.7 Kryptographie und Hash Verfahren Für jede SSL und TLS Version sind mehrere CipherSuites definiert, die sich mit jeder Version geändert haben, da bestimmte Kombinationen oder Algorithmen sich zwischenzeitlich als unsicher oder anderweitig unbrauchbar herausstellten. Da es als Basis für Kapitel 4 hilfreich ist, wird ein Verschlüsselungsalgorithmus (RC4) im Detail betrachtet. 13

14 RC4 ist eine Stromchiffre, sie verschlüsselt also einen Strom von Daten, die bereits 1980 entwickelt wurde. Obwohl seitdem viele Schwachstellen entdeckt wurden und der Einsatz nicht empfohlen wird, ist sie für SSL/TLS gesicherte Verbindungen immer noch oft im Einsatz. Zuerst wird ein initialer Array mit Werten von 0 bis 255 vorbelegt. Mithilfe des Schlüssels wird dann jeder Wert des Arrays verschoben. Die zu verschlüsselnden Daten werden danach mithilfe des Arrays Byte für Byte verschlüsselt (Hierfür verwendet RC4 die XOR Operation). Nach jedem Schritt werden im Array zwei Werte vertauscht. Entschlüsselt wird mit dem selben Algorithmus. RC4 ist mittlerweile als unsicher eingestuft und sollte nicht mehr verwendet werden [8]. TLS 1.2 verwendet mittlerweile weder RC4 noch das unsichere Hashverfahren MD5, sondern setzt allein auf AES Verschlüsselung im CBC (Cipher Block Chaining Mode) oder GCM (Galois / Counter Mode), da für beide Modi noch keine Sicherheitslücken gefunden wurden und auch AES mit längerer Schlüssellänge noch als sicher gilt. Als Hashverfahren wird ausschließlich SHA mit hohen Bit-Größen eingesetzt. Nur die ursprüngliche Vielfalt an Key Exchange Algorithmen ist weiterhin gegeben, sodass RSA und viele Varianten des Diffie-Hellmann Algorithmus weiterhin bestandteil von TLS 1.2 sind und verwendet werden können. 3.8 Implementierungen des Protokolls Auch wenn ein Protokoll wie TLS/SSL vollständig sicher sein sollte, entstehen trotzdem die meisten Fehler noch bei der Implementierung des spezifizierten Protokolls. Da derartige Aufgaben nur Sicherheitsexperten und Kyptographiespezialisten durchführen sollten, setzen auch nahezu alle, die TLS verwenden wollen, auf bereits fertige Bibliotheken. Die am häufigsten verwendete Bibliothek ist die OpenSource Implementierung von SSL/TLS namens OpenSSL. Für alle verbreiteten Betriebssysteme ist OpenSSL verfügbar, und alle SSL/TLS Versionen samt DTLS Versionen werden unterstützt. Als weitere weitverbreitete Bibliothek bietet die Java Secure Socket Extension (JSSE) für die Programmiersprache JAVA die Möglichkeit, per TLS verschlüsselte Verbindungen aufzubauen. Während der Umgang mit der Bibliothek zu Beginn noch kompliziert war, und kleine Fehler in der Verwendung der API zu großen Sicherheitslücken führen konnten, wurden diese Fehler mittlerweile behoben und auch TLS 1.1 und TLS 1.2 eingebunden. 4 Angriffsmöglichkeiten und Sicherheitslücken SSL/TLS ist durch die Verwendung im Internet wohl das am meisten genutzte und auch das bekannteste Verschlüsselungsprotokoll der Welt. Durch diese weite Verbreitung steht das Protokoll allerdings ebenfalls von Beginn an im Fokus von Forschern aber auch Kriminellen, die das Protokoll auf Schwachstellen und Fehler abklopfen. Doch nicht nur das Konzept, auch die verschiedenen Implementierungen des Proto- 14

15 kolls können Fehler enthalten, die an sich nichts mit SSL/TLS zu tun haben, aber zum Zusammenbruch der Verschlüsselung führen können. 4.1 Verwundbarkeiten im Protokoll Die Mehrzahl der Schwachstellen von SSL/TLS sind auf die verwendeten Verschlüsselungs- und Hash-Algorithmen zurückzuführen. Daher sind seit TLS 1.0 keine Algorithmen mehr im Protokoll selbst fest vorgegeben. Es wird vielmehr eine Auswahl an Algorithmen, die CipherSuites, zur Verfügung gestellt welche beständig um sicherere Algorithmen ergänzt und um gebrochene Algorithmen gekürzt werden. Im Folgenden werden erfolgreiche Angriffe auf SSL/TLS betrachtet, deren Ansatzpunkt die verwendeten Algorithmen oder die Architektur des Protokolls sind [9]. TLS-Kompression: CRIME, TIME und BREACH. Einige Angriffe zielen auf die Komprimierungsfunkion des TLS Record Protocols ab. Die Komprimierungsfunktion wird im Handshake festgesetzt, in der Praxis wird oft null, also gar keine Komprimierungsfunktion verwendet. Sonst werden meist DEFLATE Protokolle wie zlib oder gzip verwendet. DEFLATE vereint zwei Algorithmen um Daten zu komprimieren: Der Lempel-Ziv-Storer- Szymanski-Algorithmus (LZ77) sucht nach Wiederholungen in den Daten und ersetzt diese mit einem Verweis auf das erste Vorkommen. Anschließend werden mit der Huffman Codierung häufige Zeichen durch kürzere Zeichen ersetzt um insgesamt eine möglichst geringe Dateigröße zu erreichen [10] Zwei Forscher stellten 2012 den Compression Ratio Info-Leak Made Easy Angriff oder kurz CRIME vor. Die Attacke nutzt aus, dass die Länge der komprimierten Daten bekannt ist und in den Klardaten häufig ein geheimes Session Cookie enthalten ist, welches mit komprimiert wird. Ist es dem Angreifer möglich, Klardaten einzuschleusen, die anschließend komprimiert und verschlüsselt werden 7, kann er über die Länge des komprimierten und verschlüsselten Ergebnisses Rückschlüsse auf das geheime Session Cookie ziehen. Falls es nämlich Übereinstimmungen zwischen dem Geheimnis und den gewählten Klardaten gibt, werden diese durch den LZ77 eliminiert und das komprimierte Ergebnis ist kürzer als ohne Übereinstimmung. Um das geheime Cookie zu bekommen, testen die Angreifer mithilfe der Fenstergröße des Verschlüsselungsalgorithmus. Der LZ77 Algorithmus der Komprimierungsfunktion sucht nach übereinstimmenden Daten nur innerhalb eines definierten Fenster. Um herauszubekommen ob bestimmte Zeichen im geheimen Cookie vorkommen, werden zwei Anfragen geschickt. Einmal liegt das zu prüfende Zeichen innerhalb des Fensters, einmal außerhalb. War die Länge der Antwort zur Anfrage kürzer, bei der das geprüfte Zeichen im Fenster lag, gibt es eine Übereinstimmung mit dem geheimen Cookie, und es wird mit dem nächsten Zeichen fortgefahren. Mit nicht zu vielen Anfragen lässt sich somit das geheime Cookie erfragen. Für TLS wurde außerdem noch eine andere Möglichkeit gefunden, falls die Fenstergröße nicht bekannt ist. Da bei 7 Diese Art von Angriff ist besser bekannt als Chosen-Plaintext Attack 15

16 einer bestimmten Größe ein TLS Request gesplittet wird, schickt man Anfragen die minimal größer sind, werden sie in der Antwort nicht gesplittet, muss sie kleiner sein. [11]. CRIME war bereits eine Weiterentwicklung von BEAST (Browser Exploit Against SSL/TLS), welches Blockchiffren mithilfe des Initialisierungsvektors aushebeln konnte ( In TLS 1.1 wurde das Problem durch individuelle Initialisierungsvektoren behoben). Ebenso wurde CRIME zu TIME (Timing Info-leak Made Easy) weiterentwickelt, welches einige Schwächen des Angriffs behoben hat. Bei TIME wird nicht mehr die Länge der Antwort abgefragt, sondern die Zeit gemessen, die eine Antwort braucht. Da Anfragen immer am Limit zum Splitting gesendet werden, braucht eine kürzere Antwort weniger Zeit als eine Antwort, die auf zwei Antworten gesplittet werden muss. Durch dieses Vorgehen ist es nicht (wie noch bei CRIME) nötig, die gesamte Kommunikation mitzuschneiden. Man muss also nicht Man in the Middle spielen, sondern nur noch z.b. Javascript auf dem angegriffenen Rechner ausführen. Diese Lücke wurde durch das Deaktivieren der TLS-Komprimierung bei allen gängigen Browsern geschlossen, und auch serverseitig wurde TLS-Komprimierung deaktiviert. Zusätzlich wird häufig empfohlen zusätzliche zufällige zeitliche Verzögerungen in den Verschlüsselungsalgorithmus einzubauen und CAPTCHAs gegen die Vielzahl von automatisierten Abfragen, die für diese Attacken notwendig sind, einzusetzen [12]. Als neueste Fortführung der ursprünglichen CRIME Attacke gilt BREACH ( Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext). Es nutzt nicht mehr die TLS Komprimierung aus, sondern die immer noch eingesetzte HTTP response compression. Wie CRIME und TIME nutzt es die Länge der Antwort und induziert Klartext in die Server-Anfrage. Da es allerdings auf HTTP Kompression setzt, kann die TLS Verschlüsselung umgangen werden 8 [13]. Da das Abschalten der HTTP aufgrund immenser Leistungsverluste nicht praktikabel wäre, werden andere Lösungen empfohlen. Eine Strategie ist es, die Länge einer Anfrage durch überflüssige Daten künstlich und zufällig zu verändern. Außerdem ist eine Voraussetzung für den Angriff, dass das herauszufindende Geheimnis in allen Antworten gleich ist, und daher kann eine Maskierung mit einer zufälligen Zahl ein Herausfinden desselben verhindern. Renegotiation und Triple-Handshake Probleme Wie beim TLS Record Protocol und dessen Komprimierungsfähigkeit gibt es auch einige Angriffe, die auf den Ablauf nach dem Handshake Protokoll zielen. Mithilfe der Renegotiation attack (etwa: Neuverhandlungs-Angriff) können in eine verschlüsselte Kommunikation zwischen zwei Kommunikationspartnern Nachrichten eingebracht werden, die von einem Partner als valide eingestuft und behandelt werden. Dafür verwendet die Attacke die Möglichkeit bei TLS, eine TLS-Sitzung neu zu verhandeln. Der Angriff ist ein Man-in-the-middle Angriff: der Angreifer muss in der Lage sein, den Datenverkehr des Clients zum Server abzufangen. 8 Diese Angriffsart nennt man auch side-channel attack 16

17 Zuerst baut der Angreifer eine Verbindung zum Server auf und kann beliebige Anfragen senden und empfangen. Sendet der Client nun eine Anfrage an den Server, fängt der Angreifer diese ab, und leitet sie über seine gesicherte bestehende Verbindung weiter. Dadurch erfährt der Client einen normalen Verbindungsaufbau, während der Server die Anfrage des Clients als Neuverhandlung der bestehenden Verbindung versteht. Letztendlich interpretiert der Server daher die ursprünglichen Anfragen des Angreifers an den Server als vom Client kommend. Der Angreifer kann also beliebigen Code vor den vom Client gesendeten Code einfügen, und damit großen Schaden anrichten, auch wenn er den weiteren Datenverkehr nicht mehr abhören kann. Einfache Kontrollmethodiken für die Neuverhandlung können diesen Angriff allerdings unterbinden [14]. Ein etwas anderer Angriff namens 3Shake allerdings ermöglicht es einem Angreifer die Kommunikation komplett zu übernehmen, sich gegenüber dem Client also als Server auszugeben, ohne dass dieser erkennen kann, nicht mehr mit dem Server zu kommunizieren. Für diesen Angriff ist es notwendig, dass RSA oder DHE als Key Exchange Algorithmus verwendet wird. Ist dies der fall, kann sich der Angreifer beim Verbindungsaufbau zwischen Client und Server schalten, und nach dem ServerHello das Zertifikat des Servers durch ein eigenes ersetzen. Das ursprüngliche Zertifikat des Servers verwendet der Angreifer anschließend um die vom Client zurückkommende ClientKeyExchange Nachricht dementsprechend zu verändern, damit der Server sie annimmt. Dadurch gelangt der Angreifer in den Besitz des Master-secrets (bzw. premaster-secrets). Da aber die abschließenden Finished Nachrichten Hashes der vorherigen Nachrichten enthalten, welche von Client und Server ja unterschiedliche empfangen bzw. gesendet wurden, stimmen diese nicht überein. Weil beide Teilnehmer das bereits festgesetzte Master-secret speichern, kann mithilfe eines Session Resumption Handshakes, bei dem lediglich die Nachrichten-Schlüssel neu verhandelt werden, zwischen beiden Teilnehmern wieder eine valide Kommunikation hergestellt werden. Bei diesem Session Resumption Handshake werden die bei beiden Parteien unterschiedlichen Zertifikate nicht mehr abgefragt und daher kommt es zu einer gleichen Finished Nachricht bei Beiden, die also vom Kommunikationspartner akzeptiert wird. Somit kann der Angreifer beliebige Nachrichten an den Server senden, von denen der Server glaubt sie kämen vom Client, und danach die Verbindung zwischen beiden erfolgreich herstellen. Eine Lösung für dieses Problem ist das Verwenden eines Hashes über vorherige Nachrichten mit dem Mastersecret zusammen, sodass die vom Angreifer manipulierten Nachrichten auffallen und die Attacke nicht mehr möglich ist [15] [16] [17]. Verschlüsselungsverfahren RC4: RC4 biases attack Während lange Zeit SSL/TLS mit RC4 Verschlüsselung zwar nicht empfohlen wurde, aber dank der Schnelligkeit, und aufgrund der Tatsache, dass es noch keine Attacke gab, die die Entschlüsselung in SSL/TLS knacken konnte, von allen großen Anbietern für die Verschlüsselung verwendet wurde, wurde 2013 mit der RC4 biases attack ein Angriff veröffentlicht, mit dem geheime Daten - wie bei CRIME und seinen Nachfolgern - aus den Anfragen extrahiert werden können. 17

18 Der Angriff basiert darauf, dass über die ersten 257 Bytes einer mit RC4 verschlüsselten Nachricht statistische Aussagen getroffen werden können. Manche Werte kommen häufiger vor als andere. Da im verschlüsselten Text von RC4 jedes verschlüsselte Byte immer noch an der ursprünglichen Stelle des unverschlüsselten Bytes zu finden ist, kann mithilfe von im verschlüsselten Text bekannten Elementen wie z.b. HTTP Header oder URLs in einigen Versuchen der Klartext herausgefunden werden [9]. Als Lösung wurde RC4 modifiziert, damit die ersten paar Durchläufe des Algorightmus verworfen werden. Auch kann anstatt von RC4 ein anderer Verschlüsselungsalgorithmus verwendet werden [18]. Sichere Zertifikate? Angriffe auf die Public Key Infrastruktur Die Public Key Infrastruktur von TLS/SSL wurde ebenfalls bereits mehrfach umgangen. Verschiedene Ansatzpunkte wurden von Angreifern hier bisher ausgenutzt, um an Zertifikate zu gelangen, die nicht für sie authorisiert waren. Ein Weg führte über das Hacken einer Zertifizierungsstelle, sodass sich die Angreifer für große Anbieter wie Google oder Facebook valide Zertifikate beschaffen konnten. Damit konnten sie diese Anbieter mitsamt verschlüsselter Verbindung fälschen, wodurch ein Client mit gesicherter Verbindung auf einen solchen gefälschten Server zugreifen konnte und sicher war, auf den authentifizierten Servern unterwegs zu sein. Erst Monate später wurde entdeckt, dass diese Zertifikate erstellt wurden, und sie wurden deaktiviert. Eine andere Herangehensweise führte über CAs, die keine ausreichenden Prüfungen veranlassten. Aufgrund des Konkurrenz- und Preiskampfes zwischen den CAs werden die vorgesehenen Prüfungen bei der Zertifikat-Emission teilweise nur unzureichend durchgeführt, wodurch auch Unberechtigte oder anonyme Personen an derartige Zertifikat kommen können. Diesem Problem versuchten die größten Anbieter durch eine Erweiterung des Zertifikatsystems entgegenzuwirken. Die neu eingeführten Extended Validation Certificates werden nur nach besonders strengen Prüfungen von speziellen CAs herausgegeben, kosten dementsprechend mehr, aber werden bei allen aktuellen Browsern zusätzlich zum üblichen Schlosssymbol durch eine grün hinterlegte Browser-Bar sowie dem Namen des Zertifikatinhabers und der Zertifizierungsstelle eindeutig gekennzeichnet. Besonders Banken setzen auf die zusätzliche Sicherheit dieses Zertifikats, da jeder Benutzer leichter erkennen kann, ob er sich auch wirklich auf der richtigen Seite befindet. 4.2 Fehler in Implementierungen Heartbleed Bug in OpenSSL Im April 2014 wurde in OpenSSL - der quasi Standard-Bibliothek auf Webservern, die TLS/SSL verschlüsselte Verbindungen anbieten - der Heartbleed-Bug entdeckt. Dieser schwerwiegende Fehler in einer Erweiterung der TLS Implementierung namens Heartbeat erlaubt es einem Angreifer, geheime Daten aus dem sicheren Speicher des Servers zu extrahieren. Dazu gehören Benutzername und Passwort, aber auch die geheimen privaten Zertifikatschlüssel der Server. Die Heartbeat-Erweiterung bringt die normalerweise auf Netzwerkebene übliche Funktion, abzufragen ob die Verbindung zum Kommunikationspartner noch steht, in 18

19 die Transportschicht. Mithilfe von Heartbeat kann ein bis zu 16 kbyte großer Datenblock beliebiger Daten an den Kommunikationspartner gesendet werden, welche dieser unverändert zurücksendet. Durch einen Fehler in der Implementierung wurde allerdings nicht überprüft, ob die für den Datenblock angegebene Länge auch wirklich an Nutzdaten gesendet wurde. Dadurch kann ein Angreifer einen Datenblock von beispielsweise einem kbyte senden, aber im entsprechenden Feld eine Größe von bis zu 64 kbyte angeben 9. Der Server empfängt die Daten, speichert das kbyte an Daten in seinen speziellen, sicheren Speicher und möchte den Heartbeat zurücksenden. Hierzu holt er sich die gespeicherten Daten wieder aus dem sicheren Speicher - als Länge verwendet er die vom Client gesendeten 64 kbyte - und sendet diese zurück. Da aber nur ein kbyte an Daten überhaupt gespeichert wurde, sind die restlichen 63 kbyte an Daten aus dem Arbeitsspeicher, die mitgesendet werden, beliebige Daten von anderen Verbindungen oder Aufgaben, die der Server parallel gerade ausführt. Dieser Angriff kann sehr oft ausgeführt werden und hinterlässt beim Server keinerlei Spuren, da kein Fehler oder Absturz provoziert wird. Mithilfe der gewonnenen Geheim-Daten können dann beispielsweise TLS gesicherte Verbindungen entschlüsselt werden. Mit der Ankündigung des Fehlers von den Entwicklern wurde gleichzeitig ein entsprechender Patch herausgegeben. Die Länge des Datenpakets wird nach dem Patch korrekt überprüft [19] [20] [21]. 5 Zusammenfassung und Ausblick Der Heartbleed-Bug sorgte für Aufregung im Internet, da jegliche vermeintlich sichere Kommunikation auch aus der Vergangenheit eventuell mitgelesen worden sein könnte und auch Zugangsdaten bei quasi allen großen Diensten in andere Hände gelangt sein könnten. Trotzdem sind gut zwei Monate nach der Entdeckung bei einer Untersuchung immer noch die Hälfte der Server nicht aktualisiert worden, wodurch der Heartbleed-Bug ausgenutzt werden kann [22]. Da OpenSSL OpenSource ist, und damit der Quellcode für jedermann einsehbar und überprüfbar ist, ging man lange Zeit davon aus, dass Fehler schneller gefunden und behoben würden. Da der schwerwiegende Heartbleed-Bug jedoch vor der Entdeckung bereits 2 Jahre in der Bibliothek vorhanden war, wurde diese Erwartung enttäuscht. In der Folge bekamen die wenigen Entwickler der Bibliothek, die von Brachenriesen wie Facebook, Google oder Yahoo verwendet wird, finanzielle Unterstützung. Dadurch konnten viele weitere Fehler gefunden und behoben werden. Der immer zugrundeliegende Wettlauf zwischen Sicherheitsexperten und Hackern, die sowohl kriminellen als auch staatlichen Hintergrund haben können, setzt sich daher fort. SSL/TLS hat den großen Vorteil, dass die verwendeten Algorithmen keinesfalls fest implementiert sind, sondern immer wieder ausgetauscht werden können und müssen. Doch es hat sich gezeigt, dass auch die über 20 Jahre entwickelte Architektur des 9 Da die spezifizierte Maximalgröße von 16 kbyte nicht überprüft wird. 19

20 Protokolls noch immer Lücken aufweist, die sodass die drei Grundprinzipien Authentizität, Vertraulichkeit und Integrität auch mit SSL/TLS nicht immer gewährleistet sind. Doch die Fehler haben auch ihr Gutes: der Fokus der Öffentlichkeit und damit auch Fördergelder und Ressourcen richteten sich wieder auf SSL/TLS und werden wohl auch in Zukunft eine Erweiterung und Fortentwicklung dieses quasi einzigen internationalen Verschlüsselungsalgorithmus sicherstellen. 20

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IT-Sicherheit für 04INM 5. Transport Layer Security. 5. 2 Secure Socket Layer Protocol (SSL)

IT-Sicherheit für 04INM 5. Transport Layer Security. 5. 2 Secure Socket Layer Protocol (SSL) IT-Sicherheit für 04INM 5. Transport Layer Security Prof. Dr. Uwe Petermann Dept. of Computer Science University of Applied Sciences Leipzig P.O.B. 300066 D-04251 Leipzig (Germany) uwe@imn.htwk-leipzig.de

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

Mindeststandard des BSI nach 8 Abs. 1 Satz 1 BSIG für den Einsatz des SSL/TLS-Protokolls in der Bundesverwaltung

Mindeststandard des BSI nach 8 Abs. 1 Satz 1 BSIG für den Einsatz des SSL/TLS-Protokolls in der Bundesverwaltung Mindeststandard des BSI nach 8 Abs. 1 Satz 1 BSIG für den Einsatz des SSL/TLS-Protokolls in der Bundesverwaltung Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49

Mehr

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

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

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

IT-Sicherheit WS 2013/14. Übung 11. zum 30. Januar 2014

IT-Sicherheit WS 2013/14. Übung 11. zum 30. Januar 2014 Prof. Dr. C. Eckert Thomas Kittel IT-Sicherheit WS 2013/14 Übung 11 zum 30. Januar 2014 Institut für Informatik Lehrstuhl für Sicherheit in der Informatik 1 SSL/TLS in VoIP In Voice-over-IP (VoIP) Kommunikation

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

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

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

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

> Verteilte Systeme Übung 10 Deadlocks, Fehler, Security Philipp Kegel Sommersemester 2012

> Verteilte Systeme Übung 10 Deadlocks, Fehler, Security Philipp Kegel Sommersemester 2012 > Verteilte Systeme Übung 10 Deadlocks, Fehler, Security Philipp Kegel Sommersemester 2012 Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster

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

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

Kryptographische Verfahren. zur Datenübertragung im Internet. Patrick Schmid, Martin Sommer, Elvis Corbo

Kryptographische Verfahren. zur Datenübertragung im Internet. Patrick Schmid, Martin Sommer, Elvis Corbo Kryptographische Verfahren zur Datenübertragung im Internet Patrick Schmid, Martin Sommer, Elvis Corbo 1. Einführung Übersicht Grundlagen Verschlüsselungsarten Symmetrisch DES, AES Asymmetrisch RSA Hybrid

Mehr

Vorlesung Kryptographie

Vorlesung Kryptographie Vorlesung Kryptographie Teil 2 Dr. Jan Vorbrüggen Übersicht Teil 1 (Nicht-) Ziele Steganographie vs. Kryptographie Historie Annahmen Diffie-Hellman Angriffe Teil 2 Symmetrische Verfahren Asymmetrische

Mehr

SSL, robuster Protokollentwurf und Angriffe

SSL, robuster Protokollentwurf und Angriffe Ausarbeitung SSL, robuster Protokollentwurf und Angriffe Stud. Inf. Doris Diedrich Lehrstuhl für Kryptographie & Sicherheit Prof. Dr. Birgit Pfitzmann Fachbereich Informatik Universität Saarbrücken Im

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

Digital Signature and Public Key Infrastructure

Digital Signature and Public Key Infrastructure E-Governement-Seminar am Institut für Informatik an der Universität Freiburg (CH) Unter der Leitung von Prof. Dr. Andreas Meier Digital Signature and Public Key Infrastructure Von Düdingen, im Januar 2004

Mehr

Security Associations Schlüsseltausch IKE Internet Key Exchange Automatischer Schlüsseltausch und Identitätsnachweis

Security Associations Schlüsseltausch IKE Internet Key Exchange Automatischer Schlüsseltausch und Identitätsnachweis Wie Interoperabel ist IPsec? Ein Erfahrungsbericht Arturo Lopez Senior Consultant März 2003 Agenda Internet Protokoll Security (IPsec) implementiert Sicherheit auf Layer 3 in OSI Modell Application Presentation

Mehr

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet SEC Für ein sicheres Internet Was ist SEC? SEC ist eine Erweiterung des Domain Namen Systems (), die dazu dient, die Echtheit (Authentizität) und die Voll ständig keit (Integrität) der Daten von - Antworten

Mehr

IT-Sicherheit Kapitel 3 Public Key Kryptographie

IT-Sicherheit Kapitel 3 Public Key Kryptographie IT-Sicherheit Kapitel 3 Public Key Kryptographie Dr. Christian Rathgeb Sommersemester 2013 1 Einführung In der symmetrischen Kryptographie verwenden Sender und Empfänger den selben Schlüssel die Teilnehmer

Mehr

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter Datensicherheit Vorlesung 5: 15.5.2015 Sommersemester 2015 h_da, Lehrbeauftragter Inhalt 1. Einführung & Grundlagen der Datensicherheit 2. Identitäten / Authentifizierung / Passwörter 3. Kryptografie 4.

Mehr

Das TLS-Protokoll Transport Layer Security Version 1.0 Seminar: Internet Dienste SS 2004. Christoph Moll 02.07.2004

Das TLS-Protokoll Transport Layer Security Version 1.0 Seminar: Internet Dienste SS 2004. Christoph Moll 02.07.2004 Das TLS-Protokoll Transport Layer Security Version 1.0 Seminar: Internet Dienste SS 2004 Christoph Moll 02.07.2004 1 INHALTSVERZEICHNIS 2 Inhaltsverzeichnis 1 Einleitung 2 1.1 Allgemeines und Geschichte

Mehr

IPsec. Vortrag im Rahmen des Seminars Neue Internet Technologien

IPsec. Vortrag im Rahmen des Seminars Neue Internet Technologien IPsec Vortrag im Rahmen des Seminars Neue Internet Technologien Friedrich Schiller Universität Jena Wintersemester 2003/2004 Thomas Heinze, Matrikel xxxxx Gliederung IPsec? - Motivation, Grundbegriffe,

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

Seminar Neue Technologien in Internet und WWW Sicherheit auf der Anwendungsschicht: HTTP mit SSL, TLS und dabei verwendete Verfahren

Seminar Neue Technologien in Internet und WWW Sicherheit auf der Anwendungsschicht: HTTP mit SSL, TLS und dabei verwendete Verfahren Seminar Neue Technologien in Internet und WWW Sicherheit auf der Anwendungsschicht: HTTP mit SSL, TLS und dabei verwendete Verfahren Seminararbeit im Seminar Neue Technologien in Internet und WWW Wintersemester

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

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr.

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY 1 Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. Bernd Borchert GLIEDERUNG 1. Motivation Gründe für die Entwicklung Ideen für

Mehr

Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen

Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen Agenda 1. Kerckhoff sches Prinzip 2. Kommunikationsszenario 3. Wichtige Begriffe 4. Sicherheitsmechanismen 1. Symmetrische Verschlüsselung

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

Verteilte Systeme. Sicherheit. Prof. Dr. Oliver Haase

Verteilte Systeme. Sicherheit. Prof. Dr. Oliver Haase Verteilte Systeme Sicherheit Prof. Dr. Oliver Haase 1 Einführung weitere Anforderung neben Verlässlichkeit (zur Erinnerung: Verfügbarkeit, Zuverlässigkeit, Funktionssicherheit (Safety) und Wartbarkeit)

Mehr

Inhaltsverzeichnis Vorwort Kryptographie und das Internet Point-To-Point Sicherheit

Inhaltsverzeichnis Vorwort Kryptographie und das Internet Point-To-Point Sicherheit Inhaltsverzeichnis Vorwort... 1 Kryptographie und das Internet... 1 1.1 WasistdasInternet... 2 1.2 BedrohungenimInternet... 5 1.2.1 PassiveAngriffe... 5 1.2.2 AktiveAngriffe... 6 1.3 Kryptographie... 7

Mehr

Vorlesung Sicherheit

Vorlesung Sicherheit Vorlesung Sicherheit Dennis Hofheinz ITI, KIT 05.06.2014 1 / 35 Überblick 1 Schlüsselaustauschprotokolle Symmetrische Verfahren Asymmetrische Verfahren Transport Layer Security (TLS) 2 / 35 Überblick 1

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

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

IT Sicherheit: Netzwerksicherheit: SSL/TLS

IT Sicherheit: Netzwerksicherheit: SSL/TLS Dr. Christian Rathgeb IT-Sicherheit, Kapitel 7 / 11.12.2014 1/67 IT Sicherheit: Netzwerksicherheit: Dr. Christian Rathgeb Hochschule Darmstadt, CASED, da/sec Security Group 11.12.2014 Dr. Christian Rathgeb

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

Ist das so mit HTTPS wirklich eine gute Lösung?

Ist das so mit HTTPS wirklich eine gute Lösung? SSL/TLS und PKI im Internet Erik Tews erik@datenzone.de Ist das so mit HTTPS wirklich eine gute Lösung? 21.05.2012 Erik Tews 1 Was ist PKI Asymmetrische Kryptographie ist echt praktisch Schlüssel bestehen

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

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten Versuch: Eigenschaften einer Unterhaltung Instant Messaging Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten welche Rollen gibt es in einem IM-System? Analysieren

Mehr

Sicherheit in Netzen und verteilten Systemen Prof. Dr. Stefan Fischer. Überblick. Anordnung der Techniken

Sicherheit in Netzen und verteilten Systemen Prof. Dr. Stefan Fischer. Überblick. Anordnung der Techniken TU Braunschweig Institut für Betriebssysteme und Rechnerverbund Sicherheit in Netzen und verteilten Systemen Kapitel 6: Protokolle und Anwendungen Wintersemester 2002/2003 Überblick sec Authentisierungsanwendungen

Mehr

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut

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

Mehr

ESecuremail Die einfache Email verschlüsselung

ESecuremail Die einfache Email verschlüsselung Wie Sie derzeit den Medien entnehmen können, erfassen und speichern die Geheimdienste aller Länder Emails ab, egal ob Sie verdächtig sind oder nicht. Die Inhalte von EMails werden dabei an Knotenpunkten

Mehr

Aktuelle Sicherheitsprobleme im Internet

Aktuelle Sicherheitsprobleme im Internet Herbst 2014 Aktuelle Sicherheitsprobleme im Internet Wirtschaftsinformatik: 5. Semester Dozenten: Rainer Telesko / Martin Hüsler Fachhochschule Nordwestschweiz FHNW / Rainer Telesko - Martin Hüsler 1 Inhalt

Mehr

Kundenleitfaden Secure E-Mail

Kundenleitfaden Secure E-Mail Vorwort Wir leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns elektronische

Mehr

Robert Rex Proseminar Electronic Banking 13. 06. 2002 Protokolle bei Kreditkarten Seite 1 von 5

Robert Rex Proseminar Electronic Banking 13. 06. 2002 Protokolle bei Kreditkarten Seite 1 von 5 Protokolle bei Kreditkarten Seite 1 von 5 1. Einführung Mit der Entwicklung des Internets in den letzten Jahrzehnten hat auch die Bedeutung des E- Commerce immer mehr zugenommen. Um online bestellte Waren

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

Methoden der Kryptographie

Methoden der Kryptographie Methoden der Kryptographie!!Geheime Schlüssel sind die sgrundlage Folien und Inhalte aus II - Der Algorithmus ist bekannt 6. Die - Computer Networking: A Top außer bei security by obscurity Down Approach

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

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

OPC UA: Ein kritischer Vergleich der IT-Sicherheitsoptionen

OPC UA: Ein kritischer Vergleich der IT-Sicherheitsoptionen OPC UA: Ein kritischer Vergleich der IT-Sicherheitsoptionen Melanie Gallinat 1, Stefan Hausmann 2, Markus Köster 1, Stefan Heiss 2 Weidmüller Gruppe 1 Klingenbergstraße 16 32758 Detmold, Deutschland Hochschule

Mehr

Dokumentation über IPSec

Dokumentation über IPSec Dokumentation über IPSec von Joana Schweizer und Stefan Schindler Inhaltsverzeichnis 1 Einleitung...3 1.1 Warum Sicherheit?...3 1.2 Datenschutz allgemein...3 1.3 Datenschutz für eine Firma...3 1.4 Eine

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

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

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns

Mehr

MAC Message Authentication Codes

MAC Message Authentication Codes Seminar Kryptographie SoSe 2005 MAC Message Authentication Codes Andrea Schminck, Carolin Lunemann Inhaltsverzeichnis (1) MAC (2) CBC-MAC (3) Nested MAC (4) HMAC (5) Unconditionally secure MAC (6) Strongly

Mehr

Inhaltsverzeichnis KURZSTUDIE HTTPS (SSL, TLS) ANALYSE ÖSTERREICHISCHER GV.AT DOMÄNEN VERSION 1.3-26. SEPTEMBER 2014

Inhaltsverzeichnis KURZSTUDIE HTTPS (SSL, TLS) ANALYSE ÖSTERREICHISCHER GV.AT DOMÄNEN VERSION 1.3-26. SEPTEMBER 2014 Zentrum für sichere Informationstechnologie Austria Secure Information Technology Center Austria A-1030 Wien, Seidlgasse 22 / 9 Tel.: (+43 1) 503 19 63 0 Fax: (+43 1) 503 19 63 66 A-8010 Graz, Inffeldgasse

Mehr

Vortrag Keysigning Party

Vortrag Keysigning Party Vortrag Keysigning Party Benjamin Bratkus Fingerprint: 3F67 365D EA64 7774 EA09 245B 53E8 534B 0BEA 0A13 (Certifcation Key) Fingerprint: A7C3 5294 E25B B860 DD3A B65A DE85 E555 101F 5FB6 (Working Key)

Mehr

VIRTUAL PRIVATE NETWORKS

VIRTUAL PRIVATE NETWORKS VIRTUAL PRIVATE NETWORKS Seminar: Internet-Technologie Dozent: Prof. Dr. Lutz Wegner Virtual Private Networks - Agenda 1. VPN Was ist das? Definition Anforderungen Funktionsweise Anwendungsbereiche Pro

Mehr

VPN unterstützt 3 verschiedene Szenarien: Host to Host: Dies kennzeichnet eine sichere 1:1 Verbindung zweier Computer, z.b. über das Internet.

VPN unterstützt 3 verschiedene Szenarien: Host to Host: Dies kennzeichnet eine sichere 1:1 Verbindung zweier Computer, z.b. über das Internet. 1. VPN Virtual Private Network Ein VPN wird eingesetzt, um eine teure dedizierte WAN Leitung (z.b. T1, E1) zu ersetzen. Die WAN Leitungen sind nicht nur teuer, sondern auch unflexibel, da eine Leitung

Mehr

Motivation Sicherheit. WLAN Sicherheit. Karl Unterkalmsteiner, Matthias Heimbeck. Universität Salzburg, WAP Präsentation, 2005

Motivation Sicherheit. WLAN Sicherheit. Karl Unterkalmsteiner, Matthias Heimbeck. Universität Salzburg, WAP Präsentation, 2005 Universität Salzburg, WAP Präsentation, 2005 Gliederung 1 WLAN die neue drahtlose Welt Gefahren in WLAN Netzwerken Statistische Untersuchen 2 Gliederung WLAN die neue drahtlose Welt Gefahren in WLAN Netzwerken

Mehr

Prof. Dr. Martin Leischner Netzwerksysteme und TK. Hochschule Bonn-Rhein-Sieg. Modul 5: IPSEC

Prof. Dr. Martin Leischner Netzwerksysteme und TK. Hochschule Bonn-Rhein-Sieg. Modul 5: IPSEC Modul 5: IPSEC Teil 1: Transport- und Tunnelmode / Authentication Header / Encapsulating Security Payload Security Association (SAD, SPD), IPsec-Assoziationsmanagements Teil 2: Das IKE-Protokoll Folie

Mehr

Verschlüsselung und Signatur

Verschlüsselung und Signatur Verschlüsselung und Signatur 1 Inhalt Warum Verschlüsseln Anforderungen und Lösungen Grundlagen zum Verschlüsseln Beispiele Fragwürdiges rund um das Verschlüsseln Fazit Warum verschlüsseln? Sichere Nachrichtenübertragung

Mehr

IT-Sicherheitsmanagement Teil 8: Einführung in die Kryptographie

IT-Sicherheitsmanagement Teil 8: Einführung in die Kryptographie IT-Sicherheitsmanagement Teil 8: Einführung in die Kryptographie 28.04.15 1 Literatur I mit ein paar Kommentaren [8-1] Burnett, Steve; Paine, Spephen: Kryptographie. RSA Security s Official Guide. RSA

Mehr

Die Idee des Jahres 2013: Kommunikation verschlüsseln

Die Idee des Jahres 2013: Kommunikation verschlüsseln Die Idee des Jahres 2013: Kommunikation verschlüsseln Kommunikationsschema bei Email MailServer MailServer Internet PC PC Sender Empfänger Verschlüsselung ist... immer eine Vereinbarung zwischen zwei Kommunikationspartnern:

Mehr

Andreas Dittrich dittrich@informatik.hu-berlin.de. 10. Januar 2006

Andreas Dittrich dittrich@informatik.hu-berlin.de. 10. Januar 2006 mit (2) mit (2) 2 (802.11i) Andreas Dittrich dittrich@informatik.hu-berlin.de Institut für Informatik Humboldt-Universität zu Berlin 10. Januar 2006 (1/27) 2006-01-10 mit (2) 2 (802.11i) 2 (802.11i) (2/27)

Mehr

IT-Sicherheit - Sicherheit vernetzter Systeme -

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

Mehr

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells.

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. Übung 7 1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. 2.) Charakterisieren Sie kurz das User Datagram Protokoll (UDP) aus der Internetprotokollfamilie

Mehr

Rechnernetze II SS 2015. Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404

Rechnernetze II SS 2015. Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Rechnernetze II SS 2015 Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 14. Juli 2015 Betriebssysteme / verteilte Systeme Rechnernetze

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

Authentikation und digitale Signatur

Authentikation und digitale Signatur TU Graz 23. Jänner 2009 Überblick: Begriffe Authentikation Digitale Signatur Überblick: Begriffe Authentikation Digitale Signatur Überblick: Begriffe Authentikation Digitale Signatur Begriffe Alice und

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

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Dr. Marc Rennhard Institut für angewandte Informationstechnologie Zürcher Hochschule Winterthur marc.rennhard@zhwin.ch Angriffspunkt

Mehr

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen FAEL-Seminar Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte

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

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr