SSL/TLS. Sichere Kommunikation im Netzwerk


Hausarbeit, 2017

28 Seiten, Note: 1,0


Leseprobe

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Zielsetzung und Vorgehensweise

2 HTTP
2.1 Basic Authentication
2.2 Digest Access Authentication

3 Secure Socket Layer und Transport Layer Security
3.1 Protokollstruktur
3.2 ChangeCipherSpec Protocol
3.3 Record Protocol
3.4 Alert Protocol
3.5 Handshake Protocol
3.5.1 ClientHello
3.5.2 ServerHello
3.5.3 ServerCertificate
3.5.4 ServerKeyExchange
3.5.5 CertificateRequest
3.5.6 ServerHelloDone
3.5.7 ClientCertificate
3.5.8 ClientKeyExchange
3.5.9 ClientCertificateVerify
3.5.10 ChangeCipherSpec
3.5.11 Finished

4 Sicherheitsprobleme
4.1 BEAST
4.2 Triple Handshake Angriff

5 Zusammenfassung und Fazit

6 Ausblick

Literatur- und Internetverzeichnis

Abkürzungsverzeichnis

Abbildung in dieer Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Aufbau des TLS Protokolls

Abbildung 2: Überblick TLS Handshake

Abbildung 3: Phase 1 - Vertrauliche Verbindungsparameter abgreifen

Abbildung 4: Phase 2 - Wiederaufnahme der Verbindung

1 Einleitung

1.1 Problemstellung

Im Zeitalter des Internets gehen täglich reichlich sicherheitsrelevante Informationen über die elektrischen Leitungen. Das World Wide Web (WWW) ist hierbei eine der wichtigs- ten Informationsquellen der Menschen auf der Erde. Aufgrund des zunehmenden An- stiegs von Webseiten im Internet, die Dienste für Online Banktransaktionen und Aus- tausch von sensiblen Daten bereitstellen, wurde nach einer Lösung gesucht, die Kommu- nikation abzusichern.1 Gleichzeitig nimmt auch die Anzahl der Angriffe zu, die es sich zum Ziel gesetzt haben, sicherheitsrelevante Informationen abzugreifen. Diese Art von Kommunikation beruht im Wesentlichen auf dem Hypertext Transfer Protocol (HTTP). Dieses alleine stellt jedoch keine ausreichende Möglichkeit bereit, die zu übertragenden Daten vollständig zu sichern. Deshalb wurde nach einem anderen Ansatz gesucht. Das Resultat ist Secure Socket Layer (SSL) oder auch Transport Layer Security (TLS).2

1.2 Zielsetzung und Vorgehensweise

Im Rahmen dieser wissenschaftlichen Arbeit soll dem Leser die Bedeutung der sicheren Kommunikation im Internet erläutert werden, welche sich auf der Basis HTTP, dem SSL/TLS-Protokoll und den Sicherheitsproblemen stützt. Insgesamt ist diese Arbeit in sechs Hauptkapitel untergliedert. In Kapitel 2 erfolgt die Erläuterung zu den Grundlagen in HTTP und deren Authentifizierungsversuche. In Folge dessen wird auf die TLS Proto- koll Struktur und im ganz speziellen ausführlich auf den Handshake in Kapitel 3 einge- gangen. Die Sicherheitsprobleme bzw. Angriffe auf das Protokoll werden in Kapitel 4 im Detail erklärt. Eine Zusammenfassung und Fazit erfolgt in Kapitel 5. Im letzten Kapitel 6 wird ein Ausblick in die Zukunft gegeben.

2 HTTP

Das WWW besteht zum einen aus der Hypertext Markup Language (HTML), mit der man die Struktur von Dokumenten, unabhängig von Anwendungen, beschreiben kann.3

Zum anderen aus HTTP, welches das Standardprotokoll zum Abrufen von Web Doku- menten ist. HTTP kommuniziert standardmäßig über den Port 80.4 Die Kommunikation findet zwischen einem Web-Client und Webserver über einen Socket statt. Ein Socket ist die Kombination aus IP-Adresse und Portnummer, die einen Dienst eindeutig im WWW identifiziert.5 Es ist ein sehr einfaches Protokoll, da nur ein GET Befehl abgesetzt werden muss, dem als Parameter mitgegeben wird, was genau man haben möchte. Entweder der Befehl ist erfolgreich und das angefragte Dokument wird vom Server zurückgegeben oder der Client erhält einen Fehler.6

In HTTP werden alle Informationen im Klartext übertragen d. h. jeder kann die Informa- tionen mitlesen und auch jeder kann jeglichen Uniform Resource Locator (URL) abfragen ohne sich dabei authentifizieren zu müssen. Um das zweite Problem der Authentifizie- rung zu lösen wurden zwei Methoden für HTTP entwickelt und implementiert. Diese zwei Methoden werden im Folgenden näher betrachtet.7

2.1 Basic Authentication

Als aller erstes wurde die Basic Authentication Methode spezifiziert und in HTTP imple- mentiert. Sie soll vor unautorisiertem Zugriff schützen, jedoch wird hier der Aspekt von Benutzername und Passwort im Klartext nicht betrachtet. Demzufolge sollte diese Me- thode nur genutzt werden, wenn man ein geschlossenes Netz hat und dem Netzbetreiber vertraut. Sie ist die häufigste Art der HTTP-Authentifizierung.8

Der Ablauf ist wie folgt. Zuerst stellt der Client dem Server eine Anfrage an eine be- stimmte URL mit dem HTTP-Kommando GET. Zu diesem Zeitpunkt ist noch nicht klar das die angeforderte HTML-Seite zugriffsgeschützt ist. Der Server prüft nun die Anfrage und stellt fest, dass eine Authentifizierung nötig ist. Er antwortet deshalb mit dem HTTP- Statuscode 401. Dieser Statuscode steht für Authorization Required.9 Zudem hat der Server in seinem Antwortpaket den Header z. B. auf folgendes geändert:

WWW-Authenticate: Basic realm="Zugriffsgeschützt! Bitte geben Sie das Passwort für den Bereich XY ein!"10

Auf diese Weise wird dem Client mitgeteilt, welche Art von Authentisierung erforderlich ist. Mit dem zusätzlichen Parameter realm wird eine Beschreibung des geschützten Be- reiches dargestellt. Der Browser sucht daraufhin nach einem Benutzernamen und Pass- wort für die aufgerufene URL oder fordert bei Bedarf den Benutzer auf diese über ein zusätzlich eingeblendetes Fenster einzugeben. Nach der Eingabe codiert der Browser beide Werte in folgender Form durch eine Base64-Codierung und schreibt sie in den Hea- der der HTTP-Anfrage an den Server.11

Benutzername:Passwort

Der Parameter im Header wird z. B. wie folgt dargestellt: Authorization: Basic SnVsaWFuOlNwcmluZ2Vy12

Base64 codiert mit Prüfsummenbildung, damit Übertragungsfehler identifiziert werden können. Es schützt jedoch nicht vor Manipulation der Codierung, da der Algorithmus veröffentlicht wurde und somit jeder Angreifer den Benutzernamen und das Passwort codieren und dekodieren kann. Deshalb kann auch eine gültige Prüfsumme erneut errech- net werden. Base64 bietet daher keinen kryptographischen Schutz, weshalb die Basic Au- thentication nur bei Benutzung von HTTPS als sicher eingestuft werden kann.13

Sobald der Server die Zugangsdaten verifiziert hat, wird die gewünschte HTML-Seite an den Client übertragen. Bei jeder weiteren Anfrage des Clients an den Server, sendet dieser immer den Benutzernamen und das Passwort im HTTP-Header mit.14

2.2 Digest Access Authentication

Die Digest Access Authentication wurde nach der Basic Authentication eingeführt, da man mit ihr die offensichtlichen Sicherheitsmängel des Klartext Passworts beseitigen wollte. Zu Beginn wird, wie auch schon bei der Basic Authentication, die Anfrage an den Server geschickt. Dieser antwortet mit dem Statuscode 401. Zusätzlich werden weitere Header-Attribute wie folgt mitgesendet.15

WWW-Authenticate:Digestrealm="MeinTestRealm@host.com", nonce="aba84bc65aff2f0e8b11d0f00589ff3021", opaque="cd9065aff2f0eaf9f2aa2e95cc9c0ab0"

In Zeile 1 wird nun die Authentifizierungsmethode Digest anstatt Basic angegeben und die Variable realm soll dem Client darstellen für welche Seite er sich authentisieren soll. Die zweite Zeile hat eine weitere Variable nonce, die vom Server bei jedem neuen 401 neu berechnet wird und vom Client als Antwort darauf wiederverwendet werden muss. Die dritte Zeile mit der Variable opaque stellt den Challenge Wert dar, da es sich bei Digest um eine klassische Challenge-Response-Authentisierung handelt.16 Er wird auch vom Server generiert und bei jeder Übertragung, welche denselben Authentisierungs- Raum adressiert, von Client als auch von Server übermittelt. Sowohl der Wert nonce als auch opaque sind Zufallswerte in Base64- oder Hexadezimal-Codierung.17

Der Client muss dem Server nun eine Antwort schicken. Diese beinhaltet den Benutzernamen, gewünschte HTML-Seite und den Response-Wert, welcher implizit das Passwort zum angegebenen Benutzer beinhaltet. Der Response-Wert wird mit einer mathematischen Einwegfunktion wie z. B. MD5 (Message-Digest Algorithm 5) oder SHA (Secure Hash Algorithm) berechnet. Dadurch kann ein möglicher Angreifer das Passwort durch Abhören der Leitung nicht ermitteln.18

Nachdem das Paket an den Sender übermittelt worden ist, wird er aus dem zuvor schon gehashten Benutzernamen mit Passwort und realm-Wert aus der Passwortdatei, dem übermittelten nonce-Wert, sowie der gewünschten Seite einen Hash errechnen. Dieser Hash wird dann mit dem übermittelten response-Wert verglichen. Falls diese übereinstimmen, erhält der Client die gewünscht HTML-Seite.19

Das Passwort bleibt geheim, jedoch wird die HTML-Seite weiterhin unverschlüsselt übertragen, weshalb ein Angreifer diese trotzdem aufzeichnen kann. Aufgrund dieser Tatsache wird diese Art von Authentisierung nicht sehr häufig verwendet. Stattdessen verwendet man die Basic Authentication für sicherheitsunkritische Anwendungen während für sicherheitskritische Anwendungen eine Verschlüsselung wie z. B. SSL/TLS verwendet wird, die den kompletten Datenverkehr sicher macht.20

3 Secure Socket Layer und Transport Layer Security

SSL ist ein Protokoll zur sicheren Kommunikation in Netzwerken. Das Ziel von SSL ist es die Privatsphäre und Zuverlässigkeit zwischen zwei Kommunikationspartner sicher- zustellen.21 Die kryptographische Sicherheit spielt die Hauptrolle, um eine sichere Ver- bindung zwischen zwei Parteien herzustellen, die sicher miteinander kommunizieren möchten. Daher wurde das Protokoll so entwickelt, dass Schnittstellen zu anderen her- kömmlichen kryptographischen Standards hergestellt werden können. TLS ist daher ein Framework, welches stetig durch neue Verschlüsselungsalgorithmen und Hash-Funktio- nen erweitert werden kann. Nicht zuletzt dürfen die genannten Ziele die Performance nicht maßgeblich beeinflussen und somit muss die Dauer der kryptographischen Berech- nungen auf ein Minimum reduziert werden.22

Die letzte SSL Version ist 3.0. SSL wurde ursprünglich von Netscape entwickelt und im Jahr 1999 veröffentlicht. Die Organisation IETF (Internet Engineering Task Force), die für Standardisierungen von Protokollen zuständig sind, hat dies auch bei SSL getan. Daraus entstand dann deren eigene Version, die heutzutage TLS genannt wird. TLS ist aktueller Standard. Es wird aber oft von SSL gesprochen auch wenn TLS gemeint ist, da diese Bezeichnung noch bekannter ist.23

3.1 Protokollstruktur

HTTP setzt sehr häufig TLS ein, um die Kommunikation zu sichern. Es kann aber auch jedes andere Anwendungsprotokoll mit TLS verschlüsselt werden, da TLS unabhängig von dem jeweiligen Anwendungsprotokoll ist.

In Anlehnung an das OSI Model befindet es sich zwischen Applikations- und Transport- schicht wie in Abbildung 1 dargestellt. Es ist in zwei Schichten aufgeteilt. Das erste ist das Record Protocol, welches direkt über der Transportschicht einzuordnen ist. Es ist ein zuverlässiges und verbindungsorientiertes Transportprotokoll, dessen Aufgabe es ist das darüberliegende Protokoll in Datenblöcke zu unterteilen, Daten bei Bedarf zu kompri- mieren, einen Message Authentication Code (MAC) hinzuzufügen und schlussendlich die Daten zu verschlüsseln.24 Die zweite Schicht besteht aus dem Handshake-, Change- CipherSpec- und Alert Protocol, die alle eine spezielle Aufgabe im Verlauf der Kommu- nikation haben. Die Anwendungsdaten sind dort ebenfalls einzuordnen.25

Abbildung 1: Aufbau des TLS Protokolls

Abbildung in dieer Leseprobe nicht enthalten

Quelle: Eigene Darstellung

Damit das TLS Record Protocol eine geschützte Verbindung aufbauen kann, benötigt man aber erstmal eine Reihe von Spezifikationen, wie der Cipher-Suite, einem Master Secret und generierte Zufallszahlen von Client und Server. Die Cipher-Suite ist eine Sammlung aus Algorithmen für Authentisierung, Verschlüsselung und einer Hashfunk- tion, die zwischen Client und Server ausgehandelt werden. Die Kompressionsalgorithmen und Zufallswerte von Client und Server werden in den sogenannten Hello-Nachrichten, die im Handshake Protocol vorkommen, ausgetauscht. Auf diese wird in Kapitel 3.5.1 und Kapitel 3.5.2 näher eingegangen. All diese Informationen sind notwendig um das Master Secret zu berechnen, welches maßgeblich für die Verschlüsselung ist.26

3.2 ChangeCipherSpec Protocol

Das ChangeCipherSpec Protocol wird benutzt, um eine Änderung der Verschlüsselung einzuleiten. Es wird normalerweise im Handshake Prozess verwendet, um von asymmet- rischer- auf symmetrische Verschlüsselung zu wechseln. Es ist ein eigenes Protokoll, da TLS-Nachrichten über Records, sprich einer TLS-Dateneinheit verschlüsselt werden. Es können mehrere Nachrichten vom selben Typ wie z. B. der Handshake-Nachrichten in einem Record zusammengefasst werden.27 Die ChangeCipherSpec-Nachricht verändert aber die Verschlüsselungseinstellungen und auf ein Record darf nur ein Satz von krypto- graphischen Algorithmen angewandt werden, weshalb es unerwünscht ist und als eigen- ständiges Record gesendet werden muss.28 Es wurde daher ein eigenes Protokoll definiert, da Records verschiedener Protokolle nicht zusammengefasst werden dürfen.29 Demzu- folge sollte sofort nach Einleitung einer ChangeCiperSpec-Nachricht ein neues Record beginnen, damit die neuen Einstellungen direkt auf die darauffolgenden Records umge- setzt werden. Im Sinne der Sicherheit ist es teilweise sogar sehr wichtig, dass schon die Finished-Nachricht die neue Verschlüsselung und MAC verwendet.30

Das Protokoll besteht aus einer einzigen Nachricht, welche ein Byte mit dem Wert 1 beinhaltet. Die ChangeCipherSpec-Nachricht wird von Client als auch von Server gesendet um den jeweiligen Empfänger über die neu verhandelten Algorithmen zu benachrichtigen und dessen Record Protocol zu instruieren, dass ab sofort nur noch mit den neuen Algorithmen verschlüsselt wird.31

[...]


1 Vgl. Ristić, I. (2015), S. 1.

2 Vgl. Dacosta, I., Ahamad, M., Traynor, P. (2012), S. 202.

3 Vgl. Schwenk, J. (2014), S. 147-148.

4 Vgl. Davies, J. (2011), S. 38-39.

5 Vgl. Schwenk, J. (2014), S. 148.

6 Vgl. Davies, J. (2011), S. 38-39.

7 Vgl. Javvin Technologies (2005), S. 20.

8 Vgl. McClure, S., Shah, S. (2003), S. 253-254.

9 Vgl. Gourley, D., et al. (2002), S. 281-282.

10 Vgl. Oppliger, R. (2003), S. 29.

11 Vgl. Leach, et al. (1999): HTTP Authentication: Basic and Digest Access Authentication, S. 4-5.

12 Vgl. Oppliger, R. (2003), S. 31.

13 Vgl. Alpar, P., et al. (2013), S. 156-157.

14 Vgl. Oppliger, R. (2003), S. 33-34.

15 Vgl. Gourley, D., et al. (2002), S. 286-287.

16 Vgl. Leach, et al. (1999): HTTP Authentication: Basic and Digest Access Authentication, S. 7-8.

17 Vgl. Sorge, C., Iacono, L., Gruschka, N. (2013), S. 212-213.

18 Vgl. van Tilborg, H., Jajodia, S. (2014), S. 565-566.

19 Vgl. Kriha, W., Schmitz, R. (2008), S. 128.

20 Vgl. Schmeh, K. (2006), S. 352-353.

21 Vgl. McKinley, H. (2003), S. 3.

22 Vgl. Ristić, I. (2015), S. 1-2.

23 Vgl. Vandeven, S. (2013): SSL/TLS: What's Under the Hood, S. 4.

24 Vgl. Vandeven, S. (2013): SSL/TLS: What's Under the Hood, S. 8-9.

25 Vgl. Thomas, S. (2000), S. 70-71.

26 Vgl. Dierks, T., Rescorla, E. (2008): The Transport Layer Security (TLS) Protocol Version 1.2, S. 63.

27 Vgl. Kriha, W., Schmitz, R. (2008), S. 141-142.

28 Vgl. Schwenk, J. (2010), S. 98.

29 Vgl. Oppliger, R. (2016), S. 70-71.

30 Vgl. Rhee, M. (2003), S. 289-290.

31 Vgl. Miller, M. (2010), S. 837.

Ende der Leseprobe aus 28 Seiten

Details

Titel
SSL/TLS. Sichere Kommunikation im Netzwerk
Hochschule
FOM Hochschule für Oekonomie & Management gemeinnützige GmbH, Stuttgart
Note
1,0
Autor
Jahr
2017
Seiten
28
Katalognummer
V449752
ISBN (eBook)
9783668845893
ISBN (Buch)
9783668845909
Sprache
Deutsch
Schlagworte
ssl/tls, sichere, kommunikation, netzwerk
Arbeit zitieren
Julian Springer (Autor), 2017, SSL/TLS. Sichere Kommunikation im Netzwerk, München, GRIN Verlag, https://www.grin.com/document/449752

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: SSL/TLS. Sichere Kommunikation im Netzwerk



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden