6. Von damals bis heute
6
HTTPS wurde von Netscape entwickelt und zusammen
mit SSLv1 erstmals 1994 erwähnt
Kipp Hickman von Netscape veröffentlichte SSLv2 als
IETF Draft in 1995
The SSL Protocol is designed to
provide privacy between two
communicating applications
(a client and a server).
Second, the protocol is designed
to authenticate the server, and
optionally the client. [...]
Quelle: Wikipedia
7. Von damals bis heute
7
SSLv2 gilt seit Ende 1996 als gebrochen
– Aktiver Man-in-the-Middle-Angriff erlaubt die komplette
Kompromittierung der Vertraulichkeit und Integrität der
gesicherten Übertragen (http://osvdb.org/56387)
SSLv3 wird wiederum von drei Wissenschaftlern bei
Netscape erarbeitet und 1996 veröffentlicht
1999 wird SSL zu TLS umbenannt, jedoch minimale
Änderung der Spezifikation zu SSLv3 (SSLv3.1->TLS 1.0)
8. SSL und/oder TLS
8
2000 – 2006 erfolgt eine Vielzahl wissenschaftlicher
Angriffe gegen SSLv3 und TLS 1.0
– Padding-Oracle-Angriff gegen Padding der Block Cipher (2002 Vaudenay
„Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS...“)
– Timing-Attacke (2003 Brumley u. Boneh „Remote timing attacks are practical“)
– Chosen-Plaintext-Attacke: IV ist vorhersagbar (2006 Bard)
TLS 1.1 wird 2006 als Standard veröffentlicht (RFC4346)
– Entfernung der Export Ciphers (40 Bit)
Bereits 2008 wird die finale Version von TLS 1.2
als Ablösung von TLS 1.1 veröffentlicht (RFC5246)
9. SSL und TLS im Web 2015
9
Quelle: Universal-Pictures
10. SSL und TLS im Web 2015
10
Quelle: https://www.trustworthyinternet.org/ssl-pulse/
13. Designschwächen in SSL / TLS
16
Probleme basieren nicht auf den einzelnen
Implementierungen von SSL (OpenSSL, LibreSSL,
MatrixSSL, PolarSSL, GnuTLS usw.)
Lässt sich in der Regel nicht durch die Entwickler
beheben, sondern bedarf
– Anpassung und Änderung des Protokolls (Versionsupdate)
– Workaround durch Deaktivierung betroffener Cipher Suites
14. POODLE: SSLv3 vulnerability
(CVE-2014-3566)
24
Padding Oracle On Downgraded Legacy Encryption
Angreifer muss einen passiven Man-in-the-Middle-Angriff
durchführen (Sniffing) und innerhalb des Opfer-Browsers
256 x n (n-Byte langes Cookie) Anfragen abschicken
können
https://www.openssl.org/~bodo/ssl-poodle.pdf
15. POODLE: SSLv3 vulnerability
(CVE-2014-3566)
Keine bekannte Ausnutzung in the wild
– Wahrscheinlicher im Gegensatz zu BEAST, BREACH oder CRIME
Empfehlung: Deaktivierung von SSLv3
Verwundbare SSL/TLS-Versionen
TLS 1.2 -
TLS 1.1 -
TLS 1.0 -
SSL 3.0 JA
SSL 2.0 JA
25
18. FREAK: < TLS 1.1 vulnerability
28
Factoring RSA Export Keys
Angreifer muss einen aktiven Man-in-the-Middle-Angriff
durchführen und verlangt vom Server die Verwendung
von EXPORT Cipher Suites
Faktorisierung von 512bit RSA-Schlüsseln kostet ca. 100$
Amazon EC2-Rechenzeit und dauert weniger als 8
Stunden
https://www.smacktls.com/
19. FREAK: < TLS 1.1 vulnerability
Empfehlung: Deaktivierung von TLS 1.0 und kleiner
Verwundbare SSL/TLS-Versionen
TLS 1.2 -
TLS 1.1 -
TLS 1.0 JA
SSL 3.0 JA
SSL 2.0 JA
29
Quelle: https://freakattack.com/
HTTPS serves of Alexa‘s Top 1 Million Domains
21. Implementierungsfehler in SSL / TLS
31
Fehler erzeugt durch einzelne Entwickler / Teams
innerhalb einer Bibliothek
Fehlerhafte Qualitätssicherung des Codes
Typische Softwareschwachstellen
– Buffer Overflows
– Control Flow Manipulation
22. Heartbleed (CVE-2014-0160)
32
Heartbeat-Nachrichten dienen der Sicherstellung einer
intakten Kommunikationsverbindung über UDP
Fehlerhafte Überprüfung der Längenangabe der
Heartbeat-Anfrage
Heartbeat-Antwort liefert die empfangene Nachricht
zurück und mehr (max. 64 kB)
– Auslesen zufälliger Werte, die zum aktuellen Zeitpunkt in dem
dynamischen Prozessspeichers des Webserver-Prozesses liegen
http://heartbleed.com/ Verwundbare OpenSSL-Versionen
OpenSSL 1.0.1 bis 1.0.1f
OpenSSL 1.0.2-beta bis 1.0.2-beta1
23. Heartbleed (CVE-2014-0160)
35
„A HeartbeatRequest message can arrive almost
at any time during the lifetime of a connection.
Whenever a HeartbeatRequest message is
received, it SHOULD be answered with a
corresponding HeartbeatResponse message.“
https://tools.ietf.org/html/rfc6520
25. Authentisierung / Identifizierung bei
TLS
38
Woher weiß der Browser, dass der angefragte Server
legitim ist?
Server-Zertifikate sind wie Ausweisdokumente
– Der Aussteller der Zertifikate ist vergleichbar mit
einer nationalen Passbehörde
26. Vertrauenswürdige CAs in Browsern
39
Keine zentrale Datenbank
Internet Explorer / M$ CTL
Mozilla Firefox
iOS / Android
Insgesamt über 650 CAs
inklusive Sub-CAs
Quelle: https://www.eff.org/observatory
28. Beispiel: Aufbrechen der Verschlüsselung
41
Gefälschtes Zertifikat ist nicht gültig
Ist das ein Problem?
29. You Won’t Be Needing These Any More
42
Untersuchung von ca. 48 Mio. HTTPS-Seiten ergab:
– Über 140 CA-Zertifikate in den unterschiedlichen Truststores
werden nicht verwendet (Geheimdienste lassen grüßen)
– Von insgesamt 426 CA-Zertifikaten werden nur 2/3 benutzt
Welche CAs werden für .de-Domains gebraucht?
http://fc14.ifca.ai/papers/fc14_submission_100.pdf
32. Exkurs Zertifikate
46
Quelle: https://www.certcenter.de/ssl-guide
Domain Validation
- Verschlüsselung
- Validierung der
Domain-Kontrolle
- Vorhängeschloss im
Browser
- Ausstellung in
wenigen Minuten
Organization Validation
- Authentifizierung des
Unternehmens
- Nachweis des Rechts zur
Domainnutzung
- Unternehmensinfo im
Zertifikat
- Ausstellung in 1-2 Tagen
Extended Validation
- Strikte
Industriestandard-
Authentifizierung für
Unternehmen
- Für Unternehmen
vorteilhafte grüne
Adressleiste im Browser
- Ausstellung in 7-10
Tagen
43. Lebenszyklus von Zertifikaten
57
Zertifikatsantrag: Ein Benutzer beantragt ein Zertifikat.
Antragsprüfung: Die Registration Authority (RA) prüft die
Identität des Benutzers/Antragstellers.
Generierung/Ausstellung der Zertifikate: Die Certificate
Authority (CA) stellt das Zertifikat aus. Dieses Zertifikat
enthält Angaben zu Inhaber, Herausgeber, erlaubter
Nutzung und Lebensdauer (gültig von und gültig bis)
Revokation/Ungültigkeit: Das Zertifikat wird vor dem
Verfall revoziert bzw. für ungültig erklärt.
Zertifikats-Laufzeitende: Die Lebensdauer des Zertifikats
ist abgelaufen.
Zertifikats-Renewal: Erneuerung des Zertifikats.
44. Widerrufen von Zertifikaten
58
Welche Möglichkeiten gibt es, um ein Zertifikat zu
widerrufen?
Quelle: Cartoonstock.com
Quelle: stern.de
45. CRL-Listen
59
Jede CA hat die Möglichkeit, Sperrlisten
(Certificate-Revocation-Listen) zu publizieren
48. CRL-Listen
62
Werden vom Webbrowser in regelmäßigen Abständen
abgerufen
Blacklist-Ansatz
Soft-Fail bei allen Browsern
– Wenn keine CRL bezogen werden konnte,
gelten alle Zertifikate als gültig
– Angreifer auf der Netzwerkebene kann Empfang einer aktuellen
CRL einfach unterbinden
49. OCSP
63
Online Certificate Status Protocol
Netzwerkprotokoll auf Basis von HTTP
Clients (Webbrowser) können dadurch den Status von
Zertifikaten bei der CA erfragen
OCSP-Antworten sind digital von der CA signiert
Web
Browser
Web
Server
OCSP
Server
Fetch One
OCSP Status
Fetch
Certificate
50. OCSP
64
Vor dem Aufruf einer HTTPS-Webseite wird eine Anfrage
vom Browser an den OCSP-Responder der CA gestellt
OCSP-
Anfrage
Status
good
Browser
ruft
Seite auf
OCSP-
Anfrage
Status
revoked
Browser
verweigert
Aufruf
51. OCSP
65
Was passiert, wenn der OCSP-Responder nicht antwortet?
OCSP-
Anfrage
???
Browser
ruft
Seite auf
Browser
ruft
Seite auf
Quelle: https://sirdoomsbadcompany.wordpress.com
52. OCSP
66
OCSP bietet im Gegensatz zu CRLs folgende Vorteile:
– Sekundengenaue Datenbasis
– CA kann Zertifikat als bad markieren, wenn verwendete Schlüssel-
Algorithmen/-Längen oder Signaturverfahren als nicht mehr sicher
gelten
Außer Firefox bietet kein Browser den Hard-Fail an
– OCSP-Responder werden als Flaschenhals des WWWs angesehen
– Gefährdung der Privatsphären
53. Revocation-Wirrwarr
67
Behandlung von widerrufenen Zertifikaten obliegt den
Browsern
Reicht vom Nichtbeachten des Widerruf-Status bis hin
zum Verweigern des Verbindungsaufbaus
Umfassende Analyse von IE, Firefox, Chrome unter
Windows sowie unter iOS/Android
(https://www.grc.com/revocation)
67. Welche Algorithmen sind zu wählen?
86
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/T
echnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf
68. Wichtige Server-Header
HSTS (HTTP Strict Transport Security)
– Signalisiert dem Browser, dass alle zukünftigen Anfragen
ausschließlich über HTTPS erfolgen dürfen
– Verhindert anschließende SSL-Stripping-Attacken
87
70. Wichtige Server-Header
HPKP (HTTP Public Key Pinning)
– Pinning des Zertifikats der CA und/oder Domain (CN)
– https://github.com/hannob/hpkp
– https://tools.ietf.org/html/rfc7469
– https://developer.mozilla.org/en-
US/docs/Web/Security/Public_Key_Pinning
89
71. OCSP Stapling
90
OCSP-Anfragen werden vom Browser an den Server
verlagert
Webserver liefert zusammen mit dem Zertifikat eine
aktuelle und von der CA signierte OCSP-Antwort aus
Web
Browser
Web
Server
OCSP
Server
Fetch One
OCSP Status
Fetch
Certificate
& OCSP
72. OCSP Stapling
91
Vorteile:
– Auslastung der OCSP-Responder hält sich in Grenzen
– Keine Verletzung der Privatsphäre
– Keine Verzögerung beim Browsen
Unterstützung der Webserver:
– Apache ab Version 2.3.3
– nginx ab Version 1.3.7
– LiteSpeed ab Version 4.2.4
http://news.netcraft.com/archives/2013/07/19/microsoft
-achieves-world-domination-in-ocsp-stapling.html
73. OCSP must-staple
92
OCSP Stapling hat folgendes Problem:
– Wird ein Serverzertifikat gestohlen (privater Schlüssel), so kann
der Angreifer dieses für gezielte Man-in-the-Middle-Angriffe
nutzen, indem er einfach bei seinem Server das OCSP Stapling
deaktiviert und dem Opfer den Revocation-Status der CA
verschweigt.
X.509v3 Extension: OCSP Stapling Required
http://tools.ietf.org/html/draft-hallambaker-
muststaple-00
Seit 2011 ca. über 20 bekannte Angriffe gegen SSL/TLS Cipher, CAs und Implementierungen
Eine Schwachstelle braucht einen markanten Namen, eine eigene Website und das wichtigste ein passendes Logo
Wie lange verschlüsseln wir im Internet schon? Gab es was anderes als SSL
Vorstellung prominenter Beispiele, tatsächliche Bedrohung, Maßnahmen, nicht alle können durch neue Protokollversionen behoben werden
Woher kommen die Zertifikate, wie weiß der Browser wem zu vertrauen ist
Was passiert wenn ein Zertifikat kompromittiert wurde
DIY Analysen
Was bringt die Zukunft und welche Ansätze gibt es dem Dilemma zu entkommen?
- e-Commerce treibender Faktor der SSL-Verschlüsselung
SSLv2 Handshake war nicht geschützt Downgrade Attacke
MAC basierte ausschließlich auf MD5 Length Extension Attacke
Microsoft nimmt Einfluss und ist Namensgeber für TLS
- Entfernung der EXPORT Ciphers, Überbleibsel aus den late 80s / early 90s kalter Krieg
- Jetzt liegen 7 Jahren dazwischen und das gesamte Internet ist gesichert durch TLS 1.2?
Alexa Top 1 Million liefert ca. 150 000 gesicherte Webseiten
Weniger als ¼ der SSL/TLS-Server sind sicher
Unterstützte Protokolle können das Sicherheitsniveau nicht 1:1 abbilden
Rating von SSLLabs
TLS dient zur verschlüsselten Übertragung der Daten zwischen Browser und Server
Authentisierung über Zertifikate um die Identität zu beweisen
- TLS-Handshake wird vom Client initiiert (Zufallszahl, unterstützte Protokolle und untersützte Algorithmen ( Ciphersuites)
Lempel-Ziv-Welch-Algorithmus Begründer der heutigen Kompremierungen
Wörterbuch mit vorher fester Größe wird genutzt um häufige Werte abzulegen und dann nur noch Referenzen auf Einträge in Wörterbuch im komprimierten Ausgabe verwenden
Angreifer manipuliert Request indem er bekannte Werte, wie z.B. Header in die URL der Anfrage kopiert
- Ähnlich zu CRIME aber Ausnutzung der HTTP-Kompression anstelle der TLS-Kompression
- Theoretisch weil HTTP-Kompression ein essentieller Bestandteil der heutigen Architektur im Internet ausmacht (Bandbreite kostet)
- 2011 hat man Empfohlen die CBC Ciphers von AES wegen BEAST nicht mehr zu nutzen
- SSLv3 Downgrade Attack Dadurch sind auch alle TLS1.0 anfällig die noch SSLv3 unterstützem
Aktiver Man-in-the-Middle Angriff verweigert TLS
Handshake ist noch nicht authentisiert und Browser bemerkt den aktiven Man-in-the-Middle Angriff nicht
Der kalte Krieg schlägt zurück
Finit-State-Machines (Endliche Automaten wurden genutzt um alle erreichbaren Zustände unterschiedlicher Ciphersuites zu analysieren)
10% der Alexa Top 1 Million Webseiten bieten noch EXPORT Cipher an
Abschließend zu Designschwächen:
Eine Vielzahl von serverseitigen Bibliotheken und Implementierungen sind betroffen
Behebung dauert in der Regel zu lange (Appliances hinken hinter her)
Browser-Hersteller versuchen Schwachstellen client-seitig zu mitigieren
Einführung um TLS über unzuverlässige, verbindungslose UDP-Verbindungen zu gewährleisten
Deutsche Ingineurkunst von einem Studenten der FH Münster im Zuge seiner Promotion
Bug war 27 Monate im Code (31.12.2011 – 7.4.2014) Gefahr von OpenSource Software (nur ein fest angestellter Mitarbeiter<)
Eintrittswahrscheinlichkeit HOCH da Heartbeat-Anfragen zu JEDER Zeit erfolgen können
„Katastrophal ist das richtige Wort. Auf einer Skala von 1 bis 10 ist dies eine 11.“ Bruce Schneier
CCS kann normalerweise nur am Ende des TLS-Handshakes erfolgen und ist verschlüsselt
Bug war über 16 Jahre im TLS-Code und wurde durch einen mathematischen Ansatz zur formalen Beweisführung
- Damit Browsern Zertifikaten trauen können, müssen die Wurzeln (Root-Zertifikate) in Browser verankert sein
Geld regiert die Welt
Lobby-Arbeit
- Aktiver Man-in-the-Middle, der ein gefälschtes Serverzertifikat vorweist (nicht vertrauenswürdige CA, Selbstsigniert)
- Wenn Unternehmen TLS aufbrechen ist der Proxy verantwortlich, wie nicht vertrauenswürdige Verbindungen nach innen weitergeleitet werden
In allen Truststores haben die Forscher 426 CAs ermittelt
Davon wurden nur 2/3 tatsächlich im Internet gefunden, was ist mit den restlichen über 140 Cas?
- Wildcard-Zertifikat für *.google.com ausgestellt um Iranische Google-Mail Nutzer zu überwachen
- Verkettung unglücklicher Umstände führte zur Signatur von zwei Sub-/Intermediate CA Zertifikaten
- Im Februar 2015 war Lenovo negativ in der Schlagzeilen, da Adware Vorinstalliert war, welches ein Root-Zertifikat in die CTL von Microsoft installiert hat und der private Schlüssel dieses Root-Zertifikates konnte aus der Adware selbst exportiert werden
Keine Bindung zwischen TLD und CA
CAs unterscheiden sich wesentlich im Punkto Kosten
- Haben CAs in den letzten Jahren dazu gelernt? Manche vllt. schon
- Im Gegensatz zu OV oder EV Zertifikaten erfolgt die Verifikation bei DV Zertifikaten in der Regel vollautomatisiert ab
Aktiver Man-in-the-Middle Angriff z.B. in einem öffentlichen WLAN oder lokalen Netzwerk
Was versteht man unter Revocation?
Zertifikate sind keine materiellen Gegenstände die zurückgefordert werden können
Was einmal im Internet ist, bleibt da für immer
Heartbleed verursachte ein Anwachsen der Globalsign CRL von 22kb auf 4,7MB (Kosten 400.00$ pro Monat)
Wer verursacht die Kosten
- Soft-Fail Ansatz erlaubt einem Anfgreifer auf Netzwerkebene das Unterbinden des CRL-Downloads
- Reaktion ist Browser-abhängig im Zuge von Heartbleed wurde aber offensichtlich, dass aktuelle OCSP-Infrastrukturen der CAs nicht für hohe Lasten ausgelegt sind
Browser, sogar unterschiedliche Versionen behandelt Revocation anders
Wie schon gesehen, reicht es nicht aus die aktuellste TLS-Version zu unterstützen, sondern auch alte explizit zu deaktivieren
Schwache Ciphers, nicht authentisierte Ciphers, NULL Ciphers
Abgelaufene Zertifikate werden von Browsern wie nicht vertrauenswürdige Zertifikate behandelt
Wenige CAs signieren Zertifikate direkt mit der Root-CA, welche in Browsern als vertrauenswürdige hinterlegt sind (Kronjuwelen)
SHA1 wird ab 2016 von Chrome …
Feherlhafte Servernamen (Kommt nicht vor?)
- Wichtig: Manche Projekte veraltet und Cipherlisten statisch
- Fallstrick wenn OpenSSL nicht mit allen Protokollen / Cipher Suites kompiliert wurde
- Header wird im Anschluss behandelt
- Wichtig Haken setzen bei nicht Veröffentlichung
Zeitersparnis, um nicht sämtliche Browser selbst Testen zu müssen
Kunden sind nicht Security-affin und müssen zufriedengestellt
Tradeoff zwischen Sicherheit und operativem Betrieb: Oft Risikoakzeptanz
- Wie man hier sieht wird RC4 noch unterstützt? Warum?
Woher weiß der Browser, dass mein Ziel über HTTPS erreicht werden soll
Mit Hilfe von SSL-Stripping kann ein aktiver Man-in-the-Middle Angreifer ein Downgrade auf HTTP erzwingen
HTST Header übergibt dem Browser eine Zeitspanne für die ausschließlich TLS zum Ziel gesprochen werden darf
Pinning ist in der sicheren Entwicklung von mobilen Apps gefordert
Soll dazu dienen, dass nur legitime Zertifikate vom Browser erlaubt werden
Wichtig wenn man beim Zertifikatwechsel auch die CA wechselt, dass frühzeitig überschneidend anzukündigen
Woher weiß der Browser, dass mein Ziel über HTTPS erreicht werden soll
Mit Hilfe von SSL-Stripping kann ein aktiver Man-in-the-Middle Angreifer ein Downgrade auf HTTP erzwingen
HTST Header übergibt dem Browser eine Zeitspanne für die ausschließlich TLS zum Ziel gesprochen werden darf
Pinning ist in der sicheren Entwicklung von mobilen Apps gefordert
Soll dazu dienen, dass nur legitime Zertifikate vom Browser erlaubt werden
Wichtig wenn man beim Zertifikatwechsel auch die CA wechselt, dass frühzeitig überschneidend anzukündigen
Bisher hat der Browser vor jedem Seitenaufruf eine OCSP-Anfrage gestellt
- Der Hauptgrund warum ein Zertifikate revoked wird, ist der Verdachtsmoment, dass es kompromittiert wurde
TLSA-Record in DNS wiederum mit Fingerprint (OOB-Lösung) aber DNSSEC erforderlich
Lets Encrypt: Delivering TLS Everywhere (Mozilla, Akamai, Cisco, EFF, IdenTrust)