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

SSL/TLS. Präsentation zur Seminararbeit. im Seminar Internetsicherheit. Michael Hübschmann 26. Juni 2014 Betreuung: Dipl. Inf.

SSL/TLS. Präsentation zur Seminararbeit. im Seminar Internetsicherheit. Michael Hübschmann 26. Juni 2014 Betreuung: Dipl. Inf. SSL/TLS Präsentation zur Seminararbeit im Seminar Internetsicherheit Michael Hübschmann 26. Juni 2014 Betreuung: Dipl. Inf. Kuzman Katkalov Überblick 1. Motivation 2. Von SSL zu TLS, die Geschichte der

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

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

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

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

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

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

SSL Secure Socket Layer Algorithmen und Anwendung

SSL Secure Socket Layer Algorithmen und Anwendung SSL Secure Socket Layer Algorithmen und Anwendung Präsentation vom 03.06.2002 Stefan Pfab 2002 Stefan Pfab 1 Überblick Motivation SSL-Architektur Verbindungsaufbau Zertifikate, Certification Authorities

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

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

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

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

IT-Sicherheit SSL/TLS. Jens Kubieziel. Fakultät für Mathematik und Informatik. 6. Januar 2012

IT-Sicherheit SSL/TLS. Jens Kubieziel. Fakultät für Mathematik und Informatik. 6. Januar 2012 IT-Sicherheit SSL/TLS Jens Kubieziel Fakultät für Mathematik und Informatik 6. Januar 2012 Jens Kubieziel (FSU Jena) IT-Sicherheit 6. Januar 2012 1 / 14 Überblick Secure Sockets Layer (SSL) bzw. Transport

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

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

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

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

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

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

Sicherheit in Netzwerken. Leonard Claus, WS 2012 / 2013

Sicherheit in Netzwerken. Leonard Claus, WS 2012 / 2013 Sicherheit in Netzwerken Leonard Claus, WS 2012 / 2013 Inhalt 1 Definition eines Sicherheitsbegriffs 2 Einführung in die Kryptografie 3 Netzwerksicherheit 3.1 E-Mail-Sicherheit 3.2 Sicherheit im Web 4

Mehr

Sicherheit in Netzen Modul 6: TLS Transport Layer Security

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

Mehr

TLS. Transport Layer Security TLS

TLS. Transport Layer Security TLS Transport Layer Security Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN 978-3824540662 http://www.weka.at/bestellen/ protokolle-und-dienste-derinformationstechnologie

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

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

Sicherheit in Netzen Modul 7: TLS Transport Layer Security

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

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

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

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

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

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

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

Reale Nutzung kryptographischer Verfahren in TLS/SSL

Reale Nutzung kryptographischer Verfahren in TLS/SSL Reale Nutzung kryptographischer Verfahren in TLS/SSL CeBIT 2009/03/06 Dominique Petersen petersen (at) internet-sicherheit.de Institut für Internet-Sicherheit https://www.internet-sicherheit.de Fachhochschule

Mehr

IT-Sicherheit Kapitel 13. Email Sicherheit

IT-Sicherheit Kapitel 13. Email Sicherheit IT-Sicherheit Kapitel 13 Email Sicherheit Dr. Christian Rathgeb Sommersemester 2013 IT-Sicherheit Kapitel 13 Email-Sicherheit 1 Einführung Internet Mail: Der bekannteste Standard zum Übertragen von Emails

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

Erste Vorlesung Kryptographie

Erste Vorlesung Kryptographie Erste Vorlesung Kryptographie Andre Chatzistamatiou October 14, 2013 Anwendungen der Kryptographie: geheime Datenübertragung Authentifizierung (für uns = Authentisierung) Daten Authentifizierung/Integritätsprüfung

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

Informatik für Ökonomen II HS 09

Informatik für Ökonomen II HS 09 Informatik für Ökonomen II HS 09 Übung 5 Ausgabe: 03. Dezember 2009 Abgabe: 10. Dezember 2009 Die Lösungen zu den Aufgabe sind direkt auf das Blatt zu schreiben. Bitte verwenden Sie keinen Bleistift und

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

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

Public Key Infrastruktur. Georg Gruber & Georg Refenner 26.Jänner 2009 ITTK 09

Public Key Infrastruktur. Georg Gruber & Georg Refenner 26.Jänner 2009 ITTK 09 Public Key Infrastruktur Georg Gruber & Georg Refenner 26.Jänner 2009 ITTK 09 Grundlagen Symmetrische Verschlüsselung Asymmetrische Verschlüsselung Hybridverschlüsselung Hashverfahren/Digitale Signaturen

Mehr

Symmetrische und Asymmetrische Kryptographie. Technik Seminar 2012

Symmetrische und Asymmetrische Kryptographie. Technik Seminar 2012 Symmetrische und Asymmetrische Kryptographie Technik Seminar 2012 Inhalt Symmetrische Kryptographie Transpositionchiffre Substitutionchiffre Aktuelle Verfahren zur Verschlüsselung Hash-Funktionen Message

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

Sicheres HTTP. 8. Juni 2004. Proseminar Electronic Commerce und digitale Unterschriften

Sicheres HTTP. 8. Juni 2004. Proseminar Electronic Commerce und digitale Unterschriften Sicheres HTTP 8. Juni 2004 Proseminar Electronic Commerce und digitale Unterschriften Sicheres HTTP HTTP über SSL = sicheres HTTP Überblick HTTP: Protokoll zur Datenübertragung im Internet Klartextprotokoll

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

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

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

Übungen zur Vorlesung Systemsicherheit

Übungen zur Vorlesung Systemsicherheit Übungen zur Vorlesung Systemsicherheit Symmetrische Kryptographie Tilo Müller, Reinhard Tartler, Michael Gernoth Lehrstuhl Informatik 1 + 4 17. November 2010 c (Lehrstuhl Informatik 1 + 4) Übungen zur

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

Vorlesung Sicherheit

Vorlesung Sicherheit Vorlesung Sicherheit Dennis Hofheinz IKS, KIT 10.06.2013 1 / 26 Überblick 1 Schlüsselaustauschprotokolle Transport Layer Security (TLS) Weitere Schlüsselaustauschtypen Zusammenfassung 2 Identifikationsprotokolle

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

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

Bernd Blümel. Verschlüsselung. Prof. Dr. Blümel

Bernd Blümel. Verschlüsselung. Prof. Dr. Blümel Bernd Blümel 2001 Verschlüsselung Gliederung 1. Symetrische Verschlüsselung 2. Asymetrische Verschlüsselung 3. Hybride Verfahren 4. SSL 5. pgp Verschlüsselung 111101111100001110000111000011 1100110 111101111100001110000111000011

Mehr

Literatur. [3-5] Klaus Schmeh: Kryptografie. dpunkt, 3. Auflage, 2007. [3-6] Bruce Schneier: Secrets & Lies. dpunkt, 2001

Literatur. [3-5] Klaus Schmeh: Kryptografie. dpunkt, 3. Auflage, 2007. [3-6] Bruce Schneier: Secrets & Lies. dpunkt, 2001 Literatur [3-1] Gourley, David; Totty, Brian: HTTP. The definitive Guide. O'Reilly, 2002 [3-2] Badach, Anatol; Rieger, Sebastian; Schmauch, Matthias: Web- Technologien. Hanser, 2003 [3-3] Upgrading to

Mehr

Netzsicherheit I, WS 2008/2009 Übung 12. Prof. Dr. Jörg Schwenk 20.01.2009

Netzsicherheit I, WS 2008/2009 Übung 12. Prof. Dr. Jörg Schwenk 20.01.2009 Netzsicherheit I, WS 2008/2009 Übung 12 Prof. Dr. Jörg Schwenk 20.01.2009 Aufgabe 1 1 Zertifikate im Allgemeinen a) Was versteht man unter folgenden Begriffen? i. X.509 X.509 ist ein Standard (Zertifikatsstandard)

Mehr

Wiederholung: Informationssicherheit Ziele

Wiederholung: Informationssicherheit Ziele Wiederholung: Informationssicherheit Ziele Vertraulichkeit : Schutz der Information vor unberechtigtem Zugriff bei Speicherung, Verarbeitung und Übertragung Methode: Verschüsselung symmetrische Verfahren

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

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

Webtechnologien Teil 3: Sicheres HTTP

Webtechnologien Teil 3: Sicheres HTTP Webtechnologien Teil 3: Sicheres HTTP 23.03.15 1 Literatur [3-1] Gourley, David; Totty, Brian: HTTP. The definitive Guide. O'Reilly, 2002 [3-2] Badach, Anatol; Rieger, Sebastian; Schmauch, Matthias: Web-

Mehr

Mindeststandard des BSI für den Einsatz des SSL/TLS-Protokolls durch Bundesbehörden. nach 8 Abs. 1 Satz 1 BSIG

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

Mehr

Verschlüsselte E-Mails: Wie sicher ist sicher?

Verschlüsselte E-Mails: Wie sicher ist sicher? Verschlüsselte E-Mails: Wie sicher ist sicher? Mein Name ist Jörg Reinhardt Linux-Administrator und Support-Mitarbeiter bei der JPBerlin JPBerlin ist ein alteingesessener Provider mit zwei Dutzend Mitarbeitern

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

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

IT Sicherheit: Authentisierung

IT Sicherheit: Authentisierung Dr. Christian Rathgeb IT-Sicherheit, Kapitel 4 / 18.11.2015 1/21 IT Sicherheit: Dr. Christian Rathgeb Hochschule Darmstadt, CASED, da/sec Security Group 18.11.2015 Dr. Christian Rathgeb IT-Sicherheit,

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

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

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

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

Kryptographische Verfahren: Empfehlungen und Schlüssellängen

Kryptographische Verfahren: Empfehlungen und Schlüssellängen Technische Richtlinie TR-02102-2 Kryptographische Verfahren: Empfehlungen und Schlüssellängen Teil 2 Verwendung von Transport Layer Security (TLS) (Version 2015-01) Bundesamt für Sicherheit in der Informationstechnik

Mehr

Schlüssel und Zertifikate

Schlüssel und Zertifikate Schlüssel und Zertifikate Bei der asymmetrischen Verschlüsselung wird ein Schlüsselpaar bestehend aus einem öffentlichen und einem privaten Schlüssel verwendet. Daten, die mit dem privaten Schlüssel verschlüsselt

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

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

Einleitung Verfahren Programme Schlüsselverwaltung Passwörter Ende. GPG-Einführung. Martin Schütte. 13. April 2008

Einleitung Verfahren Programme Schlüsselverwaltung Passwörter Ende. GPG-Einführung. Martin Schütte. 13. April 2008 GPG-Einführung Martin Schütte 13. April 2008 Einleitung Verfahren Programme Schlüsselverwaltung Passwörter Ende Warum Kryptographie? Vertraulichkeit Mail nur für Empfänger lesbar. Integrität Keine Veränderung

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

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

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

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

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

E-Mail-Verschlüsselung

E-Mail-Verschlüsselung E-Mail-Verschlüsselung In der Böllhoff Gruppe Informationen für unsere Geschäftspartner Inhaltsverzeichnis 1 E-Mail-Verschlüsselung generell... 1 1.1 S/MIME... 1 1.2 PGP... 1 2 Korrespondenz mit Böllhoff...

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

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

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

Handshake von SIM und GSM Basisstation

Handshake von SIM und GSM Basisstation Handshake von SIM und GSM Basisstation Prüfungsvorleistung im Rahmen der Vorlesung Chipkarten SS 05 Inhalt GSM und Sicherheit Sicherheitsdienste GSM Algo Authentifizierung PDU (herausgenommen) GSM und

Mehr

The Second Generation Onion Router. Stefan Hasenauer, Christof Kauba, Stefan Mayer

The Second Generation Onion Router. Stefan Hasenauer, Christof Kauba, Stefan Mayer The Second Generation Onion Router Übersicht Einleitung Verfahren zur Anonymisierung Allgemeines über Tor Funktionsweise von Tor Hidden Services Mögliche Angriffe 2 Einleitung Identifizierung im Internet

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

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

Systemsicherheit 11 SSL/TLS

Systemsicherheit 11 SSL/TLS Systemsicherheit 11 SSL/TLS Das TCP/IP-Schichtenmodell Anwendungsschicht (FTP, HTTP, SMTP,...) Transportschicht (TCP, UDP) s-http https Internetschicht (IP) Netzwerkschicht (z.b. Ethernet, TokenRing,...)

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

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

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

Diffie-Hellman, ElGamal und DSS. Vortrag von David Gümbel am 28.05.2002

Diffie-Hellman, ElGamal und DSS. Vortrag von David Gümbel am 28.05.2002 Diffie-Hellman, ElGamal und DSS Vortrag von David Gümbel am 28.05.2002 Übersicht Prinzipielle Probleme der sicheren Nachrichtenübermittlung 'Diskreter Logarithmus'-Problem Diffie-Hellman ElGamal DSS /

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

Ü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

Vorlesung Sicherheit

Vorlesung Sicherheit Vorlesung Sicherheit Dennis Hofheinz IKS, KIT 03.06.2013 1 / 34 Überblick 1 Schlüsselaustauschprotokolle Motivation Symmetrische Verfahren Asymmetrische Verfahren Transport Layer Security (TLS) 2 / 34

Mehr

Transport Layer Security Nachtrag Angriffe

Transport Layer Security Nachtrag Angriffe Transport Layer Security Nachtrag Angriffe TLS Replay Attack TLS Replay Angriff Annahme Server sendet keine Nonce, oder immer gleiche Client generiert Pre-Master Secret, Schlüsselmaterial über KDF (deterministisch!)

Mehr

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird.

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Auch die Unternehmensgruppe ALDI Nord steht mit einer Vielzahl

Mehr