Let's Encrypt Die neue Sicherheit für Jeden
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Inhaltsverzeichnis 1 Let’s Encrypt 1 1.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Beteiligte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3.1 Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3.2 Server-Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3.3 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Geschichte und Zeitplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5 Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.6 Weblinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.7 Quellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Extended-Validation-Zertifikat 6 2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1 Browserunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Vergabekriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Weblinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5 Einzelnachweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3 X.509 9 3.1 Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1 Struktur eines X.509-v3-Zertifikats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2 Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3 Dateinamenserweiterungen für Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Beispiel für ein X.509-Zertifikat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.5 Weblinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4 Transport Layer Security 13 4.1 TLS in der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1 Versionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 i
ii INHALTSVERZEICHNIS 4.2 Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3.1 TLS-Protokolle im Protokollstapel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3.2 TLS Record Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.3 TLS Handshake Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.4 TLS Change Cipher Spec Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3.5 TLS Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3.6 TLS Application Data Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3.7 Berechnung des Master Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4.1 Padding-Oracle-Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4.2 BEAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4.3 Kompressionsangriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4.4 Downgrade auf Exportverschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4.5 Implementierungsfehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5 Vor- und Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.6 Implementierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.7 Siehe auch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.8 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.9 Weblinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.10 Einzelnachweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5 Hypertext Transfer Protocol Secure 23 5.1 Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2 Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3 Client-Verarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3.1 Varianten der HTTPS-Anwahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3.2 Vorinstallierte Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4 Server-Betrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4.1 Zertifikat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4.2 IP-Adressen bei mehreren Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4.3 Einbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4.4 Umstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.4.5 Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.5 Angriffe und Schwachstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.5.1 Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.5.2 Zertifikatsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.6 Spezifikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.7 Weblinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.8 Einzelnachweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.9 Text- und Bildquellen, Autoren und Lizenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.9.1 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
INHALTSVERZEICHNIS iii 5.9.2 Bilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.9.3 Inhaltslizenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Kapitel 1 Let’s Encrypt Let’s Encrypt (englisch, „Lasst uns verschlüsseln“) ist eine Zertifizierungsstelle, die Ende 2015 in Betrieb gegangen ist und kostenlose X.509-Zertifikate für Transport Layer Security (TLS) anbietet. Dabei ersetzt ein automatisierter Prozess die bisher gängigen komplexen händischen Vorgänge bei der Erstellung, Validierung, Signierung, Einrichtung und Erneuerung von Zertifikaten für verschlüsselte Websites.[1][2] 1.1 Überblick Ziel des Projekts ist es, verschlüsselte Verbindungen im World Wide Web zum Normalfall zu machen. Indem unter anderem Zahlung, Webserverkonfiguration, Validierungs-E-Mails und die Sorge um abgelaufene Zertifikate über- flüssig werden, sollen Aufwand für Einrichtung und Pflege von TLS-Verschlüsselung deutlich gesenkt werden.[3] Auf einem Linux-Webserver soll das Ausführen von nur zwei Befehlen genügen, um binnen 20 bis 30 Sekunden HTTPS-Verschlüsselung einzurichten, Zertifikate anzufordern und zu installieren.[4][5] Bei aktuellen Bestrebungen von großen Webbrowser-Projekten, unverschlüsseltes HTTP als überholt zu erklären und zukünftig davor zu warnen oder die Unterstützung einzuschränken, wird unter anderem auf die Verfügbarkeit von Let’s Encrypt gesetzt.[6][7] Dem Projekt wird das Potenzial zugesprochen, die standardmäßige Verschlüsselung des gesamten Web zu erreichen.[8] Es werden sogenannte Domain-Validation-Zertifikate ausgestellt. Organization-Validation- und Extended-Validation- Zertifikate werden nicht angeboten.[9] Um sowohl die eigene Vertrauenswürdigkeit, als auch gegen Angriffe und Manipulationsversuche zu schützen, soll auf größtmögliche Transparenz gesetzt werden. Dazu werden zum Beispiel regelmäßig Transparenzberichte veröffentlicht,[10] alle ACME-Transaktionen öffentlich protokolliert (u.a. mit Certificate Transparency) und möglichst viel auf offene Standards und freie Software gesetzt.[4] Der Name der Zertifizierungsstellen-Software „Boulder“ (englisch, „[Fels-]Brocken“) ist eine Anspielung auf ein Produkt der fiktiven Firma ACME (englisch acme ‚Gipfel‘, ‚Höhepunkt‘) aus den Trickfilmen um Road Runner und Wile E. Coyote. 1.2 Beteiligte Let’s Encrypt ist ein von der gemeinnützigen Internet Security Research Group (ISRG) angebotener Dienst. Haupt- sponsoren sind unter anderem die Electronic Frontier Foundation (EFF), die Mozilla Foundation, Akamai, Google Chrome und Cisco Systems. Weitere Beteiligte sind die Zertifizierungsstelle IdenTrust, die University of Michigan (U-M), die Stanford Law School, die Linux Foundation[11] sowie Stephen Kent von Raytheon/BBN Technologies und Alex Polvi von CoreOS.[4] 1
2 KAPITEL 1. LET’S ENCRYPT 1.3 Technik Let’s Encrypt besitzt ein RSA-Stammzertifikat, das in einem Hardware-Sicherheitsmodul verwahrt wird und nicht direkt verwendet wird. Es soll später durch ein ECDSA-Zertifikat ersetzt werden. Damit werden zwei Zwischen- zertifikate signiert, welche durch die Zertifizierungsstelle IdenTrust gegengezeichnet werden.[12] Eines davon dient dann zur Signierung der ausgestellten Zertifikate, das andere als Ersatz bei Problemen mit dem ersten. Durch die IdenTrust-Signatur können die ausgestellten Zertifikate in großen Webbrowsern über die vorinstallierten Stammzer- tifizierungsstellen geprüft werden. So werden Let’s-Encrypt-Zertifikate auf Client-Seite von Anfang an in der Regel ohne weiteres akzeptiert.[13] Längerfristig sollen direkt Let’s-Encrypt-Zertifikate in Anwendungen vorinstalliert wer- den. 1.3.1 Protokoll Das zur Automatisierung der Zertifizierung genutzte Challenge-Response-Verfahren heißt Automated Certificate Management Environment (ACME). Dabei werden verschiedene Anfragen an den Webserver der zu zertifizieren- den Domain gestellt. Anhand gegebenenfalls darauf erfolgenden passenden Rückmeldungen wird sichergestellt, dass der Antragsteller die Domain kontrolliert („domain validation“). Auf dem Server-System müssen diese Anfragen korrekt beantwortet werden. Dazu bietet das Protokoll verschie- dene Möglichkeiten. Bei einer wird dazu von der ACME-Client-Software ein besonders konfigurierter TLS-Server eingerichtet, der mittels Server Name Indication auf besondere Anfragen der Zertifizierungsstelle antwortet (Domain- Validierung mittels Server Name Indication, DVSNI). Dieses Verfahren wird allerdings nur für eine erste Zertifikats- ausstellung für eine Domain akzeptiert (sogenanntes „trust on first use“, TOFU – Vertrauen bei erster Benutzung). Danach kommt die alternative Validierung über ein bestehendes Zertifikat zum Einsatz. Bei Verlust der Kontrol- le über ein bereits ausgestelltes Zertifikat muss daher ein Zertifikat von einem Drittanbieter erworben werden, um wieder ein Let’s-Encrypt-Zertifikat zu erhalten. Die Validierungsverfahren werden mehrmals über verschiedene Netzwerkpfade durchgeführt. Zur Erschwerung von DNS-Spoofing ist die Prüfung von DNS-Einträgen von mehreren geographisch verteilten Standpunkten aus vorgese- hen. Bei ACME-Interaktionen werden JSON-Dokumente über HTTPS-Verbindungen ausgetauscht.[14] Ein Entwurf einer Spezifikation ist auf GitHub verfügbar.[15] Mehrere Versionen davon wurden als Entwurf eines Request for Comments für einen Internet-Standard bei der Internet Engineering Task Force (IETF) eingereicht.[16] 1.3.2 Server-Implementierung Die Zertifizierungsstelle besteht im Wesentlichen aus einer in Go geschriebenen Software namens Boulder, die die Server-Seite des ACME-Protokolles implementiert. Sie wird als freie Software auch in Quelltextform unter den Be- dingungen von Version 2 der Mozilla Public License (MPL) verbreitet.[17] Sie stellt eine REST-Programmierschnittstelle zur Verfügung, auf die TLS-verschlüsselt zugegriffen werden kann. 1.3.3 Clients Durch den offenen Standard ACME sind mittlerweile über 30 unterschiedliche Clients entwickelt worden.[18][19] Im Rahmen des Projekts wurde eine Apache-lizenzierte[20] Python-Referenzimplementierung namens certbot (früher letsencrypt) entwickelt. Über diese wird am Webserver eines Antragstellers das Zertifikat angefordert, der Domain- Validierungsprozess durchgeführt, das Zertifikat installiert, die HTTPS-Verschlüsselung im Webserver eingerichtet und später das Zertifikat regelmäßig erneuert.[21][4] Nach der Installation und Zustimmung zu einem Benutzerver- trag genügt die Ausführung des reinen Befehls, um ein gültiges Zertifikat installiert zu bekommen. Es können aber auch zusätzliche Funktionen wie OCSP stapling oder HTTP Strict Transport Security (HSTS) eingestellt werden.[14] Die automatische Einrichtung funktioniert zunächst allerdings nur mit Apache und nginx. Der Client kann aus den Paketquellen diverser Linux-Distributionen installiert werden, beispielsweise aus den Debian-Paketquellen.[22] Daneben gibt es mit acmetool[23] einen in Go geschriebenen mit vor-compilierten, statischen Programmdateien Client. Die Seite Get HTTPS for free![24] validiert ein Zertifikat per JavaScript im Webbrowser, wobei der Webadmin Anlei- tungen bekommt für verschiedene manuell auszuführende Schritte. Caddy[25] ist ein HTTP/2-kompatibler Webserver,
1.4. GESCHICHTE UND ZEITPLAN 3 Domainauswahldialog der vollautomatisch ein Zertifikat erzeugt und Inhalte per HTTPS ausliefert. Ein weiterer weit verbreiteter Client ist acme-tiny, ein in Python geschriebener Client, er ist weniger als 200 Zeilen lang und soll somit von jedem Nutzer vor der Verwendung selbst gelesen werden[26] . 1.4 Geschichte und Zeitplan Die Wurzeln des Projektes liegen in einem von der Electronic Frontier Foundation zusammen mit der University of Michigan betriebenen Projekt und einem unabhängigen Projekt von Mozilla, die in Let’s Encrypt zusammenge- führt wurden. 2014 wurde die Trägerorganisation, die ISRG, gegründet. Der Start von Let’s Encrypt wurde am 18. November des Jahres 2014 bekannt gemacht.[27] Am 28. Januar 2015 wurde das ACME-Protokoll erstmals bei der IETF zur Standardisierung eingereicht.[16] Am 9. April 2015 verkündeten die ISRG und die Linux Foundation ihre Zusammenarbeit.[11] Anfang Juni wurden die Stamm- und Zwischenzertifikate erzeugt.[13] Am 16. Juni wurde der endgültige Zeitplan für die Dienstaufnahme bekanntgegeben, wonach die Ausstellung des ersten Zertifikats für die Woche des 27. Juli vorgesehen war, dem eine Phase eingeschränkter Ausstellung folgen sollte, um die Sicherheit und Skalierbarkeit zu erproben.[28] Am 7. August wurde der Zeitplan geändert auf die erste Zertifikatsausstellung in der Woche des 7. Septembers und allgemeine Verfügbarkeit in der Woche des 16. November.[29] Ab 3. Dezember 2015 befand sich das Projekt in der offenen Betatest-Phase und kann seither von allen Interessierten genutzt werden.[30] Am 8. März 2016 wurde bekannt gegeben, dass schon über eine Million Zertifikate ausgestellt wurden.[31] Eineinhalb Monate später waren es über zwei Millionen, weitere eineinhalb Monate später über fünf Millionen Zertifikate ausge- stellt. Ein nennenswerter Teil des Zuwachses geht auf Kooperationen mit Webhosting-Anbietern wie zum Beispiel die Blogfarm WordPress.com (über 1 Million zusätzliche Sites) zurück, die für betreute Websites TLS-Verschlüsselung mit Let’s-Encrypt-Zertifikaten anbieten beziehungsweise diese eigenständig umgestellt haben. Seit der Öffnung des Betriebs erhöhte sich bis zum 22. Juni 2016 nach Messung von Browserhersteller Mozilla der weltweite Anteil ver- schlüsselter Websites von 39,5 auf 45 Prozent.[32] Am 17. März 2016 gab das Projekt bekannt, dem CA/Browser Forum beigetreten zu sein,[33] das Nutzung von X.509-v.3-Zertifikaten für TLS regelt. Dadurch soll Let’s Encrypt der Aufnahme in Webbrowser als vorinstallierte Stammzertifizierungsstelle näher kommen. Am 12. April 2016 ging das Projekt aus der offenen Betaphase in den offiziellen Regelbetrieb über.[34]
4 KAPITEL 1. LET’S ENCRYPT 1.5 Siehe auch • CAcert 1.6 Weblinks Commons: Let’s Encrypt – Sammlung von Bildern, Videos und Audiodateien • offizielle Webpräsenz • Seth Schoens Vorlesung bei Libre Planet 2015 zu Let’s Encrypt (englischsprachig) • technische Einführung in einem Blogeintrag von David Wong (englischsprachig) 1.7 Quellen [1] Sean Michael Kerner: Let’s Encrypt Effort Aims to Improve Internet Security. In: eWeek.com. Quinstreet Enterprise, 18. November 2014, abgerufen am 27. Februar 2015 (englisch). [2] Peter Eckersley: Launching in 2015: A Certificate Authority to Encrypt the Entire Web. In: eff.org. Electronic Frontier Foun- dation, 18. November 2014, abgerufen am 27. Februar 2015 (englisch). [3] Liam Tung (ZDNet), 19. November 2014: EFF, Mozilla to launch free one-click website encryption [4] Fabian Scherschel (heise.de), 19. November 2014: Let’s Encrypt: Mozilla und die EFF mischen den CA-Markt auf [5] Rob Marvin (SD Times), 19. November 2014: EFF wants to make HTTPS the default protocol [6] Richard Barnes (Mozilla), 30. April 2015: Deprecating Non-Secure HTTP [7] The Chromium Projects – Marking HTTP As Non-Secure [8] Glyn Moody, 25. November 2014: The Coming War on Encryption, Tor, and VPNs – Time to stand up for your right to online privacy [9] Steven J. Vaughan-Nichols (ZDNet), 9. April 2015: the web once and for all: The Let’s Encrypt Project [10] Zeljka Zorz (Help Net Security), 6. Juli 2015: Let’s Encrypt CA releases transparency report before its first certificate [11] Sean Michael Kerner (eweek.com), 9. April 2015: Let’s Encrypt Becomes Linux Foundation Collaborative Project [12] Reiko Kaps (heise.de), 17. Juni 2015: SSL-Zertifizierungsstelle Lets Encrypt will Mitte September 2015 öffnen [13] Reiko Kaps (heise.de), 5. Juni 2015: Let’s Encrypt: Meilenstein zu kostenlosen SSL-Zertifikaten für alle [14] Chris Brook (Threatpost), 18. November 2014: EFF, Others Plan to Make Encrypting the Web Easier in 2015 [15] Draft ACME specification. [16] R. Barnes, P. Eckersley, S. Schoen, A. Halderman, J. Kasten: Automatic Certificate Management Environment (ACME) draft-barnes-acme-01. 28. Januar 2015. [17] https://github.com/letsencrypt/boulder/blob/master/LICENSE.txt [18] List of Client Implementations. In: Let’s Encrypt Community Support. 25. Oktober 2015, abgerufen am 25. März 2016. [19] ACME Client Implementations. In: Documentation - Let’s Encrypt - Free SSL_TLS Certificates. 2. Juli 2016, abgerufen am 27. Februar 2017. [20] https://github.com/letsencrypt/letsencrypt/blob/master/LICENSE.txt [21] James Sanders (TechRepublic), 25. November 2014: Let’s Encrypt initiative to provide free encryption certificates [22] ITP: letsencrypt – Let’s Encrypt client that can update Apache configurations
1.7. QUELLEN 5 [23] acmetool. In: hlandau.github.io. Abgerufen am 25. März 2016. [24] Get HTTPS for free! In: gethttpsforfree.com. Abgerufen am 25. März 2016. [25] Caddy – The HTTP/2 Web Server with Fully Managed SSL. In: caddyserver.com. Abgerufen am 25. März 2016. [26] GitHub - diafygi/acme-tiny: A tiny script to issue and renew TLS certs from Let’s Encrypt. In: github.com. Abgerufen am 2. März 2017 (englisch). [27] Joseph Tsidulko: Let’s Encrypt, A Free And Automated Certificate Authority, Comes Out Of Stealth Mode. In: crn.com. 18. November 2014, abgerufen am 26. August 2015 (englisch). [28] Josh Aas: Let’s Encrypt Launch Schedule. Let’s Encrypt. 16. Juni 2015. Abgerufen am 19. Juni 2015. [29] Updated Let’s Encrypt Launch Schedule. 17. August 2015. [30] Entering Public Beta. Abgerufen am 4. Dezember 2015. [31] heise online: Let’s Encrypt: 1 Million Zertifikate ausgestellt. In: heise online. Abgerufen am 9. März 2016 (deutsch). [32] Dennis Schirrmacher (heise online), 23. Juni 2016: Fünf Millionen Zertifikate: Let’s Encrypt wächst rasant [33] heise online: Let’s Encrypt tritt CA/Browser Forum bei. In: heise online. Abgerufen am 20. März 2016 (deutsch). [34] Let’s Encrypt Leaves Beta. Abgerufen am 17. April 2016.
Kapitel 2 Extended-Validation-Zertifikat Ein Extended-Validation-Zertifikat wird in allen gängigen Browsern (hier Mozilla Firefox) zum Beispiel in der Adressleiste vermerkt. Extended-Validation-SSL-Zertifikate (EV-SSL; deutsch etwa „Zertifikate mit erweiterter Überprüfung“) sind X.509 SSL-Zertifikate, deren Ausgabe an strengere Vergabekriterien gebunden ist. Dies bezieht sich vor allem auf eine detaillierte Überprüfung des Antragstellers durch die Zertifizierungsstelle. Die Vergabekriterien sind in den „Richtlinien für Extended-Validation-Zertifikate“[1] spezifiziert. Die Richtlinien werden vom CA/Browser Forum herausgegeben, einem freiwilligen Zusammenschluss von Zertifizierungsstellen und Browser-Herstellern. Genutzt werden die Zertifikate meist, um Webanwendungen per HTTPS zu sichern und den Anwendern vor dem Hintergrund von Phishing-Angriffen eine zusätzliche Sicherheit zu geben, etwa beim Online-Banking. 6
2.1. MOTIVATION 7 2.1 Motivation Das vorrangige Ziel der EV-SSL-Zertifikate ist es, Phishing mit verschlüsselten und damit auf den ersten Blick siche- ren Websites zu erschweren. Durch die Einführung eines neuen, „erweiterten“ Zertifikats und der grün-hinterlegten Adresszeile des Browsers soll das Vertrauen der Benutzer in die sichere Verbindung zur gewünschten Websites ge- stärkt werden. Die Ausgabe von SSL-Zertifikaten ist zwar grundsätzlich an eine Überprüfung des Antragstellers gebunden, der Preis- druck unter den Anbietern hat aber zu einer teilweise laxen Vergabepraxis und zu vereinfachten Zertifikaten geführt, die nicht mehr als den Domain-Namen zertifizieren. Damit können auch Betrüger SSL-Zertifikate zur Steigerung ihrer Glaubwürdigkeit verwenden, ohne ihre Identität preisgeben zu müssen. Kritiker sehen in dem neuen Standard teils den Versuch der Zertifizierungsstellen, sich dem Preiskampf in der SSL- Zertifikat-Ausgabe durch die Einführung eines neuen Premium-Produktes zu entziehen, das dem Benutzer wenig zusätzliche Sicherheit bringt, und das auch mit anderen Mitteln zu erreichen wäre. Auch könnten kleinere Anbieter geschäftlich benachteiligt werden.[2] In der Version 1.1[3] wurde teils versucht, diese Einwände zu berücksichtigen. 2.2 Benutzerschnittstelle In der Adresszeile des Browsers wird zusätzlich ein Feld angezeigt, in dem Zertifikats- und Domaininhaber im Wech- sel mit der Zertifizierungsstelle (beispielsweise VeriSign oder TC TrustCenter) eingeblendet werden. Zudem wird je nach verwendetem Browser die Adresszeile oder ein Teil davon grün eingefärbt. Internetnutzer sollen so noch schnel- ler erkennen können, ob die besuchte Website echt ist und sich so besser vor Phishingversuchen schützen. 2.2.1 Browserunterstützung ab Firefox 3 Die erweiterten Funktionen der EV-SSL-Zertifikate werden von Firefox ab Version 3 standardmäßig unterstützt. Der linke Teil der Adressleiste wird grün eingefärbt. Google Chrome EV-SSL-Zertifikate werden standardmäßig unterstützt. Der linke Teil der Adressleiste wird grün eingefärbt und der Organisationsname wird in grün neben einem Schloss-Symbol dargestellt. ab Internet Explorer 7 EV-SSL-Zertifikate werden standardmäßig unterstützt. Die gesamte Adressleiste wird grün eingefärbt. Ein Benutzer mit Administratorrechten kann den Internet Explorer so konfigurieren, dass auch andere Zertifikate als EV-SSL-Zertifikate angezeigt werden.[4] ab Opera 9.5 EV-SSL-Zertifikate werden standardmäßig unterstützt. Der rechte Teil der Adressleiste wird grün eingefärbt und das Schloss-Symbol hat zusätzlich ein Häkchen. ab Safari 3.2 EV-SSL-Zertifikate werden standardmäßig unterstützt. Der Organisationsname wird in grün neben dem Schloss-Symbol angezeigt.[5] 2.3 Vergabekriterien Um EV-SSL-Zertifikate ausstellen zu dürfen, müssen sich die Zertifizierungsstellen selbst einer Überprüfung unter- ziehen. Die Vergabe der Zertifikate ist unter anderem an folgende Kriterien gebunden: • Feststellung der Identität und der Geschäftsadresse des Antragstellers • Sicherstellung, dass der Antragsteller ausschließlicher Eigentümer der Domain ist oder eine exklusive Nut- zungsberechtigung hat • Sicherstellung, dass die antragstellenden Personen befugt sind und dass rechtlich bindende Dokumente von zeichnungsberechtigten Personen unterschrieben werden Ein EV-Zertifikat kann ausgestellt werden für:
8 KAPITEL 2. EXTENDED-VALIDATION-ZERTIFIKAT • Behörden • Kapitalgesellschaften • Personengesellschaften • eingetragene Vereine • Einzelunternehmer 2.4 Weblinks • cabforum.org – Offizielle Website von CA/Browser Forum • EV SSL Certificate Guidelines Version 1.6.1 – aktuelle Version der Richtlinien (stand 7. Januar 2016) • Erweitertes SSL-Verfahren in den Startlöchern, heise.de • Mit EV-SSL-Zertifikaten gegen das Handtaschen-Missverständnis 2.5 Einzelnachweise [1] Guidelines for Extended Validation Certificates 1.0 [2] „Software to Spot ‚Phishers‘ Irks Small Concerns“, Wall Street Journal, 19. Dezember 2006 [3] Version 1.1 der Guidelines for Extended Validation Certificates [4] „Extended Validation support for websites using internal certificates“, 14. August 2009 [5] „Safari 3.2 mit Phishing-Schutz“, fscklog.com, 13. November 2008
Kapitel 3 X.509 X.509 ist ein ITU-T-Standard für eine Public-Key-Infrastruktur zum Erstellen digitaler Zertifikate. Der Standard ist auch als ISO/IEC 9594-8 zuletzt im Oktober 2016 aktualisiert worden. Der Standard spezifiziert die folgenden Datentypen: Public-Key-Zertifikat, Attributzertifikat, Certificate Revocation List (CRL) und Attribute Certificate Revocation List (ACRL). In der elektronischen Kommunikation finden X.509-Zertifikate Anwendung bei den TLS- Versionen diverser Übertragungsprotokolle, wie z. B. beim Abruf von Web-Seiten mit dem HTTPS-Protokoll, oder zum Unterschreiben und Verschlüsseln von E-Mails nach dem S/MIME-Standard. 3.1 Geschichte X.509 wurde erstmals 1988 veröffentlicht. Die Entwicklung von X.509 begann in Verbindung mit dem X.500- Standard, der nie vollständig implementiert wurde. X.509 setzt ein strikt hierarchisches System von vertrauenswür- digen Zertifizierungsstellen (englisch certificate authority, CA) voraus, die Zertifikate erteilen können. Dieses Prinzip steht im Gegensatz zum Web-of-Trust-Modell, welches einen Graphen und nicht nur einen Baum darstellt und bei dem jeder ein Zertifikat „unterschreiben“ und damit seine Echtheit beglaubigen kann (siehe z. B. OpenPGP). Version 3 von X.509 (X.509v3) beinhaltet die Flexibilität, mit Profilen erweitert zu werden. Die IETF entwickelte das wichtigste Profil, PKIX Certificate and CRL Profile, kurz „PKIX“, im Rahmen des RFC 3280, aktuell RFC 5280. Der Begriff „X.509-Zertifikat“ bezieht sich meist darauf. 3.2 Zertifikate Ein von einer Zertifizierungsstelle ausgestelltes digitales Zertifikat wird im X.509-System immer an einen „Distingu- ished Name“ oder einen „Alternative Name“ wie eine E-Mail-Adresse oder einen DNS-Eintrag gebunden. Nahezu alle Webbrowser enthalten eine vorkonfigurierte Liste vertrauenswürdiger Zertifizierungsstellen, deren X.509- Zertifikaten der Browser vertraut. Umgangssprachlich wird häufig von SSL-Zertifikaten gesprochen. X.509 beinhaltet außerdem einen Standard, mittels dessen Zertifikate seitens der Zertifizierungsstelle wieder ungültig gemacht werden können, wenn deren Sicherheit nicht mehr gegeben ist (z. B. nach dem öffentlichen Bekanntwerden des privaten Schlüssels für das Signieren von E-Mails). Die Zertifizierungsstelle kann hierfür ungültige Zertifikate in Zertifikatsperrlisten (certificate revocation list, kurz CRL) führen. Die automatische Überprüfung, ob ein Zertifi- kat inzwischen Teil einer Sperrliste ist, ist allerdings nicht in allen Programmen, die X.509-Zertifikate akzeptieren, standardmäßig aktiviert. 3.2.1 Struktur eines X.509-v3-Zertifikats • Zertifikat • Version • Seriennummer 9
10 KAPITEL 3. X.509 • Algorithmen-ID • Aussteller • Gültigkeit • von • bis • Zertifikatinhaber • Zertifikatinhaber-Schlüsselinformationen • Public-Key-Algorithmus • Public Key des Zertifikatinhabers • Eindeutige ID des Ausstellers (optional) • Eindeutige ID des Inhabers (optional) • Erweiterungen • … • Zertifikat-Signaturalgorithmus • Zertifikat-Signatur Aussteller und Zertifikatinhaber werden jeweils durch eine Reihe von Attributen charakterisiert: • Gebräuchlicher Name (CN) • Organisation (O) • Organisationseinheit (OU) • Land/Region (C) • Bundesland/Kanton (ST) • Ort (L) Aussteller- und Inhaber-ID wurden in Version 2 eingeführt, Erweiterungen in Version 3. 3.2.2 Erweiterungen Erweiterungen oder Extensions sind inzwischen ein sehr wichtiger Bestandteil eines Zertifikates geworden. Erweite- rungen haben die folgende Unterstruktur: • Erweiterungs-ID • Flag (kritisch/unkritisch) • Wert Jede Erweiterung hat eine spezifische ID. Die Flags dienen der schrittweisen Einführung einer neuen Erweiterung. So sind neue Erweiterungen zu Beginn als unkritisch markiert. Eine Implementierung, die auf eine unbekannte unkri- tische Erweiterung trifft, kann diese ignorieren. Wird eine Erweiterung mit der Zeit allerdings nach ausreichendem Testen auf kritisch gesetzt, so muss ein Zertifikat mit unbekannter kritischer Erweiterung als ungültig erachtet wer- den. Beispiele für Erweiterungen sind • KeyUsage: Gibt an, für welche Anwendung dieses Zertifikat ausgestellt wurde. Ein CA-Zertifikat muss hier bspw. keyCertSign und CRLsign eingetragen haben. • BasicConstraints: Transitivitätsvertrauen ist ohne diese Erweiterung unmöglich. BasicConstraints sind: • CA: Gibt an, ob das Zertifikat zu einer Zertifizierungsstelle gehört. In einer Zertifikatskette muss jedes Zertifikat, außer dem der letzten Instanz (des Users/Servers), als CA markiert sein. • PathLen: Gibt an, wie lang die Zertifikatskette maximal sein darf.
3.3. BEISPIEL FÜR EIN X.509-ZERTIFIKAT 11 3.2.3 Dateinamenserweiterungen für Zertifikate Übliche Dateinamenserweiterungen für X.509-Zertifikate sind: • .CER – DER- oder Base64-kodiertes Zertifikat • .CRT – DER- oder Base64-kodiertes Zertifikat • .CSR – Base64-kodierte Zertifizierungsanfrage des öffentlichen Schlüssels (plus weitere Metadaten des Besit- zers) an eine CA, umschlossen von „-----BEGIN CERTIFICATE REQUEST-----“ und „-----END CERTIFI- CATE REQUEST-----“ • .DER – DER-kodiertes Zertifikat • .P12 – PKCS#12, kann öffentliche Zertifikate und private Schlüssel (Kennwort-geschützt) enthalten. • .P7B – Siehe .p7c • .P7C – PKCS#7-signierte Datenstruktur ohne Dateninhalt, nur mit Zertifikat(en) oder Zertifikatsperrliste(n) • .PEM – Base64-kodiertes Zertifikat, umschlossen von „-----BEGIN CERTIFICATE-----“ und „-----END CERTIFICATE- ----“ • .PFX – Siehe .p12 PKCS #7 ist ein Standard zum Signieren und Verschlüsseln von Daten. Da das Zertifikat gebraucht wird, um die signierten Daten zu verifizieren, kann es in der „SignedData“-Struktur untergebracht werden. Eine .p7c-Datei ist der Spezialfall einer Datei, die keine Daten zum Signieren enthält, sondern nur die „SignedData“-Struktur. PKCS #12 entwickelte sich aus dem PFX(Personal inFormation eXchange)-Standard und wird benutzt, um öffentliche und private Schlüssel in einer gemeinsamen Datei auszutauschen. Eine .PEM-Datei kann Zertifikate und/oder private Schlüssel enthalten, die von entsprechenden BEGIN/END-Zeilen umschlossen sind. 3.3 Beispiel für ein X.509-Zertifikat Text-Darstellung eines nach X.509v3 (Version 3) aufgebauten digitalen Zertifikats. (Die Struktur basiert auf ASN.1.): Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: C=AT, ST=Steiermark, L=Graz, O=TrustMe Ltd, OU=Certificate Authority, CN=CA/Email=ca@trustme.dom Va- lidity Not Before: Oct 29 17:39:10 2000 GMT Not After : Oct 29 17:39:10 2001 GMT Subject: C=AT, ST=Vienna, L=Vienna, O=Home, OU=Web Lab, CN=anywhere.com/Email=xyz@anywhere.com Subject Public Key Info: Pu- blic Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c4:40:4c:6e:14:1b:61:36:84: 24:b2:61:c0:b5: d7:e4:7a:a5:4b:94:ef:d9:5e:43:7f:c1:64:80:fd: 9f:50:41:6b:70:73:80:48:90:f3:58:bf:f0:4c:b9: 90:32:81:59:18:16:3f:19: 5f:11:68:36:85:f6: 1c:a9:af:fa:a9:a8:7b:44:85:79:b5:f1:20:d3:25: 7d:1c:de:68:15:0c:b6:bc:59:46:0a:d8:99:4e:07: 50:0a:5d:83:61:d4: db:c9:7d:c3:2e:eb:0a:8f:62: 8f:7e:00:e1:37:67:3f:36:d5:04:38:44:44:77:e9: f0:b4:95:f5:f9:34:9f:f8:43 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: email:xyz@anywhere.com Netscape Comment: mod_ssl generated test server certificate Netscape Cert Type: SSL Server Signature Algorithm: md5WithRSAEncryption 12:ed:f7:b3:5e:a0:93:3f:a0:1d:60:cb:47:19:7d:15:59:9b: 3b:2c:a8:a3:6a:03:43:d0:85:d3:86:86:2f:e3:aa:79:39:e7: 82:20:ed: f4:11:85:a3:41:5e:5c:8d:36:a2:71:b6:6a:08:f9: cc:1e:da:c4:78:05:75:8f:9b:10:f0:15:f0:9e:67:a0:4e:a1: 4d:3f:16:4c:9b:19:56:6a:f2: af:89:54:52:4a:06:34:42:0d: d5:40:25:6b:b0:c0:a2:03:18:cd:d1:07:20:b6:e5:c5:1e:21: 44:e7:c5:09:d2:d5:94:9d:6c:13: 07:2f:3b:7c:4c:64:90:bf: ff:8e 3.4 Literatur • X.509 Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks
12 KAPITEL 3. X.509 3.5 Weblinks • RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Obsolet durch RFC 3280) • RFC 3280 (Internet X.509 Public Key Infrastructure, Certificate and CRL Profile, Update RFC 4325, Update RFC 4630, Obsolet durch RFC 5280) • RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile)
Kapitel 4 Transport Layer Security Transport Layer Security (TLS, deutsch Transportschichtsicherheit), weitläufiger bekannt unter der Vorgängerbe- zeichnung Secure Sockets Layer (SSL), ist ein hybrides Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. Die letzte Version des SSL-Protokolls war 3.0 und danach wurde es unter dem neuen Namen TLS, beginnend mit Version 1.0, weiterentwickelt und standardisiert. (Zwar werden protokollintern die Werte 3 und 1 verwendet, um TLS 1.0 zu repräsentieren, offiziell gibt es aber kein SSL 3.1.) In diesem Artikel wird die Abkür- zung TLS für beide Bezeichnungen verwendet, sofern nicht explizit auf die alten Versionen Bezug genommen wird. Bekannte Implementierungen des Protokolls sind OpenSSL, LibreSSL und GnuTLS. 4.1 TLS in der Praxis TLS-Verschlüsselung wird heute vor allem mit HTTPS eingesetzt. Die meisten Webserver unterstützen TLS 1.0, viele auch SSLv2 und SSLv3 mit einer Vielzahl von Verschlüsselungsmethoden, fast alle Browser und Server setzen jedoch bevorzugt TLS mit RSA- und AES- oder Camellia-Verschlüsselung ein. In aktuellen Browsern ist SSLv2 deaktiviert oder führt zu einer Sicherheitswarnung,[1] da diese Protokollversion eine Reihe von Sicherheitslücken[2][3] aufweist. Seit dem Bekanntwerden des Poodle-Angriffs auf die Verschlüsselung mit SSL gilt dies bei vielen Servern und Browsern auch für SSLv3. Die Weiterentwicklung TLS 1.1 wird von Google Chrome unterstützt, TLS 1.2 wird in der Standardkonfiguration von Internet Explorer, Firefox, Google Chrome, Opera und Apple iOS Safari verwendet (Stand 02/2014).[4] Seit einiger Zeit nutzen immer mehr Webseitenbetreiber Extended-Validation-TLS-Zertifikate (EV-TLS-Zertifikat). In der Adresszeile des Browsers wird zusätzlich ein Feld angezeigt, in dem Zertifikats- und Domaininhaber im Wech- sel mit der Zertifizierungsstelle eingeblendet werden. Zudem wird je nach verwendetem Browser und/oder Add-on die Adresszeile (teilweise) grün eingefärbt. Internetnutzer sollen so noch schneller erkennen, ob die besuchte Web- seite echt ist, und besser vor Phishingversuchen geschützt werden. EV-TLS-Zertifikate bieten in technischer Sicht keinen erweiterten Schutz, die Verschlüsselung und deren Stärke ist identisch. Nur der Inhaber wird dabei besser und aufwändiger verifiziert. Deshalb benutzt Google generell keine EV-Zertifikate.[5] Seit Januar 2017 markiert der Web-Browser Chrome Internetseiten als unsicher, die Informationen sammeln, ohne dabei HTTPS zu nutzen. Dies wird voraussichtlich zu einem signifikanten Anstieg des Einsatzes von HTTPS führen. Im Februar 2017 war HTTPS bei 2,57 % aller registrierten deutschen Internet-Domains[6] , sowie bei 3,70 % der österreichischen Domains[7] und 9,71 % der Schweizer Domains[8] aktiviert. Eine Untersuchung von rund 40.000 Webseiten klein- und mittelständischer Unternehmen in Baden-Württemberg durch den Landesbeauftragten für den Datenschutz und die Informationsfreiheit Baden-Württemberg hat ergeben, dass rund 7 % der untersuchten Websei- ten über HTTPS angeboten werden. Bei jenen Webseiten, die über HTTPS angeboten werden, ist die serverseitige Unterstützung für TLS 1.0 noch sehr weit verbreitet (99 %).[9] TLS ist ohne eine zertifikatsbasierte Authentifizierung anfällig für Man-in-the-Middle-Angriffe: Ist der Man-in-the- Middle vor der Übergabe des Schlüssels aktiv, kann er beiden Seiten seine Schlüssel vorgaukeln und so den gesamten Datenverkehr im Klartext aufzeichnen und unbemerkt manipulieren. Wegen der mangelnden Vertrauenswürdigkeit einiger Zertifizierungsstellen wird seit Anfang 2010 die Sicherheit von TLS grundsätzlich angezweifelt.[10][11][12][13] Durch die Deaktivierung fragwürdiger Zertifizierungsstellen im eigenen Browser lässt sich dieses Risiko jedoch weit- gehend beseitigen. 13
14 KAPITEL 4. TRANSPORT LAYER SECURITY In Verbindung mit einem virtuellen Server, zum Beispiel mit HTTP (etwa beim Apache HTTP Server über den VHost- Mechanismus), ist es grundsätzlich als Nachteil zu werten, dass pro Kombination aus IP-Adresse und Port nur ein Zertifikat verwendet werden kann, da die eigentlichen Nutzdaten des darüber liegenden Protokolls (und damit der Name des VHosts) zum Zeitpunkt des TLS-Handshakes noch nicht übertragen wurden. Dieses Problem wurde mit der TLS-Erweiterung Server Name Indication (SNI) im Juni 2003 durch die RFC 3546 behoben. Dabei wird bereits beim Verbindungsaufbau der gewünschte Servername mitgesendet. Die ursprüngliche Erweiterung wurde für TLS 1.0 beschrieben, aufgrund der Kompatibilität der einzelnen TLS-Versionen zueinander wird SNI auch bei TLS 1.1 und TLS 1.2 entsprechend der Empfehlung umgesetzt. Neben HTTPS als verschlüsselte Variante von HTTP sind weitere bekannte Anwendungsfälle für TLS beispielsweise: • POP3S für POP3 • SMTPS für SMTP • NNTPS für NNTP • SIPS für SIP • IMAPS für IMAP • XMPPS für XMPP • IRCS für IRC • LDAPS für LDAP • MBS/IP-TLS • FTPS für FTP • EAP-TLS • TN3270-TLS • OpenVPN 4.1.1 Versionen 4.2 Geschichte • 1994, neun Monate nach der ersten Ausgabe von Mosaic, dem ersten verbreiteten Webbrowser, stellte Netscape Communications die erste Version von SSL (1.0) fertig. • Fünf Monate später wurde zusammen mit einer neuen Ausgabe des Netscape Navigator die nächste Version SSL 2.0 veröffentlicht. • Ende 1995 veröffentlichte Microsoft die erste Version seines Webbrowsers Internet Explorer. Kurz darauf wurde auch die erste Version ihres SSL-Pendants bekannt, PCT 1.0 (Private Communication Technology). PCT hatte einige Vorteile gegenüber SSL 2.0, die später in SSL 3.0 aufgenommen wurden. • Als SSL von der IETF im RFC 2246 als Standard festgelegt wurde, benannte man es im Januar 1999 um zu Transport Layer Security (TLS). Die Unterschiede zwischen SSL 3.0 und TLS 1.0 sind nur gering. Doch entstanden durch die Umbenennung Versionsverwirrungen. So meldet sich TLS 1.0 im Header als Version SSL 3.1. • Später wurde TLS durch weitere RFCs erweitert: • RFC 2712 – Addition of Kerberos Cipher Suites to Transport Layer Security (TLS). • RFC 2817 – Upgrading to TLS Within HTTP/1.1 erläutert die Benutzung des Upgrade-Mechanismus in HTTP/1.1, um Transport Layer Security (TLS) über eine bestehende TCP-Verbindung zu initialisieren. Dies erlaubt es, für unsicheren und für sicheren HTTP-Verkehr die gleichen „well-known“ TCP Ports (80 bzw. 443) zu benutzen.
4.3. FUNKTIONSWEISE 15 • RFC 2818 – HTTP Over TLS trennt sicheren von unsicherem Verkehr durch Benutzung eines eigenen Server-TCP-Ports. • RFC 3268 – Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) nutzt die Erweiterbarkeit von TLS und fügt den bisher unterstützten symmetrischen Verschlüsselungs- algorithmen (RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES) und Triple DES) den Advanced Encryption Standard (AES) hinzu. • RFC 3546 – Transport Layer Security (TLS) Extensions führt das Konzept der Erweiterungen ein, durch welches optionale Datenfelder oder Header vor allem bei der anfänglichen Aushandlung übertragen wer- den können. Eine der wohl bekanntesten Erweiterungen ist Server Name Indication. • Im April 2006 wurde in RFC 4346 die Version 1.1 von TLS standardisiert und damit RFC 2246 obsolet. In TLS 1.1 wurden kleinere Sicherheitsverbesserungen vorgenommen und Unklarheiten beseitigt. • Im August 2008 erschien mit RFC 5246 die Version 1.2 von TLS, welche somit RFC 4346 obsolet machte. Als wesentliche Änderung wurde die Festlegung auf MD5/SHA-1 in der Pseudozufallsfunktion (PRF) und bei signierten Elementen fallen gelassen. Stattdessen wurden flexiblere Lösungen gewählt, bei denen die Hash- Algorithmen spezifiziert werden können. • Für die Version 1.3 liegt seit Januar 2015 ein Entwurf vor[veraltet] .[15] • Im Februar 2015 wurde RFC 7465[16] veröffentlicht, das RC4 für Verschlüsselung verbietet.[17] • Im Mai 2015 wurden mit RFC 7525,[18] basierend auf dem aktuellen Stand der Technik, Empfehlungen für den sicheren Einsatz von TLS und DTLS veröffentlicht. Diese spezifizieren, dass unter anderem SSLv2, SSLv3, RC4 und sonstige aufgrund von Exportbeschränkungen auf weniger als 112 Bit Schlüssellänge beschränk- te Verschlüsselungsalgorithmen nicht verwendet werden dürfen. Vom Einsatz von 3DES zur Verschlüsselung und RSA zum Schlüsselaustausch mit statischen Parametern wird abgeraten. Konkret zum Einsatz empfohlen werden Cipher Suites, die zum Schlüsselaustausch Ephemeral Diffie-Hellman in Kombination mit RSA ver- wenden, was Forward Secrecy bietet, zur Verschlüsselung AES im Galois/Counter Mode mit 128 oder 256 Bit Schlüssellänge sowie die Hashfunktion SHA-256 oder SHA-384 für die Pseudozufallsfunktion von TLS.[19] 4.3 Funktionsweise Der Client baut eine Verbindung zum Server auf. Der Server authentifiziert sich gegenüber dem Client mit einem Zertifikat. Der Client überprüft hierbei die Vertrauenswürdigkeit des X.509-Zertifikats und ob der Servername mit dem Zertifikat übereinstimmt. Optional kann sich der Client mit einem eigenen Zertifikat auch gegenüber dem Server authentifizieren. Dann schickt entweder der Client dem Server eine mit dem öffentlichen Schlüssel des Servers ver- schlüsselte geheime Zufallszahl, oder die beiden Parteien berechnen mit dem Diffie-Hellman-Schlüsselaustausch ein gemeinsames Geheimnis. Aus dem Geheimnis wird dann ein kryptographischer Schlüssel abgeleitet. Dieser Schlüssel wird in der Folge benutzt, um alle Nachrichten der Verbindung mit einem symmetrischen Verschlüsselungsverfahren zu verschlüsseln und zum Schutz von Nachrichten-Integrität und Authentizität durch einen Message Authentication Code abzusichern. 4.3.1 TLS-Protokolle im Protokollstapel Im OSI-Modell ist TLS in Schicht 5 (der Sitzungsschicht) angeordnet. Im TCP/IP-Modell ist TLS oberhalb der Transportschicht (zum Beispiel TCP) und unterhalb Anwendungsprotokollen wie HTTP oder SMTP angesiedelt. In den Spezifikationen wird dies dann zum Beispiel als „HTTP over TLS“ bezeichnet. Sollen jedoch beide Protokolle zusammengefasst betrachtet werden, wird üblicherweise ein „S“ für Secure dem Protokoll der Anwendungsschicht angehängt (zum Beispiel HTTPS). TLS arbeitet transparent, so dass es leicht eingesetzt werden kann, um Protokollen ohne eigene Sicherheitsmechanismen abgesicherte Verbindungen zur Verfügung zu stellen. Zudem ist es erweiterbar, um Flexibilität und Zukunftssicherheit bei den verwendeten Verschlüsselungstechniken zu gewährleisten. Das TLS-Protokoll besteht aus zwei Schichten:
16 KAPITEL 4. TRANSPORT LAYER SECURITY 4.3.2 TLS Record Protocol Das TLS Record Protocol ist die untere der beiden Schichten und dient zur Absicherung der Verbindung. Es setzt direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste, die einzeln oder gemeinsam genutzt werden können: • Ende-zu-Ende-Verschlüsselung mittels symmetrischer Algorithmen. Der verwendete Schlüssel wird dabei im Voraus über ein weiteres Protokoll (zum Beispiel das TLS Handshake Protocol) ausgehandelt und kann nur einmal für die jeweilige Verbindung verwendet werden. TLS unterstützt für die symmetrische Verschlüsselung unter anderem DES, Triple DES und AES • Sicherung der Nachrichten-Integrität und Authentizität durch einen Message Authentication Code, in der Regel HMAC. Außerdem werden zu sichernde Daten in Blöcke von maximal 16.384 (214 ) Byte fragmentiert und beim Empfän- ger wieder zusammengesetzt. Dabei schreibt der Standard vor, dass die Blockgröße diesen Wert nicht übersteigt, außer der Block ist komprimiert oder verschlüsselt – dann darf die Blockgröße um 1024 Byte (bei Kompression) bzw. 2048 Byte (bei Verschlüsselung) größer sein. Auch können die Daten vor dem Verschlüsseln und vor dem Be- rechnen der kryptografischen Prüfsumme komprimiert werden. Das Komprimierungsverfahren wird ebenso wie die kryptografischen Schlüssel mit dem TLS Handshake-Protokoll ausgehandelt. Der Aufbau einer TLS-Record-Nachricht lautet wie folgt: Content Type (1 Byte: Change Cipher Spec = 20, Alert = 21, Handshake = 22, Application Data = 23) | Protokollversion Major (1 Byte) | Protokollversion Minor (1 Byte) | Länge (1 Short bzw. zwei Byte) 4.3.3 TLS Handshake Protocol Das TLS Handshake Protocol baut auf dem TLS Record Protocol auf und erfüllt die folgenden Funktionen, noch bevor die ersten Bits des Anwendungsdatenstromes ausgetauscht wurden: • Identifikation und Authentifizierung der Kommunikationspartner auf Basis asymmetrischer Verschlüsselungs- verfahren und Public-Key-Kryptografie. Dieser Schritt ist optional eine Zwei-Wege-Authentifizierung (in die- sem Fall wird manchmal von mutual TLS gesprochen), für gewöhnlich authentifiziert sich aber nur der Server gegenüber dem Client. • Aushandeln zu benutzender kryptografischer Algorithmen und Schlüssel. TLS unterstützt auch eine unver- schlüsselte Übertragung. Der Handshake selbst kann in vier Phasen unterteilt werden: 1. Der Client schickt zum Server ein client_hello, und der Server antwortet dem Client mit einem server_hello. Die Parameter der Nachrichten sind: • die Version (die höchste vom Client unterstützte TLS-Protokoll-Version) • eine 32 Byte Zufallsinformation (4 Byte Timestamp + 28 Byte lange Zufallszahl), die später verwendet wird, um das pre-master-secret zu bilden (sie schützt damit vor Replay-Attacken) • eine Session-ID • die zu verwendende Cipher Suite (Algorithmen für Schlüsselaustausch, Verschlüsselung und Authentifi- zierung) • Optional den gewünschten FQDN für die Unterstützung von Server Name Indication 2. Der Server identifiziert sich gegenüber dem Client. Hier wird auch das X.509v3-Zertifikat zum Client über- mittelt. Außerdem kann der Server einen CertificateRequest an den Client schicken. Diese Phase darf nur bei anonymem Key Agreement weggelassen werden. 3. Hier identifiziert sich der Client gegenüber dem Server. Besitzt der Client kein Zertifikat, antwortete er früher mit einem NoCertificateAlert. TLS-konforme Systeme verwenden diesen Alert jedoch nicht. Der Client versucht außerdem, das Zertifikat, das er vom Server erhalten hat, zu verifizieren (bei Misserfolg wird die Verbindung
4.3. FUNKTIONSWEISE 17 public key client public key server private key client Client Server private key server generate random number RNc RNc client_hello (crypto information, RNc ) RNc Phase 1 generate random number RNs RNc RNs RNs RNc server_hello (crypto information, RNs ) server certificate (incl. ) demand client certificate Phase 2 check server certificate RNs RNc client certificate (incl. ) check client certificate hash over all previous messages (signed with ) check hash and signature Phase 3 RNc RNs generate random number pre-master-secret PMS PMS RNs RNc PMS encrypted with RNc RNs PMS calculate Master-Secret from PMS RNs RNc MS MS change to encrypted connection with MS as key end SSL handshake change to encrypted connection with MS as key Phase 4 end SSL handshake TLS-Handshake mit Zwei-Wege-Authentifizierung mittels Zertifikaten abgebrochen). Dieses Zertifikat enthält den öffentlichen Schlüssel des Servers. Wird die Cipher-Suite RSA verwendet, so wird das vom Client generierte pre-master-secret mit diesem öffentlichen Schlüssel verschlüsselt und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden. Alternativ kann hier auch das Diffie-Hellman-Verfahren verwendet werden, um ein gemeinsames pre-master-secret zu generieren. Werden die Diffie-Hellman Geheimnisse von Server und Client während des Handshakes frisch und zufällig gewählt, sind die Voraussetzungen für Perfect Forward Secrecy erfüllt. Diese Phase ist optional. 4. Diese Phase schließt den Handshake ab. Aus dem vorhandenen pre-master-secret kann das Master Secret ab- geleitet werden und aus diesem der einmalige Sitzungsschlüssel (englisch „session key“). Das ist ein einmalig benutzbarer symmetrischer Schlüssel, der während der Verbindung zum Ver- und Entschlüsseln der Daten ge- nutzt wird. Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch verschlüsselt übertragen. 4.3.4 TLS Change Cipher Spec Protocol Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht. Diese Nachricht ist ein Byte groß und besitzt den Inhalt 1. Durch diese Nachricht teilt der Sender dem Empfänger mit, dass er in der aktiven Sitzung auf die im Handshake Protocol ausgehandelte Cipher Suite wechselt. Ein wesentlicher Grund für die Definition eines eigenen Protokolls für diese Nachricht besteht darin, dass TLS-Implementierungen mehrere Nachrichten eines Protokolls in einem Record (also einer TLS-Dateneinheit) zusammenfassen können. Für die Nachricht „Change Cipher Spec“ ist das unerwünscht. Weil Records verschiedener Protokolle nicht zusammengefasst werden dürfen, ist das Problem durch Definition eines eigenen Protokolls gelöst.[20]
18 KAPITEL 4. TRANSPORT LAYER SECURITY 4.3.5 TLS Alert Protocol Das Alert Protocol unterscheidet etwa zwei Dutzend verschiedene Mitteilungen. Eine davon teilt das Ende der Sitzung mit (close_notify). Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten Zertifikate. Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden. Der Aufbau einer Fehlermeldung lautet wie folgt: AlertLevel (1 Byte: Warning = 1, Fatal = 2) | AlertDescription (1 Byte: close_notify = 0, […], no_renegotiation = 100). In der Spezifikation von TLS werden die folgenden schweren Fehlertypen definiert: In der Spezifikation von TLS werden die folgenden Warnungen definiert: In der Spezifikation von TLS 1.0 wurden folgende Warnungen ergänzt:[21] 4.3.6 TLS Application Data Protocol Die Anwendungsdaten werden über das Record Protocol transportiert, in Teile zerlegt, komprimiert und in Abhän- gigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt. Inhaltlich werden sie von TLS nicht näher interpretiert. 4.3.7 Berechnung des Master Secrets Aus dem pre-master-secret wird in früheren Protokollversionen mit Hilfe der Hashfunktionen SHA-1 und MD5, in TLS 1.2 mit Hilfe einer durch eine Cipher Suite spezifizierten Pseudozufallsfunktion das Master Secret berechnet. In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein. Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das Master Secret immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt. In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt. 4.4 Sicherheit Auf SSL und TLS ist eine Reihe von Angriffen bekannt, die die Sicherheitsgarantien untergraben.[22] Die folgende Liste stellt einen Teil der bekannten Angriffe dar. 4.4.1 Padding-Oracle-Angriffe Der Kryptologe Serge Vaudenay entdeckte 2002, dass ein Man-in-the-Middle-Angreifer aus dem Padding einer mit dem Cipher Block Chaining Mode (CBC) verschlüsselten Nachricht Informationen erhalten kann, die zur Entschlüs- selung der Nachricht genutzt werden können. Durch gezielte Manipulation einer verschlüsselten Nachricht lernt der Angreifer, ob der Server ein gültiges Padding meldet und damit ein Teil des Klartexts richtig erraten wurde.[23] Als Schutzmaßnahme sollte der Server ungültige Nachrichten verwerfen, ohne dabei zu offenbaren, ob das Padding oder die Nachrichtenauthentizität ungültig war. Allerdings kann ein Angreifer diese Information auch durch eine Analyse der Antwortzeiten herleiten (Timing-Angriff). Betroffen sind SSL, TLS bis Version 1.2 und DTLS, sofern eine Cipher Suite mit CBC verwendet wird. Cipher Suites mit Authenticated Encryption sind nicht betroffen.[24] Im Oktober 2014 demonstrierten Sicherheitsforscher den POODLE-Angriff (Padding Oracle On Downgraded Lega- cy Encryption), mit dem ein Angreifer ein Versions-Downgrade einer TLS-Verbindung erzwingt, um einen Padding- Oracle-Angriff gegen SSL 3.0 durchzuführen. Zwecks Kompatibilität wurde SSL 3.0 trotz zu dem Zeitpunkt be- kannter Sicherheitsschwächen noch von Webbrowsern und anderen Implementierungen unterstützt. Im Nachgang hat die Internet Engineering Task Force SSL 3.0 als überholt gekennzeichnet[25] und ein Verfahren zum Schutz vor Downgrade-Angriffen auf TLS spezifiziert.[26] 4.4.2 BEAST SSL 3.0 und TLS 1.0 verwenden im CBC-Modus einen vorhersagbaren Initialisierungsvektor. Ein Angreifer kann dadurch mit einem Chosen-Plaintext-Angriff unbekannte Teile des Klartexts ermitteln. Ein Angriffsszenario ist das Stehlen von HTTP-Cookies, die verschlüsselt übertragen werden. Hierzu muss der Angreifer das Angriffsopfer auf
Sie können auch lesen