• Save
Transportsicherheit - SSL und HTTPS
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Transportsicherheit - SSL und HTTPS

  • 589 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
589
On Slideshare
518
From Embeds
71
Number of Embeds
3

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 71

http://markusgross.de 45
http://www.markusgross.de 24
http://127.0.0.1 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Transportsicherheit – SSL und HTTPSMarkus Groß
  • 2. AGENDA2Inhaltsverzeichnis
  • 3.  Wie lässt sich die Vertrauenswürdigkeit derGegenstelle gewährleisten? Woher weiss man genau, durch welche Rechner dieTCP-Pakete gehen? Sicherheitsrisiko z.B. beim online Banking,eCommerce und „Unterschrift“ von Verträgen1 MOTIVATION3Wozu Transportsicherheit?
  • 4.  Transposition Bei einem Transpositions-Algorithmus bleiben die Buchstabenwas sie sind, aber nicht wo sie sind Substitution Bei der Substitution werden die einzelnen Klartextbuchstabendurch bestimmte Geheimtextbuchstaben ersetztVerfahren und Methoden2 EXKURSVERSCHLÜSSELUNG4Grundlagen VerschlüsselungKlartext: a b c d e f g h i j k l m n o p q r s t u v w x y zGeheimtext: Q W E R T Y U I O P A S D F G H J K L Z X C V B N MKlartext: H A L L O L E U T E W I E G E H T E S E U C HGeheimtext: H A L L OL E U T EW I E G EH T E S EU C H
  • 5.  Gleicher Schlüssel zum Ver- und Entschlüsseln derDaten bzw. Datei Problem: Schlüsselübergabe Unsicher (per E-Mail oder andere elektronische Medien) Unpraktisch (per Telefon o.ä.) Wegen Notwendigkeit der Übergabe: Schlüssellänge nichtausreichend komplex2 EXKURSVERSCHLÜSSELUNG5Symmetrische Verfahren
  • 6.  Caesar Chiffre - Substitution Verschiebung der Buchstaben um X Buchtaben Leicht zu erraten, maximal 26 Schlüssel Griechische Skytral –Transposition Klartext wird um eine Rolle gewickelt Komplexere Verfahren (Polyalphabetisch) Vigenère Verschlüsselung Playfair Chiper Mechanische Verfahren Rotor Maschine Enigma2 EXKURSVERSCHLÜSSELUNG6Klassische symmetrische Verschlüsselung
  • 7. Data Encryption Standard (DES)7Moderne symmetrische Verschlüsselung Von IBM entwickelt und 1974 in denUSA standardisiert Wichtigste Bestandteile sind: Permutation XOR (logische Verknüpfung zweierbinärer Werte) Substitution DES ist ein Blockchiffre Klartext wird in 64 Bit Blöcke eingeteilt Durch Registeroperation sehr„hardwarenah“ und schnell2 EXKURSVERSCHLÜSSELUNG
  • 8.  Ein Schlüssel zum Verschlüsseln der Datei, PublicKey, nicht geheim, auf Schlüsselservern verfügbar Ein Schlüssel zum Entschlüsseln, Private Key,geschützt, bleibt beim Adressaten der Datei→ Problem der unsicheren/unkomfortablenSchlüsselübergabe gelöst2 EXKURSVERSCHLÜSSELUNG8Asymmetrische Verfahren (Public Key-Prinzip)Der geheime Schlüsselentschlüsselt NachrichtenDer öffentliche Schlüsselverschlüsselt Nachrichten
  • 9. RSA Verfahren9Ronal Rivest, Adi Shamir und Leonard Adleman Schlüsselerzeugung→Wahl von zwei große Primzahlen p und q(> 512 Bit)→Bilde n = p * q→Bestimme mit Hilfe des euklidischenAlgorithmus d und e→ n und e bilden den öffentlichen Schlüssel→ d den privaten Schlüssel Chiffrierung Geheimtext = Klartexte mod n Dechiffrierung Klartext = Geheimtextd mod n2 EXKURSVERSCHLÜSSELUNG
  • 10. Sicherheit Asymmetrische Verschlüsselung10 Solange sicher bis es keineneffizienten Algorithmus zurPrimfaktorzerlegung großer Zahlengibt Laufzeitberechnung nach Schorn: Bei >100 stelligen Primzahlen benötigtein „handelsüblicher“ PC über 74Jahre2 EXKURSVERSCHLÜSSELUNG
  • 11. Hybride Verschlüsselung11 Kombination beider Verfahren Problem symmetrische Verfahren→Schlüssel Übermittlung Problem asymmetrischen Verfahren→Hardware unfreundlich Übertragung des Schlüssels perasymmetrischer Verschlüsselung Übertragung der Nachricht persymmetrischen Verschlüsselung→Grundlage von SSL2 EXKURSVERSCHLÜSSELUNG
  • 12.  MD5 wurde 1994 von Ronald L. Rivest am MITentwickelt Einweg-Algorithmus um aus einer beliebig langenZeichenkette eine eindeutige Checksumme mitfester Länge zu berechnen (128 Bit) Auffüllen der Nachricht bis die Länge in Bit ein Vielfaches von512 Bit beträgt Eingabewert wird in 512 Bit Blöcke geteilt - ABCD … http://www.hashgenerator.de/MD5 (Message-Digest Algorithm 5) - RFC13212 EXKURSVERSCHLÜSSELUNG12Hashingmd5("Transportsicherheit - SSL, TLS https") =552697af6c392a8b1b0934587695242ecef8ede6
  • 13. 1. Nutzer tippt http://www.fhdw.de ein2. Browser sucht auf einem Domain Name Server(DNS) die IP-Adresse zu www.fhdw.de3. Browser baut eine TCP-Verbindung zu193.426.15.50 und Port 80 auf4. Browser sendet ein HTTP-Kommando über TCP an193.426.15.50 /Port 80:Wie arbeitet ein Webbrowser?3 GRUNDLAGEN13HTTPGet start.htm HTTP/1.0User-agent: Netscape 4.7Accept: text/plainAccept: text/htmlAccept: image/gif
  • 14. 5. Server antwortet über die TCP-Verbindung mit: Einer Statuszeile (Erfolgsmeldung oder Fehler), Metainfomation (Beschreibung der nachfolgendenInformation), Einer Leerzeile und Der Information selbst:Wie arbeitet ein Webbrowser?3 GRUNDLAGEN14HTTPHTTP/1.0 Status 200 Document followsServer: Apache/1.8Date: Mon, 14 Mai, 2001 11:23:22 GMTContent-type: text/htmlContent-length: 5280Last-modified: Fri, 11 Mai, 2001 03:12:12 GMT<html> ...</html>
  • 15.  Schritt 1 - 5 wird für jede HTTP(1.0)-Anfragewiederholt Insbesondere muss für jede HTTP(1.0)-Anfrage eineneue TCP-Verbindung aufgebaut werden Moderne Browser „schummeln“ hier und bauenmehrere TCP-Verbindungen gleichzeitig auf, um dieverschiedenen Bestandteile einer Webseiteschneller zu ladenWie arbeitet ein Webbrowser?3 GRUNDLAGEN15HTTP
  • 16.  Einfaches Username/Passwort-Verfahren Pop-Up-Fenster im Browser erscheint Passwort ist NICHT verschlüsselt (BASE64-codiert)3 GRUNDLAGEN16HTTP Basic Authentication (RFC 2617)Quelle: Schwenk, Jörg (2005): Sicherheit und Kryptographie im Internet, 2.Auflage, ViewegGET /root/secret.html HTTP/1.0HOST: www.bank.deHTTP/1.0 401 Authorization RequiredWWW-Authenticate: Basic realm="name"GET /root/secret.html HTTP/1.0HOST:www.bank.deAuthorization: Basic QWRtaW46Zm9vYmFyHTTP/1.0 200 OKsecret.html
  • 17.  Erweiterung im HTTP 1.1 Standard User-ID und Passwort nicht mehr im Klartext3 GRUNDLAGEN17HTTP Digest Authentication (RFC 2617)Quelle: Schwenk, Jörg (2005): Sicherheit und Kryptographie im Internet, 2.Auflage, ViewegGET /root/secret.html HTTP/1.0HOST: www.bank.deHTTP/1.1 401 UnauthorizedWWW-Authenticate: Digestrealm=“mitarbeiter@bank.de",nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",opaque="5ccc069c403ebaf9f0171e9517f40e41Authorization: Digest username=“Hans.Mueller",realm="mitarbeiter@bank.de",nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",uri=“/root/secret.html",response="e966c932a9242554e42c8ee200cec7f6",opaque="5ccc069c403ebaf9f0171e9517f40e41HTTP/1.0 200 OKsecret.html
  • 18.  Authentizität Empfänger soll die Herkunft eindeutig ermittel können Verhindern, dass sich jemand Drittes alsKommunikationspartner ausgibt Integrität Sicherstellung der Echtheit der Daten Empfänger soll überprüfen können, ob die Nachricht bei derÜbermittlung verändert wurde Vertraulichkeit Es soll sichergestellt werden, dass nur derjenige die Nachrichtempfängt für den sie auch bestimmt ist3 GRUNDLAGEN18Anforderungen an sichere Kommunikation
  • 19.  SSL 1.0 (1993) Interne Entwicklung von Netscape SSL 2.0 (1994) Erste Veröffentlichung in Netscape Navigator Max. 40 Bit Schlüssellänge (US Export Vorschriften) SSL 3.0 (1995) Bugfixing und aktuelle Kryptotechnologie Aufhebung der Begrenzung der Schlüssellänge TLS (Transport Layer Security) Eigentlich Version 3.1 von SSL (auf SSL 3.0 basierend) Standardisiertes von der IETF entwickeltes SicherheitsprotokollSecure Socket Layer3 GRUNDLAGEN19Entwicklung von SSL
  • 20. Von 1994 bis heute3 GRUNDLAGEN20Die Meilensteine von SSLEntwicklungsschritteSSL 1.0NetscapeSSL 2.0SSL 3.0TLS 1.0RFC 2246TLS 1.1
  • 21. Die transparente SSL Zwischenschicht4 SECURESOCKTLAYER21SSL im OSI ModelSSL ImplemetierungTCPIPNetzwerkschichtQuelle: Schwenk, Jörg (2005): Sicherheit und Kryptographie im Internet, 2.Auflage, ViewegHTTP(S)SSL RecordSSL Handshake
  • 22. SSL Protokoll Aufbau im Detail4 SECURESOCKTLAYER22ProtokollübersichtHand-shakeChange-ChiperAlertRecord LayerTCPQuelle: Schwenk, Jörg (2005): Sicherheit und Kryptographie im Internet, 2.Auflage, ViewegHTTP(s) - AnwendungsprotokollTLS
  • 23.  Funktion Sicherstellung der Authentizität der Gegenstelle durchZertifikate Austausch der öffentlichen Schlüssel Bei X.509 Zertifikaten Ausstellung durchCertifcation Authorities (CA) Zertifikat beinhalte folgende Felder Aussteller und Inhaber Gültigkeitsdauer Zertifizierungspfad (LDAP) Public Key Verwendete Algorithmen Mit dem PrivateKey verschlüsselter Hashwert über Zertifikat4 SECURESOCKTLAYER23Exkurs: Zertifikate nach X.509-Standard
  • 24.  Beispiel Zertifikat:4 SECURESOCKTLAYER24Exkurs: Zertifikate nach X.509-StandardIssuer VeriSign, Inc.Subject CIS GmbHpremium01.privatepilot.deValidationPeriod01-01-2008 00:00:00 UTC31-01-2009 23:59:59 UTCPublic Key RSA, 0x433d9384582...Algorithm MD5 + RSASignature 0x3a53cb25445...0x53f2MD5 DigestEntschlüsselung mitPrivateKey
  • 25.  Sichere Identifizierung erfordert dritte Instanz, derbeide Kommunikationspartner vertrauen Erstellung eines eindeutigen Zertifikats Ein CA validiert die Identität des Zertifikatsinhabers aufkonventionellem Weg (Ausweis, Handelsregisterauszug) Die CA erstellt das Zertifikat und schickt Zertifikat (per E-Mail)und privaten Schlüssel (per Post) an Antragsteller Certification Authoritys authentifizieren sichgegenseitig In Deutschland gilt ergänzend Signaturgesetz – SigG Risiko durch die Vielzahl der Schlüssel/CA4 SECURESOCKTLAYER25Exkurs: Zertifikate nach X.509-Standard
  • 26. 4 SECURESOCKTLAYER26SSL Handschake ProtokollClient_Hello• Verfügbare sym.Verschlüsselung•Client ZufallszahlServer_Hello• Verschlüsselung• Server ZufallszahlServer_CertifikatServer-Zertifikat mitPublic KeyClientKeyExchangeSym. Schlüssel,verschlüsselt mitPublic KeyVerify_KeySicherer Kanal Sicherer Kanal
  • 27.  Einfach gehaltenes Protokoll Besteht neben dem Header nur aus dem Wert 1 CCS „erzwingt“ die Verschlüsselung neuauszuhandeln Beim Versenden dieser kurzen Nachricht darfallerdings nicht vergessen werden, sie mit Hilfe deralten Spezifikationen zu komprimieren bzw. zuchiffrieren4 SECURESOCKTLAYER27Change-Cipher-Spec ProtokollVersion: 3.0Type: 20 Length:0x1 CCS: 1
  • 28. 4 SECURESOCKTLAYER28Change-Cipher-Spec Protokoll
  • 29.  Tritt bei Fehlern in der Kommunikation in Kraft4 SECURESOCKTLAYER29Alert ProtokollVersion: 3.0Type: 21 Length:0x2 Grad Beschreibung
  • 30. SSL Record Protokoll4 SECURESOCKTLAYER30Ablauf einer VerschlüsselungA B C D E F G H IAnwendungsdatenA B C D E F G H IAufteilung in„Records“XXXkomprimierter„Record“komprimieren„Records“ dürfen max. 16 KB groß seinXXXverschlüsselter„Record“.........TCP Paketverschlüsseln MAC generierenübermittelnQuelle: http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html
  • 31. Daten4 SECURESOCKTLAYER31Darstellung eines RecordsVersion: 3.0Type: 23 Length:0x2Message Autehtification CodeVerschlüsseltQuelle: Schwenk, Jörg (2005): Sicherheit und Kryptographie im Internet, 2.Auflage, Vieweg
  • 32. Passive Traffic-Analyse32 Länge des http-get()-Statements undder Antwort ist bekannt Scann gegen Webserver auf passendeURLs und HTML-Seiten möglich Beispiel:unmittelbar nach Verbindungsaufbau Client  Server: 53 Byte übertragen Server  Client: 3742 Byte übertragen Suche nach 53 Byte langer URLs, die3742 Byte Daten zurückliefern5 ANGRIFFSMÖGLICHKEITEN
  • 33.  Alle Informationen zwischen Server und Clientwerden vom Hacker abgefangen Server und Client „denken“ immer, dass sie direktmiteinander kommunizieren Nur erfolgsversprechend während desVerbindungsaufbaus (einzige unverschlüsselteKommunikation)Aktive Attacke5 ANGRIFFSMÖGLICHKEITEN33Man-in-the-middle Attake
  • 34. Sonstige Angriffsmöglichkeiten34 Schwachpunkt sitzt vor demBildschirm Unwissenheit Zu schwache Passwörter Sozial Hacking (Geburtsdatum,Nachname etc.) Phishing Versand vom SPAM Mail mit derAufforderung persönlicheZugangsdaten bekannt zu geben Trojaner5 ANGRIFFSMÖGLICHKEITEN
  • 35.  Ursprünglich von Netscape entwickelt Erste Implementierung 1995 in Netscape Navigator SSL wahrt: Authentizität durch Zertifikate und asymmetrischeVerschlüsselung Integrität durch eindeutige Hashes Datenschutz (privacy) durch symmetrische Verschlüsselung SSL ist nach heutigem Kenntnisstand sehr sicherund schnell Universell einsetzbar, da transparent im OSIProtokoll implementiert6 ZUSAMMENFASSUNG35Fazit
  • 36.  Protokollstruktur verifiziert Sicherheit gegenseitig Standardisierte Weiterentwicklung durch IETF alsTLS (SSL 3.1) Dokumentiert als Request for Comment (RfC) Schwachpunkte sind Certification Autorities Verwaltung sehr vieler Schlüssel und Benutzer (Passwörter) Mögliche Angriffspunkte Passive Traffic-Analyse Man-in-the-middle-Attake Phishing, Trojaner, schwache Passwörter6 ZUSAMMENFASSUNG36Fazit
  • 37.  Beutelspacher, Albrecht (1994): Kryptologie, 4Aufl., Springer Boon, Rochard E. Smith (1998): Internet-Kryptographie, 1. Aufl., Addison-Wesley Garfinkel, Simson / Spafford, Gene (2002): WebSecurity, Privacy and Commerce, 2. Aufl., O‘Reilly Rescorla, Eric (2000): SSL and TLS, 1. Aufl., Addison-Wesley Schumacher, Roger (2007): Geschichte derKryptographie. 1 Aufl., Vieweg Schwenk, Jörg (2005): Sicherheit und Kryptographieim Internet, 2.Aufl., Vieweg7 LITERATURVERZEICHNIS37Quellen (1/2)
  • 38.  Wobst, Reinhard (2000): Abenteuer Kryptologie, 1.Aufl., Addison-WesleyOnlinequellen: Spezifikation von SSL:http://wp.netscape.com/ssl13/3-SPEC.HTM Einführung in SSL:http://www.repges.net/SSL/ssl.html SSL Zusammenfassunghttp://www1.tfh-berlin.de/~toby/vh/ssl7 LITERATURVERZEICHNIS38Quellen (2/2)
  • 39. 5c91a528471ec0b430de5fbdd73cea54abd853daffff69f5ea2e1fc005590f86
  • 40. Vielen Dank für Ihre AufmerksamkeitNoch Fragen?