Let's Encrypt

Let’s Encrypt Die neue Sicherheit für Jeden 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-Zertiﬁkat 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-Angriﬀe ...... 18 4.4.2 BEAST ...... 18 4.4.3 Kompressionsangriﬀe ...... 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 Zertiﬁzierungsstelle 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 werden.

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 verschiedene 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 vorgesehen. 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 Zertiﬁzierungsstelle 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 zugegriﬀen 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 Zertiﬁkat 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 ausgestellt. 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

• oﬃzielle 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 Eﬀort 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 Certiﬁcate Authority to Encrypt the Entire Web. In: eﬀ.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 ﬁrst certiﬁcate

[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-Zertiﬁzierungsstelle Lets Encrypt will Mitte September 2015 öﬀnen

[13] Reiko Kaps (heise.de), 5. Juni 2015: Let’s Encrypt: Meilenstein zu kostenlosen SSL-Zertiﬁkaten für alle

[14] Chris Brook (Threatpost), 18. November 2014: EFF, Others Plan to Make Encrypting the Web Easier in 2015

[15] Draft ACME speciﬁcation.

[16] R. Barnes, P. Eckersley, S. Schoen, A. Halderman, J. Kasten: Automatic Certiﬁcate 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 Certiﬁcates. 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 certiﬁcates

[22] ITP: letsencrypt – Let’s Encrypt client that can update Apache conﬁgurations 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 Certiﬁcate 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 Zertiﬁkate ausgestellt. In: heise online. Abgerufen am 9. März 2016 (deutsch).

[32] Dennis Schirrmacher (heise online), 23. Juni 2016: Fünf Millionen Zertiﬁkate: 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-Zertiﬁkat

Ein Extended-Validation-Zertiﬁkat 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 sicheren 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 Zertiﬁkats- und Domaininhaber im Wech- sel mit der Zertiﬁzierungsstelle (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 schneller 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-Zertiﬁkate 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-Zertiﬁkat kann ausgestellt werden für: 8 KAPITEL 2. EXTENDED-VALIDATION-ZERTIFIKAT

• Behörden

• Kapitalgesellschaften • Personengesellschaften

• eingetragene Vereine • Einzelunternehmer

2.4 Weblinks

• cabforum.org – Oﬃzielle Website von CA/Browser Forum

• EV SSL Certiﬁcate 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-Zertiﬁkaten gegen das Handtaschen-Missverständnis

2.5 Einzelnachweise

[1] Guidelines for Extended Validation Certiﬁcates 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 Certiﬁcates

[4] „Extended Validation support for websites using internal certiﬁcates“, 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 Zertiﬁkate

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-Zertiﬁkats

• Zertiﬁkat

• 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 Zertiﬁkatinhaber 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 Zertiﬁkates 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 werden. 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 Zertiﬁkate

Übliche Dateinamenserweiterungen für X.509-Zertiﬁkate sind:

• .CER – DER- oder Base64-kodiertes Zertiﬁkat

• .CRT – DER- oder Base64-kodiertes Zertiﬁkat

• .CSR – Base64-kodierte Zertiﬁzierungsanfrage des öﬀentlichen Schlüssels (plus weitere Metadaten des Besit- zers) an eine CA, umschlossen von „-----BEGIN CERTIFICATE REQUEST-----“ und „-----END CERTIFI- CATE REQUEST-----“

• .DER – DER-kodiertes Zertiﬁkat

• .P12 – PKCS#12, kann öﬀentliche Zertiﬁkate und private Schlüssel (Kennwort-geschützt) enthalten.

• .P7B – Siehe .p7c

• .P7C – PKCS#7-signierte Datenstruktur ohne Dateninhalt, nur mit Zertiﬁkat(en) oder Zertiﬁkatsperrliste(n)

• .PEM – Base64-kodiertes Zertiﬁkat, 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-Zertiﬁkat

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 protected] 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 protected] 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:f4: 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:[email protected] 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 certiﬁcate frameworks 12 KAPITEL 3. X.509

3.5 Weblinks

• RFC 2459 (Internet X.509 Public Key Infrastructure Certiﬁcate and CRL Proﬁle, Obsolet durch RFC 3280)

• RFC 3280 (Internet X.509 Public Key Infrastructure, Certiﬁcate and CRL Proﬁle, 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äuﬁger 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, oﬃziell 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 Zertiﬁkat 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öﬀentlicht. • Ende 1995 veröﬀentlichte 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 werden 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 ﬂexiblere Lösungen gewählt, bei denen die Hash- Algorithmen speziﬁziert 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öﬀentlicht, 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 verwenden, 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 Speziﬁkationen 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 kryptograﬁschen Prüfsumme komprimiert werden. Das Komprimierungsverfahren wird ebenso wie die kryptograﬁschen 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 diesem 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 Server private key client Client private key server

generate random number RNc RNc

client_hello (crypto information, RNc ) RNc Phase 1

generate random number RNs

RNc RNs server_hello (crypto information, RNs ) RNs RNc

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-Authentiﬁzierung mittels Zertiﬁkaten

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 abgeleitet 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 genutzt 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 Deﬁnition 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 Deﬁnition 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 Angriﬀen bekannt, die die Sicherheitsgarantien untergraben.[22] Die folgende Liste stellt einen Teil der bekannten Angriﬀe dar.

4.4.1 Padding-Oracle-Angriﬀe

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 bekannter 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 4.4. SICHERHEIT 19

eine bösartige Website locken, die wiederholt HTTP-Anfragen an eine fremde Domain auslöst, wobei der Web- browser automatisch die für die Domain gesetzten HTTP-Cookies mitsendet. Durch den teilweise selbst gewählten Inhalt der HTTP-Anfragen und durch Abhören der verschlüsselten TLS-Nachrichten kann der Angreifer das Cookie zeichenweise erraten. Die Grundlagen des Angriﬀs wurden 2004 beschrieben[27] und 2011 erstmals in der Praxis unter dem Namen BE- AST (Browser Exploit Against SSL/TLS) demonstriert.[28][29] TLS-Version 1.1 und höher sind nicht betroﬀen, da jede Nachricht mit einem pseudozufälligen Initialisierungsvektor verschlüsselt wird.

4.4.3 Kompressionsangriﬀe

Die Verwendung der optionalen Kompression von Nutzdaten eröffnet eine Klasse von Angriffen, die das Erraten von Teilen des Klartexts ermöglichen. Das Angriffsszenario ist ähnlich wie beim BEAST-Angriff: der Angreifer führt einen Chosen-Plaintext-Angriff durch und beobachtet die verschlüsselten TLS-Nachrichten im Netz. Das Kompres- sionsverfahren entfernt Redundanzen aus den Nutzdaten, sodass der zu verschlüsselnde Klartext und damit auch der Geheimtext kürzer wird. Hat der Angreifer einen Teil des unbekannten Klartexts erraten, zum Beispiel ein Zeichen eines HTTP-Cookies, so erfährt er dies aus dem Längenunterschied einer verschlüsselten TLS-Nachricht. Der Angriff wurde 2012 von den Urhebern des BEAST-Angriffs unter dem Namen CRIME (Compression Ratio Info- leak Made Easy) veröffentlicht.[30] Neben SSL und TLS ist auch das SPDY-Protokoll betroffen. Als Schutzmaßnahme wird von der Verwendung der Kompression abgeraten. TLS ab Version 1.3 unterstützt keine Kompression mehr. Der SPDY-Nachfolger HTTP/2 verwendet ein vereinfachtes Kompressionsformat (HPACK), das weniger effizient komprimiert als Deflate, dafür aber schwerer anzugreifen ist.[31] TIME und BREACH sind verbesserte Varianten des Angriffs. TIME (Timing Info-leak Made Easy) leitet die Größe einer verschlüsselten TLS-Nachricht aus der Antwortzeit her, ohne dass der Netzwerkverkehr abgehört werden muss.[32] Beide Angriffe erlauben das Erraten von TLS-verschlüsselten Inhalten, wenn TLS-Kompression abgeschaltet ist und stattdessen HTTP-Kompression verwendet wird. Da TLS Kompressionsangriffe nicht grundsätzlich verhindern kann, müssen anwendungsspezifische Schutzmaßnahmen verwendet werden, zum Beispiel der vollständige Verzicht auf Kompression.

4.4.4 Downgrade auf Exportverschlüsselung

Als Folge der Exportbeschränkungen von Kryptographie aus den Vereinigten Staaten sind in TLS zahlreiche exporttaugliche Cipher Suites spezifiziert, die kurze Schlüssellängen verwenden. Trotz bekannter Sicherheitsschwächen wurden oder werden diese zum Teil noch von Implementierungen unterstützt. Der TLS-Handshake soll eigentlich verhindern, dass ein Man-in-the-Middle-Angreifer einen Downgrade auf eine nicht angefragte Cipher Suite erzwingen kann, indem die Handshake-Nachrichten authentifiziert werden. Die Sicherheit der Authentifizierung hängt allerdings auch von der ausgehandelten Cipher Suite ab, sodass der Angreifer den Schlüssel brechen kann. Beim 2015 veröffentlichten FREAK-Angriff (Factoring RSA Export Keys) findet ein Downgrade auf RSA-basierte Cipher Suites mit 512-bit langen Exportschlüsseln statt.[33] Der Angriff setzt einen Implementierungsfehler voraus, bei dem der Client den 512-bit Schlüssel anstatt des längeren Schlüssel aus dem Serverzertifikat verwendet. Der Fehler betraf unter anderem OpenSSL und SecureTransport (Apple).[34][35] Kurz darauf veröffentlichte ein Forscherteam den Logjam-Angriff, der einen Downgrade des Diffie-Hellman-Schlüsselaustauschs auf 512-bit Restklassengruppen ermöglicht. Ursache ist die Unterstützung von exporttauglichen Cipher Suites mit Ephemeral Diffie-Hellman.[36] Anders als bei FREAK handelt es sich um eine Protokollschwäche in TLS, die auch ohne Implementierungsfehler ausgenutzt werden kann. Der Logjam-Angriff kann in der Praxis performant durch- geführt werden, da ein Großteil der Rechenarbeit zum Brechen des Schlüssels schon vor dem Verbindungsaufbau durchgeführt werden kann. Der erforderliche Rechenaufwand während des eigentlichen Schlüsselaustauschs dauert etwa 70 Sekunden. Als Schutzmaßnahme sollten Server die Unterstützung für exporttaugliche Cipher Suites abschal- ten und mindestens 2048 Bit lange Gruppen verwenden. Clients sollten Gruppen verwerfen, die kürzer als 1024 Bit sind.[37]

4.4.5 Implementierungsfehler

Neben Sicherheitsschwächen im Protokoll sind TLS-Implementierungen in wiederkehrender Regelmäßigkeit von si- cherheitsrelevanten Implementierungsfehlern betroﬀen. Einer der schwerwiegendsten Fehler war der 2014 entdeckte 20 KAPITEL 4. TRANSPORT LAYER SECURITY

Heartbleed-Bug in OpenSSL.

4.5 Vor- und Nachteile

Der Vorteil des TLS-Protokolls ist die Möglichkeit, jedes höhere Protokoll auf Basis des TLS-Protokolls zu implementieren. Damit ist eine Unabhängigkeit von Anwendungen und Systemen gewährleistet. Der Nachteil der TLS-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite rechenintensiv und deshalb langsamer ist. Die Verschlüsselung selbst beansprucht je nach verwendetem Algorithmus nur wenig Rechenzeit. Verschlüsselte Daten sind auf niedrigeren Schichten (etwa auf PPTP-Ebene) kaum durch Kompression zu verdichten. TLS verschlüsselt nur die Kommunikation zwischen zwei Stationen. Es sind Szenarien in serviceorientierten Archi- tekturen denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird. Wenn jede Station nur einen Teil der Nachricht lesen darf, reicht TLS nicht aus, da jede Station alle Daten der Nachricht entschlüsseln kann. Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann.

4.6 Implementierungen

Zu den bekanntesten Programmbibliotheken, die Transport Layer Security implementieren, gehören:

• OpenSSL

• GnuTLS

• LibreSSL

• Network Security Services

• mbed TLS, vormals PolarSSL

• BoringSSL[38]

• Cryptlib

• SChannel (Microsoft)

• WolfSSL

4.7 Siehe auch

• IPsec

4.8 Literatur

• Eric Rescorla: SSL and TLS. Designing and building secure systems. Addison-Wesley, New York NY u. a. 2001, ISBN 0-201-61598-3.

• Roland Bless u. a.: Sichere Netzwerkkommunikation. Grundlagen, Protokolle und Architekturen. Springer Verlag, Berlin u. a. 2005, ISBN 3-540-21845-9,(X.systems.press).

• Claudia Eckert: IT-Sicherheit. Konzepte – Verfahren – Protokolle. 6. überarbeitete Auﬂage. Oldenbourg, Mün- chen u. a. 2009, ISBN 978-3-486-58999-3. 4.9. WEBLINKS 21

4.9 Weblinks

• TLS-Arbeitsgruppe der IETF

• TLS 1.2 Speziﬁkation (Proposed Standard) der IETF (TLS-Arbeitsgruppe)

• SSL 3.0 Speziﬁkation (Memento vom 8. Februar 2008 im Internet Archive)

• Einführung in SSL von Markus Repges Beschreibt Handshake und Protokoll im Detail

4.10 Einzelnachweise

[1] Firefox kann keine sichere Verbindung aufbauen weil die Website eine ältere unsichere Version des SSL-Protokolls verwendet. Abgerufen am 19. Januar 2016.

[2] SSLv2 insecure – should be disabled by default. Abgerufen am 19. Januar 2016.

[3] On SSL 2 and older protocols. Abgerufen am 19. Januar 2016.

[4] Firefox 27 verschlüsselt mit TLS 1.2. Abgerufen am 19. Januar 2016.

[5] Does Google use extended validation certiﬁcates? In: security.stackexchange.com. Abgerufen am 27. August 2016.

[6] Deutsch Internet Statistiken reﬂecte.de. Abgerufen am 22. Februar 2017 (deutsch).

[7] Österreichisch Internet Statistiken reﬂecte.at. Abgerufen am 22. Februar 2017 (deutsch).

[8] Schweizerisch Internet Statistiken avidom.ch. Abgerufen am 22. Februar 2017 (deutsch).

[9] Ronald Petrlic, Klaus Manny: Wie sicher ist der Zugriﬀ auf Websites im Internet? In: Datenschutz und Datensicherheit - DuD. Band 41, Nr. 2, 3. Februar 2017, ISSN 1614-0702, S. 88–92, doi:10.1007/s11623-017-0734-y.

[10] EFF zweifelt an Abhörsicherheit von SSL. Abgerufen am 19. Januar 2016.

[11] New Research Suggests That Governments May Fake SSL Certiﬁcates. Abgerufen am 19. Januar 2016.

[12] Certiﬁed Lies: Detecting and Defeating Government Interception Attacks Against SSL. Abgerufen am 19. Januar 2016 (PDF, englisch).

[13] Law Enforcement Appliance Subverts SSL. Abgerufen am 19. Januar 2016.

[14] Hanno Böck: Die Zukunft der Netzverschlüsselung, golem.de, 13. Dezember 2016. Abgerufen am 13. Dezember 2016.

[15] The Transport Layer Security (TLS) Protocol Version 1.3. Abgerufen am 19. Januar 2016.

[16] Prohibiting RC4 Cipher Suites. Abgerufen am 20. Februar 2015.

[17] Jürgen Schmidt: IETF verbietet RC4-Verschlüsselung in TLS. Heise Security, 20. Februar 2015, abgerufen am 20. Februar 2015.

[18] Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Ab- gerufen am 10. Mai 2015.

[19] Jürgen Schmidt: IETF speziﬁziert Richtlinien für den Einsatz von Verschlüsselung. Heise Security, 8. Mai 2015, abgerufen am 10. Mai 2015.

[20] Joshua Davies: Implementing SSL / TLS Using Cryptography and PKI. John Wiley and Sons, Indianapolis 2011, S. 344.

[21] Schwenk, Jörg (2010): Sicherheit und Kryptographie im Internet. Von sicherer E-Mail bis zu IP-Verschlüsselung, herausgegeben von Vieweg+Teubner Verlag / GWV Fachverlage GmbH, Wiesbaden. ISBN 978-3-8348-0814-1.

[22] Y. Sheﬀer, R. Holz, P. Saint-Andre: RFC 7457: Summarizing Known Attacks on Transport Layer Security (TLS) and Da- tagram TLS (DTLS). In: Request for Comments. Internet Engineering Task Force, Februar 2015, abgerufen am 10. Januar 2016.

[23] Serge Vaudenay: Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS... In: Advances in Cryp- tology – EUROCRYPT 2002 (= Lecture Notes in Computer Science). Band 2332. Springer, Berlin / Heidelberg 2002, S. 535–545, doi:10.1145/586110.586125 (iacr.org [PDF]). 22 KAPITEL 4. TRANSPORT LAYER SECURITY

[24] Nadhem J. AlFardan, Kenneth G. Paterson: Lucky Thirteen: Breaking the TLS and DTLS Record Protocols. In: IEEE Symposium on Security and Privacy. IEEE, 2013, S. 526–540, doi:10.1109/SP.2013.42 (ieee-security.org [PDF]).

[25] R. Barnes, M. Thomson, A. Pironti, A. Langley: RFC 7568: Deprecating Secure Sockets Layer Version 3.0. In: Request for Comments. Internet Engineering Task Force, Juni 2015, abgerufen am 10. Januar 2016.

[26] B. Moeller, A. Langley: RFC 7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks. In: Request for Comments. Internet Engineering Task Force, April 2015, abgerufen am 10. Januar 2016.

[27] Gregory V. Bard: The Vulnerability of SSL to Chosen Plaintext Attack. In: Cryptology ePrint Archive. 2004, doi:10.1145/586110.586125 (iacr.org [PDF]).

[28] Thai Duong, Juliano Rizzo: Here Come The Ninjas. 13. Mai 2011, abgerufen am 10. Januar 2016 (PDF).

[29] Juliano Rizzo, Thai Duong: Browser Exploit Against SSL/TLS. 3. Oktober 2011, abgerufen am 10. Januar 2016.

[30] Juliano Rizzo, Thai Duong: The CRIME attack. 2012, abgerufen am 11. Januar 2016 (PDF, Präsentation bei der Ekoparty 2012.).

[31] R. Peon, H. Ruellan: RFC 7541: HPACK: Header Compression for HTTP/2. In: Request for Comments. Internet Engineering Task Force, Mai 2015, abgerufen am 11. Januar 2016.

[32] Tal Be'ery, Amichai Shulman: A Perfect CRIME? Only TIME Will Tell. 2013, abgerufen am 11. Januar 2016 (PDF).

[33] Cipher Suites mit „RSA_EXPORT“ im Namen.

[34] Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfre- do Pironti, Pierre-Yves Strub, Jean Karim Zinzindohoue: A Messy State of the Union: Taming the Composite State Machines of TLS. In: IEEE Symposium on Security and Privacy. IEEE, 2015, S. 535–552, doi:10.1109/SP.2015.39 (research.microsoft.com [PDF]).

[35] Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfredo Pironti, Pierre-Yves Strub, Jean Karim Zinzindohoue: A messy state of the union: Taming the Composite State Machines of TLS. 2015, abgerufen am 11. Januar 2016 (PDF, Präsentationsfolien.).

[36] Cipher Suites mit „DHE_EXPORT“ im Namen.

[37] David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella- Béguelin, Paul Zimmermann: Imperfect Forward Secrecy: How Diﬃe-Hellman Fails in Practice. In: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. ACM, New York 2015, S. 5–17, doi:10.1145/2810103.2813707 (weakdh.org [PDF]).

[38] Google entwickelt eigene SSL-Bibliothek auf heise online Kapitel 5

Hypertext Transfer Protocol Secure

HyperText Transfer Protocol Secure (HTTPS, englisch für „sicheres Hypertext-Übertragungsprotokoll“) ist ein Kommunikationsprotokoll im World Wide Web, um Daten abhörsicher zu übertragen. Es stellt eine Transportver- schlüsselung dar. Technisch deﬁniert es als URI-Schema eine zusätzliche Schicht zwischen HTTP und TCP. HTTPS wurde von Netscape entwickelt und zusammen mit SSL 1.0 erstmals 1994 mit deren Browser veröﬀentlicht.

5.1 Nutzen

HTTPS wird zur Herstellung von Vertraulichkeit und Integrität in der Kommunikation zwischen Webserver und Webbrowser (Client) im World Wide Web verwendet. Dies wird u. a. durch Verschlüsselung und Authentifizierung erreicht. Ohne Verschlüsselung sind Daten, die über das Internet übertragen werden, für jeden, der Zugang zum entsprechenden Netz hat, als Klartext lesbar. Mit der zunehmenden Verbreitung von offenen (d. h. unverschlüsselten) WLANs nimmt die Bedeutung von HTTPS zu, da damit die Inhalte unabhängig vom Netz verschlüsselt werden können. Die Authentifizierung dient dazu, dass beide Seiten der Verbindung beim Aufbau der Kommunikation die Identität des Verbindungspartners überprüfen können. Dadurch sollen Man-in-the-Middle-Angriffe und teilweise auch Phishing verhindert werden.

5.2 Technik

Syntaktisch ist HTTPS identisch mit dem Schema für HTTP, die zusätzliche Verschlüsselung der Daten geschieht mittels SSL/TLS: Unter Verwendung des SSL-Handshake-Protokolls findet zunächst eine geschützte Identifikation und Authentifizierung der Kommunikationspartner statt. Anschließend wird mit Hilfe asymmetrischer Verschlüsse- lung oder des Diffie-Hellman-Schlüsselaustauschs ein gemeinsamer symmetrischer Sitzungsschlüssel ausgetauscht. Dieser wird schließlich zur Verschlüsselung der Nutzdaten verwendet. Der Standard-Port für HTTPS-Verbindungen ist 443. Neben den Server-Zertifikaten können auch signierte Client-Zertifikate nach X.509.3 erstellt werden. Das ermöglicht eine Authentifizierung der Clients gegenüber dem Server, wird jedoch selten eingesetzt. Eine ältere Protokollvariante von HTTPS war S-HTTP.

5.3 Client-Verarbeitung

Mit der Entwicklung von HTTPS durch Netscape wurde das Protokoll und die anwenderseitige Client-Software schon früh in Webbrowser integriert. Damit ist meist keine weitere Installation gesonderter Software notwendig.

23 24 KAPITEL 5. HYPERTEXT TRANSFER PROTOCOL SECURE

Eine HTTPS-Verbindung wird durch eine https-URL angewählt und durch das SSL-Logo angezeigt – beim Internet Explorer 6 ein Schloss-Icon in der Statusleiste, bei Mozilla zusätzlich in der Adresszeile, die bei Firefox, aktuellen Opera- und Internet-Explorer-7-Browsern zusätzlich gelb hinterlegt wird, bei Apple Safari 3.0 durch ein kleines Schloss-Symbol in der obersten rechten Ecke des Browserfensters.

5.3.1 Varianten der HTTPS-Anwahl

Die Entscheidung, ob eine sichere HTTPS- statt einer HTTP-Verbindung genutzt wird, kann unterschiedlich erfolgen:

• Serverseitig wird ausschließlich HTTPS zugelassen, wie meist bei Online-Banking; teils wird dabei eine ange- wählte http-Adresse automatisch auf https weitergeleitet.

• Der Login wird über HTTPS erzwungen, dann wird ein HTTP-Cookie im Browser gesetzt und, um Rechenzeit zu sparen, der weitere Dienst unverschlüsselt abgewickelt; z. B. bei eBay.

• Clientseitig durch HSTS: Wenn der Server nur HTTPS zulässt (wie oben beschrieben), kann der Browser dies speichern und stellt zukünftig immer eine Verbindung über HTTPS her. Steht der Server zusätzlich auf der 5.4. SERVER-BETRIEB 25

HSTS Preload Liste, stellt der Browser auch beim ersten Besuch schon direkt eine HTTPS-Verbindung her.[1]

• Clientseitige Eingabe der httpS-Variante oder Browser-Plug-in (z. B. für Firefox und Chrome „HTTPS Ever- ywhere“), welches http-Anfragen durch https-Anfragen ersetzt, bei Diensten, die beide Varianten unterstützen.

Nach Anwahl der HTTPS-Adresse soll der Client-Browser dem Anwender zuerst das Zertifikat anzeigen, sofern es nicht automatisch über bereits akzeptierte Zertifikate überprüft werden kann. Dieser entscheidet nun, gegebenenfalls nach Prüfung über die angegebenen Links, ob er dem Zertifikat für diese Sitzung vertraut, ggf. es auch permanent speichert. Andernfalls wird die HTTPS-Verbindung nicht hergestellt („Diese Seite verlassen“ bei Firefox bzw. „Kli- cken Sie hier um diese Seite zu verlassen.“ beim Internet Explorer).

5.3.2 Vorinstallierte Zertiﬁkate

Um diese für Unkundige eventuell irritierende Abfrage zu vermeiden, wurde mit der Zeit eine Reihe von Root- Zertifikaten von den Browserherstellern akzeptiert, die schon bei der Installation eingetragen werden. Webseiten, die entsprechende Zertifikate haben, werden dann, ebenso wie davon abgeleitete Unter-Zertifikate, bei Aufruf ohne Nachfrage akzeptiert. Ob ein Root-Zertifikat dem Browser bekannt ist, hängt von der Browser-Version ab; zudem wird die Liste der Zertifikate teils auch online im Rahmen der Systemaktualisierung auf den neuesten Stand gebracht, so bei Microsoft Windows. Mit dem Internet Explorer 7 hat Microsoft, kurz danach auch Mozilla mit dem Firefox 3, die Warnung bei nicht eingetragenen Zertifikaten verschärft: Erschien vorher nur ein Pop-up „Sicherheitshinweis“, das nach Name, Quelle und Laufzeit des Zertifikats differenzierte, so wird nun der Inhalt der Webseite ausgeblendet und eine Warnung angezeigt, mit der Empfehlung, die Seite nicht zu benutzen. Um diese sehen zu können, muss der Anwender dann explizit eine „Ausnahme hinzufügen“. Ein nicht im Browser eingetragenes Zertifikat wird damit für Massenanwendungen zunehmend untauglich. Die Frage, welche Zertifikate in die Browser aufgenommen werden, hat in der Open-Source-Community fallweise zu längeren Diskussionen geführt, so zwischen CAcert, einem Anbieter kostenloser Zertifikate, und der Mozilla Foundation, siehe CAcert (Vertrauenswürdigkeit). Ende 2015 ging Let’s Encrypt online, gegründet u. a. von Mozilla und der Electronic Frontier Foundation. Hier werden kostenlose Zertifikate für jedermann angeboten mit dem Ziel, die Verbreitung von HTTPS insgesamt zu fördern. Für die Installation und laufende Aktualisierung der Zertifikate ist jedoch eine eigene Software auf dem Server notwendig.

5.4 Server-Betrieb

Als Software zum Betrieb eines HTTPS-fähigen Webservers wird eine SSL-Bibliothek wie OpenSSL benötigt. Diese wird häuﬁg bereits mitgeliefert oder kann als Modul installiert werden. Der HTTPS-Service wird üblicherweise auf Port 443 bereitgestellt.

5.4.1 Zertiﬁkat

Weiterhin ist ein digitales Zertifikat für SSL notwendig: Ein Binärdokument, das im Allgemeinen von einer – selbst wiederum zertifizierten – Zertifizierungsstelle (CA von englisch certificate authority) ausgestellt wird, das den Server und die Domain eindeutig identifiziert. Bei der Beantragung werden dazu etwa die Adressdaten und die Firmierung des Antragstellers geprüft. In gängigen Browsern eingetragene Zertifikate werden typischerweise zu Preisen zwischen 15 und 600 € pro Jahr angeboten, wobei fallweise weitere Dienste, Siegel oder Versicherungen enthalten sind. Eine Reihe von Zertifizie- rungsstellen gibt kostenlos Zertifikate aus. Die etwa von StartCom[2] oder Let’s Encrypt ausgestellten Zertifikate werden dabei von fast allen modernen Browsern ohne Fehlermeldung akzeptiert. Ebenfalls kostenlose Zertifikate erstellt CAcert, wo es bisher jedoch nicht gelang, in die Liste der vom Browser automatisch akzeptierten Zertifikate aufgenommen zu werden; siehe oben. Ein solches Zertifikat muss daher bei der Client-Verarbeitung vom Anwender manuell importiert werden; dieses Verhalten kann aber auch erwünscht sein. Auch ist es möglich, selbst-signierte Zertifikate (engl. self-signed certificate) zu verwenden, die ohne Beteiligung einer gesonderten Instanz erstellt wurden und ebenfalls manuell bestätigt werden müssen. Ein so erstelltes Zertifikat 26 KAPITEL 5. HYPERTEXT TRANSFER PROTOCOL SECURE ist verwundbar durch einen Man-in-the-middle-Angriff, wenn es dem Anwender vor der Erstverwendung nicht auf einem sicheren Weg zugestellt und von ihm in seine Client-Anwendung importiert wurde. Um veraltete oder unsicher gewordene Zertifikate für ungültig zu erklären, sind Zertifikatsperrlisten (englisch certificate revocation list, CRL) vorgesehen. Die Konzeption sieht vor, dass diese Listen regelmäßig von Browsern geprüft und darin gesperrte Zertifikate ab sofort abgewiesen werden. Das Verfahren ist jedoch nicht durchgängig organisiert und wird praktisch nur wenig genutzt. Zu Angriffen auf das Zertifikatsystem, siehe unten.

Extended-Validation-Zertiﬁkat

→ Hauptartikel: Extended-Validation-Zertiﬁkat

Vor dem Hintergrund zunehmender Phishing-Angriffe auf HTTPS-gesicherte Webanwendungen hat sich 2007 in den USA das CA/Browser Forum[3] gebildet, das aus Vertretern von Zertifizierungsorganisationen und den Browser- Herstellern Google, KDE, Microsoft, Mozilla und Opera besteht. Im Juni 2007 wurde daraufhin eine erste gemein- same Richtlinie verabschiedet, das Extended-Validation-Zertifikat, kurz EV-SSL in Version 1.0, im April 2008 dann Version 1.1. Ein Domain-Betreiber muss für dieses Zertifikat weitere Prüfungen akzeptieren: Während bisher nur die Erreichbar- keit des Admins (per Telefon und E-Mail) zu prüfen war, wird nun die Postadresse des Antragstellers überprüft und bei Firmen die Prüfung auf zeichnungsberechtigte Personen vorgenommen. Damit sind auch deutlich höhere Kosten verbunden. Für den Anwender macht sich das EV-Zertifikat durch eine zusätzliche weiß auf grün unterlegte Firma in der Adress- zeile des neueren Browsers (ab 2007, also etwa Firefox 3 und IE7), rechts vom Site-Logo, bemerkbar. Durch das Ausbleiben der (für diese Site) gewohnten grünen Farbe soll der Anwender dann gefälschte HTTPS-Sites schnell und ggf. auch intuitiv – also ohne spezielle Schulung – erkennen können.

5.4.2 IP-Adressen bei mehreren Domains

Zum Betrieb eines HTTPS-Webservers war lange Zeit eine eigene IP-Adresse pro Hostname notwendig. Bei unverschlüsseltem HTTP ist das nicht erforderlich: Seitdem Browser den Hostnamen im HTTP-Header mit- senden, können mehrere virtuelle Webserver mit je eigenem Hostnamen auf einer IP-Adresse bedient werden, zum Beispiel bei Apache über den NameVirtualHost-Mechanismus. Dieses Verfahren wird inzwischen bei der weit über- wiegenden Zahl der Domains benutzt, da hier der Domain-Eigner selbst keinen Server betreibt. Da bei HTTPS jedoch der Webserver für jeden Hostnamen ein eigenes Zertifikat ausliefern muss, der Hostname aber erst nach erfolgtem SSL-Handshake in der höheren HTTP-Schicht übertragen wird, ist das Deklarieren des Hostnamens im HTTP-Header hier nicht anwendbar. Dadurch war eine Unterscheidung nur anhand der IP/Port- Kombination möglich; ein anderer Port als 443 wird wiederum von vielen Proxys nicht akzeptiert. Vor diesem Hintergrund nutzten einige Provider einen Workaround, um ihren Kunden auch HTTPS ohne eigene IP- Adresse zu ermöglichen, etwa „shared SSL“. Sie nutzten wildcard Zertifikate, die für alle Subdomains einer Domain gültig sind, in Verbindung mit kundenspezifischen Subdomains. Andere Provider nutzten einen „SSL Proxy“, der die Anfragen über eine von mehren Kunden genutzte Domain leitete. Die Lösung dieses Problems kam durch Server Name Indication (SNI)[4], auf Basis von Transport Layer Security 1.2, da hier das Zertifikat bereits beim SSL-Handshake übermittelt werden kann. Damit sind die o.g. anderen Tech- niken bedeutungslos geworden. Das Verfahren bedarf entsprechend aktueller Software auf Seiten des Servers und des Browsers. Im Falle des Apache-Servers wird die SNI Verarbeitung z. B. durch eine nur leicht modifizierte Konfigurations- Anweisung gesteuert:[5]

5.4.3 Einbindung

Die Einbindung von HTTPS in eine Website oder -anwendung erfolgt analog zu den oben genannten Varianten der HTTPS-Anwahl: 5.4. SERVER-BETRIEB 27

• Wenn ausschließlich HTTPS zulässig ist, kann das umgesetzt werden durch:

• Weiterleitung (HTML-refresh) oder auch ein rewrite der URL • Konﬁguration von HTML-Seiten oder Skripten als Muss-SSL, bei Apache etwa durch die Anweisung SSLRequireSSL in der .htaccess. Wird eine solche Seite per http aufgerufen, erzeugt der Server einen '403 – Forbidden' HTTP-Fehlercode.

• Der Anwender wird auf die Möglichkeit der SSL-Nutzung durch einen entsprechenden Link hingewiesen.

• Teilweise wird, vor allem während der Einführung von HTTPS, auf eine Bewerbung durch einen Link verzichtet. Der Anwender kann nur manuell auf HTTPS umschalten, indem er in der URL selbstständig das „s“ hinter „http“ hinzufügt.

• Skriptgesteuerte Erzeugung von HTTPS-Links, um den Anwender bei bestimmten Arbeitsschritten oder Aus- gaben auf eine HTTPS-Seite zu lenken. Anschließend kann im Skript geprüft werden, ob dieses per HTTPS aufgerufen wurde, bei PHP etwa durch die Bedingung: $_SERVER['HTTPS']=='on'

5.4.4 Umstellung

Mit zunehmender CPU-Leistung sowie Sicherheitsbewußtsein tritt regelmäßig die Anforderung auf, eine bisher auf HTTP basierende Website auf HTTPS umzustellen. Im Falle des Stack overﬂow Dienstes mit einer Vielzahl von Usern und Services zieht sich dieser Prozess über einige Jahre hin[6] und ist Stand März 2017 nicht abgeschlossen. Dabei wurden u. a. folgende Themen bearbeitet:[7]

• Inhalte von Drittanbietern, inklusive Mediadaten, müssen SSL unterstützen; andernfalls ggf. eine Browserwar- nung erscheint ('Part of this page is not secure' o.ä.)

• Gesamte Infrastruktur ist auf SSL umzustellen, darunter Loadbalancer und Proxies

• Organisation der Zertiﬁkate, ggf. für eine Vielzahl von Subdomains

• Umstellung von Code der eigenen Webanwendung, worin HTTP hart codiert ist

• Umstellung von altem und Prüfung von neuem User-Code, der ggf. HTTP verwendet

• Qualitätsprüfung

• Umsetzung laufender Sessions, ohne deren Inhalte zu verlieren (24/7 Betrieb)

5.4.5 Leistung

2010 verursachte die Verschlüsselung bei Gmail weniger als 1 % der CPUs-Last, weniger als 1 KB Arbeitsspeicherbedarf pro Verbindung und weniger als 2 % des Netzwerk-Datenverkehrs.[8] 10 Jahre vorher belastete der Rechenaufwand der Verschlüsselung die Server noch stark.[8] Beim Verbindungsaufbau legt der Server einen Verschlüsselungsalgorithmen fest. In der Theorie soll der Server dabei an den Wünschen des Clients orientieren. Um Rechenzeit zu sparen, werden jedoch auf Servern mit hohem Datenverkehr bevorzugt Strom-Chiﬀren eingesetzt, da diese weniger rechenintensiv sind als Block-Chiﬀren wie AES oder Camellia. Viele der dabei lange Zeit genutzten Verfahren wie RC4 gelten als unsicher und werden daher ab 2016 von den großen Webbrowsern nicht mehr unterstützt.[9] Zur Entlastung der Server-CPU werden auch Hardware-SSL-Beschleuniger (SSL accelerators) angeboten: PCI-Steckkarten mit speziellen, optimierten Prozessoren, die aus der SSL-Bibliothek angesprochen werden. Daneben gibt es auch ei- genständige Geräte, meist in Rack-Bauweise, die Teile des HTTP-Datenstroms automatisch verschlüsseln. Weiterhin werden Server mit programmierbaren Recheneinheiten angeboten, die mit entsprechenden SSL-Bibliotheken höhere Leistung als vergleichbar aufwendige Universal-CPUs erreichen, so die MAU (Modular Arithmetic Unit) von Sun. Diese spezielle Hardware steht aber im engen Wettbewerb mit der stetigen Entwicklung der Multiprozessor- und Multi-Core-Systeme der großen CPU-Hersteller Intel und AMD.[10] 28 KAPITEL 5. HYPERTEXT TRANSFER PROTOCOL SECURE

5.5 Angriﬀe und Schwachstellen

Mit den allgemein zunehmenden Kenntnissen über die HTTPS-Technik haben sich auch die Angriffe auf SSL- gesicherte Verbindungen gehäuft. Daneben sind durch Recherche und Forschungen Lücken in der Umsetzung bekannt geworden. Dabei ist grundsätzlich zu unterscheiden zwischen Schwachstellen bei der Verschlüsselung selbst und im Zertifikatsystem. 2013 wurde im Zusammenhang mit der globalen Überwachungs- und Spionageaffäre bekannt, dass die NSA beide Angriffskanäle nutzte um Zugang zu verschlüsselten Verbindungen zu erlangen.

5.5.1 Verschlüsselung

Die bei SSL eingesetzten Verschlüsselungsverfahren werden unabhängig von ihrem Einsatzzweck regelmäßig über- prüft und gelten als mathematisch sicher, d. h., sie lassen sich theoretisch mit den heute bekannten Techniken nicht brechen. Die Zuverlässigkeit der Algorithmen wird regelmäßig etwa durch Wettbewerbe unter Kryptologen überprüft. Regelmäßig werden in den Spezifikationen und den Implementierungen die Unterstützung veralteter Verschlüsse- lungsverfahren, die nach dem aktuellen Stand der Technik als nicht mehr sicher gelten, gestrichen und neue Verfahren aufgenommen.[11] Probleme entstanden in der Vergangenheit mehrfach durch fehlerhafte Implementierung der Kryptologie. Insbe- sondere Schwachstellen in der weit verbreiten OpenSSL-Bibliothek wie Heartbleed haben dabei große öffentliche Aufmerksamkeit erfahren. Da in der Regel Benutzer nicht explizit eine verschlüsselte Verbindung durch Spezifizierung des HTTPS-Protokolls (https:// ) beim Aufruf einer Webseite anfordern, kann ein Angreifer eine Verschlüsselung der Verbindung bereits vor Initialisierung unterbinden und einen Man-in-the-Middle-Angriff ausführen.[12] Als Schutz vor solchen Angriffen wurde der Standard HTTP Strict Transport Security (HSTS) entwickelt.

5.5.2 Zertiﬁkatsystem

SSL-Verbindungen sind grundsätzlich gefährdet durch Man-in-the-middle-Angriffe, bei denen der Angreifer den Datenverkehr zwischen Client und Server abfängt, indem dieser sich beispielsweise als Zwischenstelle ausgibt. Eine Reihe von Angriffsverfahren setzen voraus, dass sich der Angreifer im Netzwerk des Opfers befindet. Beim DNS- Spoofing wiederum bestehen diese Voraussetzungen nicht. Um sich als (anderer) Server auszugeben, muss der Angreifer auch ein Zertifikat vorweisen. Das ist ihm beispielsweise dann möglich, wenn es ihm gelingt, in das System einer Zertifizierungsstelle einzudringen, oder er anderweitig in den Besitz eines Zertifikats kommt, mit dem sich beliebige andere Zertifikate ausstellen lassen. Insbesondere bei einflussreichen Angreifern, wie etwa Regierungsbehörden, können solche Möglichkeiten bestehen, da mitunter auch staatliche Zertifizierungsstellen existieren.[13] HTTP Public Key Pinning und Certificate Transparency sollen solche Angriffe erschweren.

Phishing und HTTPS

Ein Nachteil der automatischen Bestätigung der Zertifikate besteht darin, dass der Anwender eine HTTPS-Verbindung nicht mehr bewusst wahrnimmt. Das wurde in jüngerer Zeit bei Phishing-Angriffen ausgenutzt, die etwa Online- Banking-Anwendungen simulieren und dem Anwender eine sichere Verbindung vortäuschen, um eingegebene PIN/TAN- Codes „abzufischen“. Als Reaktion wiesen betroffene Unternehmen ihre Kunden darauf hin, keine Links aus E-Mails anzuklicken und https-URLs nur manuell oder per Lesezeichen einzugeben. Wegen der teils oberflächlichen Prüfungen bei der Vergabe von Zertifikaten wurde von den Browserherstellern das extended-validation-Cert eingeführt, siehe oben.

Gemischte Inhalte Das Nachladen unverschlüsselter Ressourcen ermöglicht einem Angreifer mittels eines Man- in-the-Middle-Angriﬀs Schadcode in die ursprünglich verschlüsselt übertragene Webseite einzuschleusen. Daher blo- ckieren aktuelle Versionen gängiger Webbrowser das Nachladen unverschlüsselter Ressourcen standardmäßig. Eben- so besteht bei einem sowohl für verschlüsselte als auch unverschlüsselte Verbindungen genutzten HTTP-Cookie das Risiko eines Session Hijacking, auch wenn die Authentiﬁzierung über eine verschlüsselte Verbindung erfolgte. 5.6. SPEZIFIKATIONEN 29

Schwachstelle MD5

Im Rahmen des 25. Chaos Communication Congress in Berlin wurde im Dezember 2008 ein erfolgreicher An- griff auf das SSL-Zertifikatsystem veröffentlicht. In internationaler Zusammenarbeit von Kryptologen und mit Ein- satz speziell programmierter Hardware – einem Cluster aus 200 Playstation-3-Spielkonsolen – war es gelungen, im MD5-Algorithmus eine Kollision zu erzeugen, auf deren Basis ein Angreifer sich selbst beliebige Zertifikate ausstellen könnte.[14] Von der Verwendung des MD5-Algorithmus wurde in Fachkreisen vorher schon abgeraten, bei EV-Zertifikaten kann er ohnehin nicht verwendet werden. Die meisten Webbrowser akzeptieren schon seit 2011 keine MD5-Zertifikate mehr.[15] Um ähnliche Probleme zu vermeiden, kündigten die Browser-Hersteller bereits an, Zertifikate die SHA1 nutzen, nur noch eine beschränkte Zeit zu unterstützen.[16]

5.6 Speziﬁkationen

• RFC 2818 – HTTP Over TLS (englisch)

5.7 Weblinks

• Wie funktioniert HTTPS?

5.8 Einzelnachweise

[1] Preloading HSTS

[2] Mozilla vertraut kostenlosen StartCom Zertiﬁkaten. Heise-Online, 3. Juni 2006, abgerufen am 4. März 2010. Vgl. dazu auch Comparison of SSL certiﬁcates for web servers in der englischsprachigen Wikipedia.

[3] cabforum.org

[4] Internet Engineering Task Force: RFC 3546, Juni 2003, abgerufen 10. März 2017

[5] digitalocean.com: How To Set Up Multiple SSL Certiﬁcates on One IP with Apache on Ubuntu 12.04, 19. Oktober 2012, abgerufen 9. März 2017

[6] meta.stackexchange.com: Network-wide HTTPS: It’s time, abgerufen 9. März 2017

[7] nickcraver.com: Stackoverﬂow.com: the road to SSL, abgerufen 9. März 2017

[8] Adam Langley, Nagendra Modadugu, Wan-Teh Chang: Overclocking SSL. In: ImperialViolet. Adam Langley’s Weblog. 25. Juni 2010, abgerufen am 23. Oktober 2014 (englisch).

[9] Emil Protalinski: Google, Microsoft, and Mozilla will drop RC4 encryption in Chrome, Edge, IE, and Firefox next year, VentureBeat, 1. September 2015

[10] Quad Core Intel Xeon SSL Performance auf anandtech.com, 27. Dezember 2006.

[11] Beispielhaft: Daniel Berger: Firefox 39 entfernt SSLv3 und RC4. In: Heise online. 3. Juli 2015, abgerufen am 22. Oktober 2015. Daniel Berger: Firefox 27 verschlüsselt mit TLS 1.2. In: Heise online. 4. Februar 2014, abgerufen am 22. Oktober 2015.

[12] Daniel Bachfeld: Black Hat: Neue Angriﬀsmethoden auf SSL vorgestellt. In: Heise online Security. 19. Februar 2009, abgerufen am 25. Oktober 2015.

[13] EFF zweifelt an Abhörsicherheit von SSL auf heise security, abgerufen am 28. Juni 2013

[14] 25C3: Erfolgreicher Angriﬀ auf das SSL-Zertiﬁkatsystem. Auf heise.de, 30. Dezember 2008, abgerufen am 3. Januar 2013.

[15] Apple IOS5, Firefox 16, Microsoft Internet Explorer

[16] Ivan Ristic: SHA1 Deprecation: What You Need to Know. 30 KAPITEL 5. HYPERTEXT TRANSFER PROTOCOL SECURE

5.9 Text- und Bildquellen, Autoren und Lizenzen

5.9.1 Text • Let’s Encrypt Quelle: https://de.wikipedia.org/wiki/Let%E2%80%99s_Encrypt?oldid=165551916 Autoren: Aka, Ocrho, Dnaber, Doc Taxon, Next2u, Simon04, Mprofitl, PaulBommel, Björn König, Axka, Körnerbrötchen, Jobu0101, MichaelSchoenitzer, The Anome, No- lispanmo, MaVoe, Crazy1880, Trustable, Magioladitis, Häuslebauer, Editorofthewiki, Hadibe, MZMcBride, Wikinger08, Intgr, Lou- syd, MDXDave, Opihuck, Kashmiri, Lómelinde, Zhaofeng Li, Dateientlinkerbot, Mjdtjm, MeanMotherJr, Quotengrote, Mehmetaergun, Impsswoon, Lm 1909, Rugk, Tony Tan, Sarr Cat, RS34, Luke081515Bot, Ndevor, Islandoftrees, JuliusPC und Anonyme: 15 • Extended-Validation-Zertifikat Quelle: https://de.wikipedia.org/wiki/Extended-Validation-Zertifikat?oldid=162498042 Autoren: Mar- kobr, Ocrho, P. Birken, VanGore, MarioS, Hangy, GFJ, RedBot, Dodo von den Bergen, Elvaube, Namex, Bernd vdB, Benjamin.nagel, Rufus46, Thijs!bot, Ciko~dewiki, Seth Cohen, Don Magnifico, Volker Alexander, Mitja, Blaimi, Eginho, Steavor, DumZiBoT, Laak- norBot, Kubz, Nameless23, Johannes Schneider, KLBot2, IDSN, Makecat-bot, Rmcharb, EricSchreyer, Luke081515Bot und Anonyme: 15 • X.509 Quelle: https://de.wikipedia.org/wiki/X.509?oldid=162435828 Autoren: Aka, Leonardo, Wgd, Mrehker, Kubieziel, Geof, Zwobot, Stern, MichaelDiederich, Jpp, Nankea, Mussklprozz, Mijobe, Sadduk, MFM, Fuzzy~dewiki, Bluec, Cljk, PeeCee, Inode, MarioS, Salmi, Cws, BWBot, J-m.s, Polluks, Speck-Made, Jstein, White gecko, Nopherox, Achim Raschka, Flominator, RedBot, Bjou, Calestyo, Felix Stember, Ponte, Hoelli, Dake~dewiki, JSTC, Jens Meißner, Fomafix, LetsGetLauth, Steven Malkovich, Sebman81, Thijs!bot, Rainald62, Cebus, Mojo1442, Kero, Wwwprofi, Kyle the bot, Poxy, Emergency doc, Ute Erb, GernotMS, VanBot, Weblinger, Luckas-bot, ArthurBot, Peterpall, Stegosaurus Rex, Corrigo, Sdochow, Dinamik-bot, EmausBot, Cologinux, B-greift, MerlIwBot, E.windmeier, Mtrenkmann, Anection, SiebenBergeGrizzly, Addbot und Anonyme: 47 • Transport Layer Security Quelle: https://de.wikipedia.org/wiki/Transport_Layer_Security?oldid=165099334 Autoren: Jed, Aka, Mo- lily, Head, Mathias Schindler, Euripides, Markobr, Jla net.de, Matthäus Wander, Erd, Hubi, Mkleine, Hernani, MrTux, Zwobot, Ocrho, Gorgo, Robbot, MichaelDiederich, Jpp, Moolsan~dewiki, Stfn, APPER, Pietz, RokerHRO, Kroimon, Peter200, Priwo, MFM, Thomas Springer, Hardenacke, Ot, Wiegand, Benji, Bluec, PeeCee, Tibi, Panzerknacker, DasBee, VanGore, MarioS, Graui, Zotti, Hansele, See- bi, Togs, J-m.s, Botteler, Mps, Mpils, Polluks, ThomasSkora, Speck-Made, Ja.stiebing, Robot Monk, FlaBot, GFJ, Jef-Infojef, Ber, Ka~dewiki, Flominator, Dubu, Schaengel89, Itti, AmiUhle, Hullbr3ach, Bachsau, Saibot2, Florian Rampp, Millbart, Zuul, Yurik, Lu- diKalell, Viciarg, Tronicum, RobotE, Varina, SCPS, Mcp, El Cazangero, MIGNON, Delvey, RobotQuistnix, Smial, Bota47, Namex, YurikBot, Stefan506, GGNBot, Saibo, Hgulf, Nightflyer, L.D., Ufobat, LKD, ThePeritus, Fomafix, Steven Malkovich, Stefan Knauf, UMW, Tschäfer, P.Soell, 321meins, Mpollmeier, Dominic Z., PixelBot, Semper, Triple-m, Spuk968, Thijs!bot, Schmiditwo, Gvz~dewiki, Leider, Horst Gräbner, Tobi B., Gohnarch, Cocker68, JAnDbot, Xypron, YourEyesOnly, Kuhlo, Essich, Doerk, Frankao, Merlissimo, PerfektesChaos, DodekBot, Reaper35, Gerakibot, VolkovBot, Regi51, Idioma-bot, Lautrivta, Färber, Der.Traeumer, Eulenspiegel1, Lo- gicproblem, Trustable, Snoopy1964, Blaimi, Plankton314, Se4598, Rekire, Woches, Alexbot, Digisus, Lon Molescraft, Tattoo, Cars- racBot, AwOc, PM3, MystBot, Luckas-bot, Traute Meyer, Rubinbot, Yonidebot, Xqbot, ArthurBot, Der Messer, RainerGrimm, Mas- tiBot, Blubberdiblub, Nameless23, Rr2000, Steppke79, Serols, Kghbln, EmausBot, Vorrauslöscher, Speleosepp, Mkmikado, Kristian- domke, Stuart.clayton.22, WikitanvirBot, Milad A380, Phry, Udo the man, Kasirbot, Pangean, MerlIwBot, Boshomi, Lómelinde, Gerold Rosenberg, Radiojunkie, Yep2, Tolek, Rmcharb, Addbot, Itsecstudi, J744, MrEurostar, Codandus, Luke081515Bot, FNDE, WIr lagen vor Madagaskar, Soluvo, RopeWiki01, DaDoKa, Louis 2100 und Anonyme: 195 • Hypertext Transfer Protocol Secure Quelle: https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure?oldid=165146418 Au- toren: Ben-Zin, Andre Engels, Nerd, DaB., Aka, IGEL, Head, Pkn, Markobr, Jens Lang, Matthäus Wander, Leonardo, Diddi, ApeBot, Hubi, Carter666, HenrikHolke, Freerk, --, MrTux, Ocrho, Kdwnv, Stern, Schoos, Mazbln, Anton, Jpp, Flacus, Peter200, Darkone, MFM, FutureCrash, Thomas Springer, Hardenacke, Eike sauer, PeeCee, Fabian Bieker, Fleminra, ChristophDemmer, TMg, MarioS, Vwm, S.K., Hansele, Magnummandel, Lustiger seth, Sabata, Mullkubel, Udo T., Janra, Speck-Made, Grimmi59 rade, Diba, Ja.stiebing, NeuerNa- me2010, FlaBot, Gerbil, Sir, Ralf5000, Sir Gawain, Voks, -jha-, RedBot, Berlin-Jurist, Windharp, Ellywa, Folke, Fleasoft, Rkaltenthaler, Zaphiro, Bachsau, Localhost~dewiki, Mpohl307, Sflori, BLUcoder, LudiKalell, Nepenthes, BaniPani, RobotQuistnix, Elvaube, Tsca.bot, Andreasklug, YurikBot, Stefan506, Hgulf, DerHexer, Bernd vdB, Aruck, Fomafix, Markus Moll, Cottbus, Mfb, Carry05, Thornard, Stefan Knauf, Schreibvieh, Edoe, Joschi71, Pendulin, Mitten, Benatrevqre, Diego017, Roo1812, Spuk968, Thijs!bot, Arno Matthias, Horst Gräbner, Bernard Ladenthin, Gohnarch, Dandelo, JAnDbot, Vrumfondel, Heinzelotto, Webmeischda, Dunedan, Mgmax, Don Magnifico, Zollernalb, Merlissimo, PerfektesChaos, Gerold Broser, Reaper35, Gerakibot, DorganBot, TXiKiBoT, Regi51, Alleborgo- Bot, SieBot, Oceancetaceen, Trustable, Umherirrender, Theonlyandy, Alnilam, QualiStattQuanti, Tolentino, Se4598, Emergency doc, Ute Erb, Häuslebauer, Alexbot, SilvonenBot, Schotterebene, Hadibe, PM3, MystBot, Luckas-bot, Enth'ust'eac, Nallimbot, GrouchoBot, Krd, ThurnerRupert, Traute Meyer, Small Axe, Tofra, ArthurBot, Der Messer, Wsxx, RibotBOT, Apatenge, FrankDopatka, Mushushu, FalconL, Nothere, Lotterfriends, TobeBot, Anoxi, Wurmkraut, Sternschläger, Sebastian Uellenbeck, Bernd.Brincken, TjBot, Gorlingor, Wassertraeger, EmausBot, NonScolae, Devsheeep, JackieBot, Didym, Sinuhe20, VPiaNo, Ebrambot, Balumir, Xayax, WikitanvirBot, Randolph33, Mjbmrbot, CamelBot, MerlIwBot, Hkoeln, Scintz, Hybridbus, Justincheng12345-bot, Dexbot, Steinsplitter, Makecat-bot, Rmcharb, Lex parsimoniae, Exploide, Nenntmichruhigip, Addbot, Mö1997, Abrixas2, J744, Rugk, Schnabeltassentier, Unfugsbeseitiger, Centenier, Luke081515Bot, S536870912, Jange2, Alfrejg und Anonyme: 143

5.9.2 Bilder • Datei:Commons-logo.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/4/4a/Commons-logo.svg Lizenz: Public domain Autoren: This version created by Pumbaa, using a proper partial circle and SVG geometry features. (Former versions used to be slightly warped.) Ursprünglicher Schöpfer: SVG version was created by User:Grunt and cleaned up by 3247, based on the earlier PNG version, created by Reidab. • Datei:Deutsche_bank_erweitertes_Zertifikat.png Quelle: https://upload.wikimedia.org/wikipedia/commons/b/be/Deutsche_bank_erweitertes_ Zertifikat.png Lizenz: Copyrighted free use Autoren: www.deutsche-bank.de, Screenshot von Johannes Schneider Ursprünglicher Schöp- fer: Johannes Schneider • Datei:Letsencrypt_screenshot_2_domain_choice.png Quelle: https://upload.wikimedia.org/wikipedia/commons/b/bb/Letsencrypt_screenshot_ 2_domain_choice.png Lizenz: CC BY 3.0 Autoren: https://media.ccc.de/browse/conferences/camp2015/camp2015-6907-let_s_encrypt. html#download, ~31:44 Ursprünglicher Schöpfer: Peter Eckersley 5.9. TEXT- UND BILDQUELLEN, AUTOREN UND LIZENZEN 31

• Datei:SSL_Symbol.png Quelle: https://upload.wikimedia.org/wikipedia/commons/4/41/SSL_Symbol.png Lizenz: MPL 1.1 Autoren: Screenshot of Mozilla Firefox Ursprünglicher Schöpfer: Mozilla contributors • Datei:SSL_handshake_with_two_way_authentication_with_certificates.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/ a/ae/SSL_handshake_with_two_way_authentication_with_certificates.svg Lizenz: CC BY 3.0 Autoren: eigene Arbeit, based on a PNG- image by Christian Friedrich, using Cliparts from openclipart.org (koliberek) Ursprünglicher Schöpfer: Essich

5.9.3 Inhaltslizenz

• Creative Commons Attribution-Share Alike 3.0