Let's Encrypt Die neue Sicherheit für Jeden

 
Let's Encrypt Die neue Sicherheit für Jeden
Let’s Encrypt
Die neue Sicherheit für Jeden
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-Zertifikat                                                                                      6
    2.1   Motivation     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
    2.2   Benutzerschnittstelle    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
          2.2.1   Browserunterstützung       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
    2.3   Vergabekriterien     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
    2.4   Weblinks     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
    2.5   Einzelnachweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      8

3   X.509                                                                                                              9
    3.1   Geschichte     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
    3.2   Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     9
          3.2.1   Struktur eines X.509-v3-Zertifikats       . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
          3.2.2   Erweiterungen      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   10
          3.2.3   Dateinamenserweiterungen für Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . .          11
    3.3   Beispiel für ein X.509-Zertifikat     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   11
    3.4   Literatur    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   11
    3.5   Weblinks     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   12

4   Transport Layer Security                                                                                           13
    4.1   TLS in der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      13
          4.1.1   Versionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      14

                                                            i
ii                                                                                               INHALTSVERZEICHNIS

     4.2   Geschichte      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   14
     4.3   Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        15
           4.3.1    TLS-Protokolle im Protokollstapel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        15
           4.3.2    TLS Record Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        16
           4.3.3    TLS Handshake Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .         16
           4.3.4    TLS Change Cipher Spec Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .          17
           4.3.5    TLS Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       18
           4.3.6    TLS Application Data Protocol        . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   18
           4.3.7    Berechnung des Master Secrets        . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   18
     4.4   Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      18
           4.4.1    Padding-Oracle-Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .         18
           4.4.2    BEAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        18
           4.4.3    Kompressionsangriffe        . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   19
           4.4.4    Downgrade auf Exportverschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . .          19
           4.4.5    Implementierungsfehler       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   19
     4.5   Vor- und Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        20
     4.6   Implementierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .         20
     4.7   Siehe auch      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   20
     4.8   Literatur     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   20
     4.9   Weblinks      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   21
     4.10 Einzelnachweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        21

5    Hypertext Transfer Protocol Secure                                                                                  23
     5.1   Nutzen      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   23
     5.2   Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       23
     5.3   Client-Verarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       23
           5.3.1    Varianten der HTTPS-Anwahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .           24
           5.3.2    Vorinstallierte Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     25
     5.4   Server-Betrieb      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   25
           5.4.1    Zertifikat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      25
           5.4.2    IP-Adressen bei mehreren Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . .           26
           5.4.3    Einbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       26
           5.4.4    Umstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       27
           5.4.5    Leistung     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   27
     5.5   Angriffe und Schwachstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .          28
           5.5.1    Verschlüsselung      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   28
           5.5.2    Zertifikatsystem      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   28
     5.6   Spezifikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        29
     5.7   Weblinks      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   29
     5.8   Einzelnachweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       29
     5.9   Text- und Bildquellen, Autoren und Lizenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .         30
           5.9.1    Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     30
INHALTSVERZEICHNIS                                                                                                 iii

       5.9.2   Bilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    30
       5.9.3   Inhaltslizenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   31
Kapitel 1

Let’s Encrypt

Let’s Encrypt (englisch, „Lasst uns verschlüsseln“) ist eine Zertifizierungsstelle, die Ende 2015 in Betrieb gegangen
ist und kostenlose X.509-Zertifikate für Transport Layer Security (TLS) anbietet. Dabei ersetzt ein automatisierter
Prozess die bisher gängigen komplexen händischen Vorgänge bei der Erstellung, Validierung, Signierung, Einrichtung
und Erneuerung von Zertifikaten für verschlüsselte Websites.[1][2]

1.1 Überblick

Ziel des Projekts ist es, verschlüsselte Verbindungen im World Wide Web zum Normalfall zu machen. Indem unter
anderem Zahlung, Webserverkonfiguration, Validierungs-E-Mails und die Sorge um abgelaufene Zertifikate über-
flüssig werden, sollen Aufwand für Einrichtung und Pflege von TLS-Verschlüsselung deutlich gesenkt werden.[3]
Auf einem Linux-Webserver soll das Ausführen von nur zwei Befehlen genügen, um binnen 20 bis 30 Sekunden
HTTPS-Verschlüsselung einzurichten, Zertifikate anzufordern und zu installieren.[4][5]
Bei aktuellen Bestrebungen von großen Webbrowser-Projekten, unverschlüsseltes HTTP als überholt zu erklären und
zukünftig davor zu warnen oder die Unterstützung einzuschränken, wird unter anderem auf die Verfügbarkeit von
Let’s Encrypt gesetzt.[6][7] Dem Projekt wird das Potenzial zugesprochen, die standardmäßige Verschlüsselung des
gesamten Web zu erreichen.[8]
Es werden sogenannte Domain-Validation-Zertifikate ausgestellt. Organization-Validation- und Extended-Validation-
Zertifikate werden nicht angeboten.[9]
Um sowohl die eigene Vertrauenswürdigkeit, als auch gegen Angriffe und Manipulationsversuche zu schützen, soll auf
größtmögliche Transparenz gesetzt werden. Dazu werden zum Beispiel regelmäßig Transparenzberichte veröffentlicht,[10]
alle ACME-Transaktionen öffentlich protokolliert (u.a. mit Certificate Transparency) und möglichst viel auf offene
Standards und freie Software gesetzt.[4]
Der Name der Zertifizierungsstellen-Software „Boulder“ (englisch, „[Fels-]Brocken“) ist eine Anspielung auf ein
Produkt der fiktiven Firma ACME (englisch acme ‚Gipfel‘, ‚Höhepunkt‘) aus den Trickfilmen um Road Runner und
Wile E. Coyote.

1.2 Beteiligte

Let’s Encrypt ist ein von der gemeinnützigen Internet Security Research Group (ISRG) angebotener Dienst. Haupt-
sponsoren sind unter anderem die Electronic Frontier Foundation (EFF), die Mozilla Foundation, Akamai, Google
Chrome und Cisco Systems. Weitere Beteiligte sind die Zertifizierungsstelle IdenTrust, die University of Michigan
(U-M), die Stanford Law School, die Linux Foundation[11] sowie Stephen Kent von Raytheon/BBN Technologies
und Alex Polvi von CoreOS.[4]

                                                         1
2                                                                                    KAPITEL 1. LET’S ENCRYPT

1.3 Technik
Let’s Encrypt besitzt ein RSA-Stammzertifikat, das in einem Hardware-Sicherheitsmodul verwahrt wird und nicht
direkt verwendet wird. Es soll später durch ein ECDSA-Zertifikat ersetzt werden. Damit werden zwei Zwischen-
zertifikate signiert, welche durch die Zertifizierungsstelle IdenTrust gegengezeichnet werden.[12] Eines davon dient
dann zur Signierung der ausgestellten Zertifikate, das andere als Ersatz bei Problemen mit dem ersten. Durch die
IdenTrust-Signatur können die ausgestellten Zertifikate in großen Webbrowsern über die vorinstallierten Stammzer-
tifizierungsstellen geprüft werden. So werden Let’s-Encrypt-Zertifikate auf Client-Seite von Anfang an in der Regel
ohne weiteres akzeptiert.[13] Längerfristig sollen direkt Let’s-Encrypt-Zertifikate in Anwendungen vorinstalliert wer-
den.

1.3.1    Protokoll

Das zur Automatisierung der Zertifizierung genutzte Challenge-Response-Verfahren heißt Automated Certificate
Management Environment (ACME). Dabei werden verschiedene Anfragen an den Webserver der zu zertifizieren-
den Domain gestellt. Anhand gegebenenfalls darauf erfolgenden passenden Rückmeldungen wird sichergestellt, dass
der Antragsteller die Domain kontrolliert („domain validation“).
Auf dem Server-System müssen diese Anfragen korrekt beantwortet werden. Dazu bietet das Protokoll verschie-
dene Möglichkeiten. Bei einer wird dazu von der ACME-Client-Software ein besonders konfigurierter TLS-Server
eingerichtet, der mittels Server Name Indication auf besondere Anfragen der Zertifizierungsstelle antwortet (Domain-
Validierung mittels Server Name Indication, DVSNI). Dieses Verfahren wird allerdings nur für eine erste Zertifikats-
ausstellung für eine Domain akzeptiert (sogenanntes „trust on first use“, TOFU – Vertrauen bei erster Benutzung).
Danach kommt die alternative Validierung über ein bestehendes Zertifikat zum Einsatz. Bei Verlust der Kontrol-
le über ein bereits ausgestelltes Zertifikat muss daher ein Zertifikat von einem Drittanbieter erworben werden, um
wieder ein Let’s-Encrypt-Zertifikat zu erhalten.
Die Validierungsverfahren werden mehrmals über verschiedene Netzwerkpfade durchgeführt. Zur Erschwerung von
DNS-Spoofing ist die Prüfung von DNS-Einträgen von mehreren geographisch verteilten Standpunkten aus vorgese-
hen.
Bei ACME-Interaktionen werden JSON-Dokumente über HTTPS-Verbindungen ausgetauscht.[14] Ein Entwurf einer
Spezifikation ist auf GitHub verfügbar.[15] Mehrere Versionen davon wurden als Entwurf eines Request for Comments
für einen Internet-Standard bei der Internet Engineering Task Force (IETF) eingereicht.[16]

1.3.2    Server-Implementierung

Die Zertifizierungsstelle besteht im Wesentlichen aus einer in Go geschriebenen Software namens Boulder, die die
Server-Seite des ACME-Protokolles implementiert. Sie wird als freie Software auch in Quelltextform unter den Be-
dingungen von Version 2 der Mozilla Public License (MPL) verbreitet.[17] Sie stellt eine REST-Programmierschnittstelle
zur Verfügung, auf die TLS-verschlüsselt zugegriffen werden kann.

1.3.3    Clients

Durch den offenen Standard ACME sind mittlerweile über 30 unterschiedliche Clients entwickelt worden.[18][19]
Im Rahmen des Projekts wurde eine Apache-lizenzierte[20] Python-Referenzimplementierung namens certbot (früher
letsencrypt) entwickelt. Über diese wird am Webserver eines Antragstellers das Zertifikat angefordert, der Domain-
Validierungsprozess durchgeführt, das Zertifikat installiert, die HTTPS-Verschlüsselung im Webserver eingerichtet
und später das Zertifikat regelmäßig erneuert.[21][4] Nach der Installation und Zustimmung zu einem Benutzerver-
trag genügt die Ausführung des reinen Befehls, um ein gültiges Zertifikat installiert zu bekommen. Es können aber
auch zusätzliche Funktionen wie OCSP stapling oder HTTP Strict Transport Security (HSTS) eingestellt werden.[14]
Die automatische Einrichtung funktioniert zunächst allerdings nur mit Apache und nginx. Der Client kann aus den
Paketquellen diverser Linux-Distributionen installiert werden, beispielsweise aus den Debian-Paketquellen.[22]
Daneben gibt es mit acmetool[23] einen in Go geschriebenen mit vor-compilierten, statischen Programmdateien Client.
Die Seite Get HTTPS for free![24] validiert ein Zertifikat per JavaScript im Webbrowser, wobei der Webadmin Anlei-
tungen bekommt für verschiedene manuell auszuführende Schritte. Caddy[25] ist ein HTTP/2-kompatibler Webserver,
1.4. GESCHICHTE UND ZEITPLAN                                                                                       3

Domainauswahldialog

der vollautomatisch ein Zertifikat erzeugt und Inhalte per HTTPS ausliefert. Ein weiterer weit verbreiteter Client ist
acme-tiny, ein in Python geschriebener Client, er ist weniger als 200 Zeilen lang und soll somit von jedem Nutzer
vor der Verwendung selbst gelesen werden[26] .

1.4 Geschichte und Zeitplan

Die Wurzeln des Projektes liegen in einem von der Electronic Frontier Foundation zusammen mit der University
of Michigan betriebenen Projekt und einem unabhängigen Projekt von Mozilla, die in Let’s Encrypt zusammenge-
führt wurden. 2014 wurde die Trägerorganisation, die ISRG, gegründet. Der Start von Let’s Encrypt wurde am 18.
November des Jahres 2014 bekannt gemacht.[27]
Am 28. Januar 2015 wurde das ACME-Protokoll erstmals bei der IETF zur Standardisierung eingereicht.[16] Am
9. April 2015 verkündeten die ISRG und die Linux Foundation ihre Zusammenarbeit.[11] Anfang Juni wurden die
Stamm- und Zwischenzertifikate erzeugt.[13] Am 16. Juni wurde der endgültige Zeitplan für die Dienstaufnahme
bekanntgegeben, wonach die Ausstellung des ersten Zertifikats für die Woche des 27. Juli vorgesehen war, dem eine
Phase eingeschränkter Ausstellung folgen sollte, um die Sicherheit und Skalierbarkeit zu erproben.[28] Am 7. August
wurde der Zeitplan geändert auf die erste Zertifikatsausstellung in der Woche des 7. Septembers und allgemeine
Verfügbarkeit in der Woche des 16. November.[29] Ab 3. Dezember 2015 befand sich das Projekt in der offenen
Betatest-Phase und kann seither von allen Interessierten genutzt werden.[30]
Am 8. März 2016 wurde bekannt gegeben, dass schon über eine Million Zertifikate ausgestellt wurden.[31] Eineinhalb
Monate später waren es über zwei Millionen, weitere eineinhalb Monate später über fünf Millionen Zertifikate ausge-
stellt. Ein nennenswerter Teil des Zuwachses geht auf Kooperationen mit Webhosting-Anbietern wie zum Beispiel die
Blogfarm WordPress.com (über 1 Million zusätzliche Sites) zurück, die für betreute Websites TLS-Verschlüsselung
mit Let’s-Encrypt-Zertifikaten anbieten beziehungsweise diese eigenständig umgestellt haben. Seit der Öffnung des
Betriebs erhöhte sich bis zum 22. Juni 2016 nach Messung von Browserhersteller Mozilla der weltweite Anteil ver-
schlüsselter Websites von 39,5 auf 45 Prozent.[32]
Am 17. März 2016 gab das Projekt bekannt, dem CA/Browser Forum beigetreten zu sein,[33] das Nutzung von
X.509-v.3-Zertifikaten für TLS regelt. Dadurch soll Let’s Encrypt der Aufnahme in Webbrowser als vorinstallierte
Stammzertifizierungsstelle näher kommen.
Am 12. April 2016 ging das Projekt aus der offenen Betaphase in den offiziellen Regelbetrieb über.[34]
4                                                                                                KAPITEL 1. LET’S ENCRYPT

1.5 Siehe auch
      • CAcert

1.6 Weblinks
     Commons: Let’s Encrypt – Sammlung von Bildern, Videos und Audiodateien

      • offizielle Webpräsenz

      • Seth Schoens Vorlesung bei Libre Planet 2015 zu Let’s Encrypt (englischsprachig)

      • technische Einführung in einem Blogeintrag von David Wong (englischsprachig)

1.7 Quellen
     [1] Sean Michael Kerner: Let’s Encrypt Effort Aims to Improve Internet Security. In: eWeek.com. Quinstreet Enterprise, 18.
         November 2014, abgerufen am 27. Februar 2015 (englisch).

     [2] Peter Eckersley: Launching in 2015: A Certificate Authority to Encrypt the Entire Web. In: eff.org. Electronic Frontier Foun-
         dation, 18. November 2014, abgerufen am 27. Februar 2015 (englisch).

     [3] Liam Tung (ZDNet), 19. November 2014: EFF, Mozilla to launch free one-click website encryption

     [4] Fabian Scherschel (heise.de), 19. November 2014: Let’s Encrypt: Mozilla und die EFF mischen den CA-Markt auf

     [5] Rob Marvin (SD Times), 19. November 2014: EFF wants to make HTTPS the default protocol

     [6] Richard Barnes (Mozilla), 30. April 2015: Deprecating Non-Secure HTTP

     [7] The Chromium Projects – Marking HTTP As Non-Secure

     [8] Glyn Moody, 25. November 2014: The Coming War on Encryption, Tor, and VPNs – Time to stand up for your right to
         online privacy

     [9] Steven J. Vaughan-Nichols (ZDNet), 9. April 2015: the web once and for all: The Let’s Encrypt Project

    [10] Zeljka Zorz (Help Net Security), 6. Juli 2015: Let’s Encrypt CA releases transparency report before its first certificate

    [11] Sean Michael Kerner (eweek.com), 9. April 2015: Let’s Encrypt Becomes Linux Foundation Collaborative Project

    [12] Reiko Kaps (heise.de), 17. Juni 2015: SSL-Zertifizierungsstelle Lets Encrypt will Mitte September 2015 öffnen

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

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

    [15] Draft ACME specification.

    [16] R. Barnes, P. Eckersley, S. Schoen, A. Halderman, J. Kasten: Automatic Certificate Management Environment (ACME)
         draft-barnes-acme-01. 28. Januar 2015.

    [17] https://github.com/letsencrypt/boulder/blob/master/LICENSE.txt

    [18] List of Client Implementations. In: Let’s Encrypt Community Support. 25. Oktober 2015, abgerufen am 25. März 2016.

    [19] ACME Client Implementations. In: Documentation - Let’s Encrypt - Free SSL_TLS Certificates. 2. Juli 2016, abgerufen am
         27. Februar 2017.

    [20] https://github.com/letsencrypt/letsencrypt/blob/master/LICENSE.txt

    [21] James Sanders (TechRepublic), 25. November 2014: Let’s Encrypt initiative to provide free encryption certificates

    [22] ITP: letsencrypt – Let’s Encrypt client that can update Apache configurations
1.7. QUELLEN                                                                                                                 5

[23] acmetool. In: hlandau.github.io. Abgerufen am 25. März 2016.

[24] Get HTTPS for free! In: gethttpsforfree.com. Abgerufen am 25. März 2016.

[25] Caddy – The HTTP/2 Web Server with Fully Managed SSL. In: caddyserver.com. Abgerufen am 25. März 2016.

[26] GitHub - diafygi/acme-tiny: A tiny script to issue and renew TLS certs from Let’s Encrypt. In: github.com. Abgerufen am 2.
     März 2017 (englisch).

[27] Joseph Tsidulko: Let’s Encrypt, A Free And Automated Certificate Authority, Comes Out Of Stealth Mode. In: crn.com. 18.
     November 2014, abgerufen am 26. August 2015 (englisch).

[28] Josh Aas: Let’s Encrypt Launch Schedule. Let’s Encrypt. 16. Juni 2015. Abgerufen am 19. Juni 2015.

[29] Updated Let’s Encrypt Launch Schedule. 17. August 2015.

[30] Entering Public Beta. Abgerufen am 4. Dezember 2015.

[31] heise online: Let’s Encrypt: 1 Million Zertifikate ausgestellt. In: heise online. Abgerufen am 9. März 2016 (deutsch).

[32] Dennis Schirrmacher (heise online), 23. Juni 2016: Fünf Millionen Zertifikate: Let’s Encrypt wächst rasant

[33] heise online: Let’s Encrypt tritt CA/Browser Forum bei. In: heise online. Abgerufen am 20. März 2016 (deutsch).

[34] Let’s Encrypt Leaves Beta. Abgerufen am 17. April 2016.
Kapitel 2

Extended-Validation-Zertifikat

Ein Extended-Validation-Zertifikat wird in allen gängigen Browsern (hier Mozilla Firefox) zum Beispiel in der Adressleiste vermerkt.

Extended-Validation-SSL-Zertifikate (EV-SSL; deutsch etwa „Zertifikate mit erweiterter Überprüfung“) sind
X.509 SSL-Zertifikate, deren Ausgabe an strengere Vergabekriterien gebunden ist. Dies bezieht sich vor allem auf
eine detaillierte Überprüfung des Antragstellers durch die Zertifizierungsstelle. Die Vergabekriterien sind in den
„Richtlinien für Extended-Validation-Zertifikate“[1] spezifiziert. Die Richtlinien werden vom CA/Browser Forum
herausgegeben, einem freiwilligen Zusammenschluss von Zertifizierungsstellen und Browser-Herstellern.
Genutzt werden die Zertifikate meist, um Webanwendungen per HTTPS zu sichern und den Anwendern vor dem
Hintergrund von Phishing-Angriffen eine zusätzliche Sicherheit zu geben, etwa beim Online-Banking.

                                                                6
2.1. MOTIVATION                                                                                                   7

2.1 Motivation
Das vorrangige Ziel der EV-SSL-Zertifikate ist es, Phishing mit verschlüsselten und damit auf den ersten Blick siche-
ren Websites zu erschweren. Durch die Einführung eines neuen, „erweiterten“ Zertifikats und der grün-hinterlegten
Adresszeile des Browsers soll das Vertrauen der Benutzer in die sichere Verbindung zur gewünschten Websites ge-
stärkt werden.
Die Ausgabe von SSL-Zertifikaten ist zwar grundsätzlich an eine Überprüfung des Antragstellers gebunden, der Preis-
druck unter den Anbietern hat aber zu einer teilweise laxen Vergabepraxis und zu vereinfachten Zertifikaten geführt,
die nicht mehr als den Domain-Namen zertifizieren. Damit können auch Betrüger SSL-Zertifikate zur Steigerung
ihrer Glaubwürdigkeit verwenden, ohne ihre Identität preisgeben zu müssen.
Kritiker sehen in dem neuen Standard teils den Versuch der Zertifizierungsstellen, sich dem Preiskampf in der SSL-
Zertifikat-Ausgabe durch die Einführung eines neuen Premium-Produktes zu entziehen, das dem Benutzer wenig
zusätzliche Sicherheit bringt, und das auch mit anderen Mitteln zu erreichen wäre. Auch könnten kleinere Anbieter
geschäftlich benachteiligt werden.[2] In der Version 1.1[3] wurde teils versucht, diese Einwände zu berücksichtigen.

2.2 Benutzerschnittstelle
In der Adresszeile des Browsers wird zusätzlich ein Feld angezeigt, in dem Zertifikats- und Domaininhaber im Wech-
sel mit der Zertifizierungsstelle (beispielsweise VeriSign oder TC TrustCenter) eingeblendet werden. Zudem wird je
nach verwendetem Browser die Adresszeile oder ein Teil davon grün eingefärbt. Internetnutzer sollen so noch schnel-
ler erkennen können, ob die besuchte Website echt ist und sich so besser vor Phishingversuchen schützen.

2.2.1    Browserunterstützung
ab Firefox 3 Die erweiterten Funktionen der EV-SSL-Zertifikate werden von Firefox ab Version 3 standardmäßig
      unterstützt. Der linke Teil der Adressleiste wird grün eingefärbt.

Google Chrome EV-SSL-Zertifikate werden standardmäßig unterstützt. Der linke Teil der Adressleiste wird grün
     eingefärbt und der Organisationsname wird in grün neben einem Schloss-Symbol dargestellt.

ab Internet Explorer 7 EV-SSL-Zertifikate werden standardmäßig unterstützt. Die gesamte Adressleiste wird grün
      eingefärbt. Ein Benutzer mit Administratorrechten kann den Internet Explorer so konfigurieren, dass auch
      andere Zertifikate als EV-SSL-Zertifikate angezeigt werden.[4]

ab Opera 9.5 EV-SSL-Zertifikate werden standardmäßig unterstützt. Der rechte Teil der Adressleiste wird grün
     eingefärbt und das Schloss-Symbol hat zusätzlich ein Häkchen.

ab Safari 3.2 EV-SSL-Zertifikate werden standardmäßig unterstützt. Der Organisationsname wird in grün neben
     dem Schloss-Symbol angezeigt.[5]

2.3 Vergabekriterien
Um EV-SSL-Zertifikate ausstellen zu dürfen, müssen sich die Zertifizierungsstellen selbst einer Überprüfung unter-
ziehen. Die Vergabe der Zertifikate ist unter anderem an folgende Kriterien gebunden:

   • Feststellung der Identität und der Geschäftsadresse des Antragstellers

   • Sicherstellung, dass der Antragsteller ausschließlicher Eigentümer der Domain ist oder eine exklusive Nut-
     zungsberechtigung hat

   • Sicherstellung, dass die antragstellenden Personen befugt sind und dass rechtlich bindende Dokumente von
     zeichnungsberechtigten Personen unterschrieben werden

Ein EV-Zertifikat kann ausgestellt werden für:
8                                                                   KAPITEL 2. EXTENDED-VALIDATION-ZERTIFIKAT

     • Behörden

     • Kapitalgesellschaften
     • Personengesellschaften

     • eingetragene Vereine
     • Einzelunternehmer

2.4 Weblinks
     • cabforum.org – Offizielle Website von CA/Browser Forum

     • EV SSL Certificate Guidelines Version 1.6.1 – aktuelle Version der Richtlinien (stand 7. Januar 2016)
     • Erweitertes SSL-Verfahren in den Startlöchern, heise.de

     • Mit EV-SSL-Zertifikaten gegen das Handtaschen-Missverständnis

2.5 Einzelnachweise
    [1] Guidelines for Extended Validation Certificates 1.0

    [2] „Software to Spot ‚Phishers‘ Irks Small Concerns“, Wall Street Journal, 19. Dezember 2006

    [3] Version 1.1 der Guidelines for Extended Validation Certificates

    [4] „Extended Validation support for websites using internal certificates“, 14. August 2009

    [5] „Safari 3.2 mit Phishing-Schutz“, fscklog.com, 13. November 2008
Kapitel 3

X.509

X.509 ist ein ITU-T-Standard für eine Public-Key-Infrastruktur zum Erstellen digitaler Zertifikate. Der Standard
ist auch als ISO/IEC 9594-8 zuletzt im Oktober 2016 aktualisiert worden. Der Standard spezifiziert die folgenden
Datentypen: Public-Key-Zertifikat, Attributzertifikat, Certificate Revocation List (CRL) und Attribute Certificate
Revocation List (ACRL). In der elektronischen Kommunikation finden X.509-Zertifikate Anwendung bei den TLS-
Versionen diverser Übertragungsprotokolle, wie z. B. beim Abruf von Web-Seiten mit dem HTTPS-Protokoll, oder
zum Unterschreiben und Verschlüsseln von E-Mails nach dem S/MIME-Standard.

3.1 Geschichte
X.509 wurde erstmals 1988 veröffentlicht. Die Entwicklung von X.509 begann in Verbindung mit dem X.500-
Standard, der nie vollständig implementiert wurde. X.509 setzt ein strikt hierarchisches System von vertrauenswür-
digen Zertifizierungsstellen (englisch certificate authority, CA) voraus, die Zertifikate erteilen können. Dieses Prinzip
steht im Gegensatz zum Web-of-Trust-Modell, welches einen Graphen und nicht nur einen Baum darstellt und bei
dem jeder ein Zertifikat „unterschreiben“ und damit seine Echtheit beglaubigen kann (siehe z. B. OpenPGP).
Version 3 von X.509 (X.509v3) beinhaltet die Flexibilität, mit Profilen erweitert zu werden. Die IETF entwickelte
das wichtigste Profil, PKIX Certificate and CRL Profile, kurz „PKIX“, im Rahmen des RFC 3280, aktuell RFC 5280.
Der Begriff „X.509-Zertifikat“ bezieht sich meist darauf.

3.2 Zertifikate
Ein von einer Zertifizierungsstelle ausgestelltes digitales Zertifikat wird im X.509-System immer an einen „Distingu-
ished Name“ oder einen „Alternative Name“ wie eine E-Mail-Adresse oder einen DNS-Eintrag gebunden.
Nahezu alle Webbrowser enthalten eine vorkonfigurierte Liste vertrauenswürdiger Zertifizierungsstellen, deren X.509-
Zertifikaten der Browser vertraut. Umgangssprachlich wird häufig von SSL-Zertifikaten gesprochen.
X.509 beinhaltet außerdem einen Standard, mittels dessen Zertifikate seitens der Zertifizierungsstelle wieder ungültig
gemacht werden können, wenn deren Sicherheit nicht mehr gegeben ist (z. B. nach dem öffentlichen Bekanntwerden
des privaten Schlüssels für das Signieren von E-Mails). Die Zertifizierungsstelle kann hierfür ungültige Zertifikate
in Zertifikatsperrlisten (certificate revocation list, kurz CRL) führen. Die automatische Überprüfung, ob ein Zertifi-
kat inzwischen Teil einer Sperrliste ist, ist allerdings nicht in allen Programmen, die X.509-Zertifikate akzeptieren,
standardmäßig aktiviert.

3.2.1    Struktur eines X.509-v3-Zertifikats
   • Zertifikat

         • Version
         • Seriennummer

                                                          9
10                                                                                              KAPITEL 3. X.509

          • Algorithmen-ID
          • Aussteller
          • Gültigkeit
                 • von
                 • bis
          • Zertifikatinhaber
          • Zertifikatinhaber-Schlüsselinformationen
                 • Public-Key-Algorithmus
                 • Public Key des Zertifikatinhabers
          • Eindeutige ID des Ausstellers (optional)
          • Eindeutige ID des Inhabers (optional)
          • Erweiterungen
                 • …
     • Zertifikat-Signaturalgorithmus
     • Zertifikat-Signatur

Aussteller und Zertifikatinhaber werden jeweils durch eine Reihe von Attributen charakterisiert:

     • Gebräuchlicher Name (CN)
     • Organisation (O)
     • Organisationseinheit (OU)
     • Land/Region (C)
     • Bundesland/Kanton (ST)
     • Ort (L)

Aussteller- und Inhaber-ID wurden in Version 2 eingeführt, Erweiterungen in Version 3.

3.2.2     Erweiterungen
Erweiterungen oder Extensions sind inzwischen ein sehr wichtiger Bestandteil eines Zertifikates geworden. Erweite-
rungen haben die folgende Unterstruktur:

     • Erweiterungs-ID
     • Flag (kritisch/unkritisch)
     • Wert

Jede Erweiterung hat eine spezifische ID. Die Flags dienen der schrittweisen Einführung einer neuen Erweiterung. So
sind neue Erweiterungen zu Beginn als unkritisch markiert. Eine Implementierung, die auf eine unbekannte unkri-
tische Erweiterung trifft, kann diese ignorieren. Wird eine Erweiterung mit der Zeit allerdings nach ausreichendem
Testen auf kritisch gesetzt, so muss ein Zertifikat mit unbekannter kritischer Erweiterung als ungültig erachtet wer-
den. Beispiele für Erweiterungen sind

     • KeyUsage: Gibt an, für welche Anwendung dieses Zertifikat ausgestellt wurde. Ein CA-Zertifikat muss hier
       bspw. keyCertSign und CRLsign eingetragen haben.
     • BasicConstraints: Transitivitätsvertrauen ist ohne diese Erweiterung unmöglich. BasicConstraints sind:
          • CA: Gibt an, ob das Zertifikat zu einer Zertifizierungsstelle gehört. In einer Zertifikatskette muss jedes
            Zertifikat, außer dem der letzten Instanz (des Users/Servers), als CA markiert sein.
          • PathLen: Gibt an, wie lang die Zertifikatskette maximal sein darf.
3.3. BEISPIEL FÜR EIN X.509-ZERTIFIKAT                                                                           11

3.2.3    Dateinamenserweiterungen für Zertifikate

Übliche Dateinamenserweiterungen für X.509-Zertifikate sind:

   • .CER – DER- oder Base64-kodiertes Zertifikat

   • .CRT – DER- oder Base64-kodiertes Zertifikat

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

   • .DER – DER-kodiertes Zertifikat

   • .P12 – PKCS#12, kann öffentliche Zertifikate und private Schlüssel (Kennwort-geschützt) enthalten.

   • .P7B – Siehe .p7c

   • .P7C – PKCS#7-signierte Datenstruktur ohne Dateninhalt, nur mit Zertifikat(en) oder Zertifikatsperrliste(n)

   • .PEM – Base64-kodiertes Zertifikat, umschlossen von „-----BEGIN CERTIFICATE-----“ und „-----END CERTIFICATE-
     ----“

   • .PFX – Siehe .p12

PKCS #7 ist ein Standard zum Signieren und Verschlüsseln von Daten. Da das Zertifikat gebraucht wird, um die
signierten Daten zu verifizieren, kann es in der „SignedData“-Struktur untergebracht werden. Eine .p7c-Datei ist der
Spezialfall einer Datei, die keine Daten zum Signieren enthält, sondern nur die „SignedData“-Struktur.
PKCS #12 entwickelte sich aus dem PFX(Personal inFormation eXchange)-Standard und wird benutzt, um öffentliche
und private Schlüssel in einer gemeinsamen Datei auszutauschen.
Eine .PEM-Datei kann Zertifikate und/oder private Schlüssel enthalten, die von entsprechenden BEGIN/END-Zeilen
umschlossen sind.

3.3 Beispiel für ein X.509-Zertifikat
Text-Darstellung eines nach X.509v3 (Version 3) aufgebauten digitalen Zertifikats. (Die Struktur basiert auf ASN.1.):
Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer:
C=AT, ST=Steiermark, L=Graz, O=TrustMe Ltd, OU=Certificate Authority, CN=CA/Email=ca@trustme.dom Va-
lidity Not Before: Oct 29 17:39:10 2000 GMT Not After : Oct 29 17:39:10 2001 GMT Subject: C=AT, ST=Vienna,
L=Vienna, O=Home, OU=Web Lab, CN=anywhere.com/Email=xyz@anywhere.com Subject Public Key Info: Pu-
blic Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c4:40:4c:6e:14:1b:61:36:84:
24:b2:61:c0:b5: d7:e4:7a:a5:4b:94:ef:d9:5e:43:7f:c1:64:80:fd: 9f:50:41:6b:70:73:80:48:90:f3:58:bf:f0:4c:b9: 90:32:81:59:18:16:3f:19:
5f:11:68:36:85:f6: 1c:a9:af:fa:a9:a8:7b:44:85:79:b5:f1:20:d3:25: 7d:1c:de:68:15:0c:b6:bc:59:46:0a:d8:99:4e:07: 50:0a:5d:83:61:d4:
db:c9:7d:c3:2e:eb:0a:8f:62: 8f:7e:00:e1:37:67:3f:36:d5:04:38:44:44:77:e9: f0:b4:95:f5:f9:34:9f:f8:43 Exponent: 65537
(0x10001) X509v3 extensions: X509v3 Subject Alternative Name: email:xyz@anywhere.com Netscape Comment:
mod_ssl generated test server certificate Netscape Cert Type: SSL Server Signature Algorithm: md5WithRSAEncryption
12:ed:f7:b3:5e:a0:93:3f:a0:1d:60:cb:47:19:7d:15:59:9b: 3b:2c:a8:a3:6a:03:43:d0:85:d3:86:86:2f:e3:aa:79:39:e7: 82:20:ed:
f4:11:85:a3:41:5e:5c:8d:36:a2:71:b6:6a:08:f9: cc:1e:da:c4:78:05:75:8f:9b:10:f0:15:f0:9e:67:a0:4e:a1: 4d:3f:16:4c:9b:19:56:6a:f2:
af:89:54:52:4a:06:34:42:0d: d5:40:25:6b:b0:c0:a2:03:18:cd:d1:07:20:b6:e5:c5:1e:21: 44:e7:c5:09:d2:d5:94:9d:6c:13:
07:2f:3b:7c:4c:64:90:bf: ff:8e

3.4 Literatur
   • X.509 Information technology – Open Systems Interconnection – The Directory: Public-key and attribute
     certificate frameworks
12                                                                                           KAPITEL 3. X.509

3.5 Weblinks
     • RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile, Obsolet durch RFC 3280)

     • RFC 3280 (Internet X.509 Public Key Infrastructure, Certificate and CRL Profile, Update RFC 4325, Update
       RFC 4630, Obsolet durch RFC 5280)

     • RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile)
Kapitel 4

Transport Layer Security

Transport Layer Security (TLS, deutsch Transportschichtsicherheit), weitläufiger bekannt unter der Vorgängerbe-
zeichnung Secure Sockets Layer (SSL), ist ein hybrides Verschlüsselungsprotokoll zur sicheren Datenübertragung
im Internet. Die letzte Version des SSL-Protokolls war 3.0 und danach wurde es unter dem neuen Namen TLS,
beginnend mit Version 1.0, weiterentwickelt und standardisiert. (Zwar werden protokollintern die Werte 3 und 1
verwendet, um TLS 1.0 zu repräsentieren, offiziell gibt es aber kein SSL 3.1.) In diesem Artikel wird die Abkür-
zung TLS für beide Bezeichnungen verwendet, sofern nicht explizit auf die alten Versionen Bezug genommen wird.
Bekannte Implementierungen des Protokolls sind OpenSSL, LibreSSL und GnuTLS.

4.1 TLS in der Praxis
TLS-Verschlüsselung wird heute vor allem mit HTTPS eingesetzt. Die meisten Webserver unterstützen TLS 1.0,
viele auch SSLv2 und SSLv3 mit einer Vielzahl von Verschlüsselungsmethoden, fast alle Browser und Server setzen
jedoch bevorzugt TLS mit RSA- und AES- oder Camellia-Verschlüsselung ein. In aktuellen Browsern ist SSLv2
deaktiviert oder führt zu einer Sicherheitswarnung,[1] da diese Protokollversion eine Reihe von Sicherheitslücken[2][3]
aufweist. Seit dem Bekanntwerden des Poodle-Angriffs auf die Verschlüsselung mit SSL gilt dies bei vielen Servern
und Browsern auch für SSLv3. Die Weiterentwicklung TLS 1.1 wird von Google Chrome unterstützt, TLS 1.2 wird
in der Standardkonfiguration von Internet Explorer, Firefox, Google Chrome, Opera und Apple iOS Safari verwendet
(Stand 02/2014).[4]
Seit einiger Zeit nutzen immer mehr Webseitenbetreiber Extended-Validation-TLS-Zertifikate (EV-TLS-Zertifikat).
In der Adresszeile des Browsers wird zusätzlich ein Feld angezeigt, in dem Zertifikats- und Domaininhaber im Wech-
sel mit der Zertifizierungsstelle eingeblendet werden. Zudem wird je nach verwendetem Browser und/oder Add-on
die Adresszeile (teilweise) grün eingefärbt. Internetnutzer sollen so noch schneller erkennen, ob die besuchte Web-
seite echt ist, und besser vor Phishingversuchen geschützt werden. EV-TLS-Zertifikate bieten in technischer Sicht
keinen erweiterten Schutz, die Verschlüsselung und deren Stärke ist identisch. Nur der Inhaber wird dabei besser und
aufwändiger verifiziert. Deshalb benutzt Google generell keine EV-Zertifikate.[5]
Seit Januar 2017 markiert der Web-Browser Chrome Internetseiten als unsicher, die Informationen sammeln, ohne
dabei HTTPS zu nutzen. Dies wird voraussichtlich zu einem signifikanten Anstieg des Einsatzes von HTTPS führen.
Im Februar 2017 war HTTPS bei 2,57 % aller registrierten deutschen Internet-Domains[6] , sowie bei 3,70 % der
österreichischen Domains[7] und 9,71 % der Schweizer Domains[8] aktiviert. Eine Untersuchung von rund 40.000
Webseiten klein- und mittelständischer Unternehmen in Baden-Württemberg durch den Landesbeauftragten für den
Datenschutz und die Informationsfreiheit Baden-Württemberg hat ergeben, dass rund 7 % der untersuchten Websei-
ten über HTTPS angeboten werden. Bei jenen Webseiten, die über HTTPS angeboten werden, ist die serverseitige
Unterstützung für TLS 1.0 noch sehr weit verbreitet (99 %).[9]
TLS ist ohne eine zertifikatsbasierte Authentifizierung anfällig für Man-in-the-Middle-Angriffe: Ist der Man-in-the-
Middle vor der Übergabe des Schlüssels aktiv, kann er beiden Seiten seine Schlüssel vorgaukeln und so den gesamten
Datenverkehr im Klartext aufzeichnen und unbemerkt manipulieren. Wegen der mangelnden Vertrauenswürdigkeit
einiger Zertifizierungsstellen wird seit Anfang 2010 die Sicherheit von TLS grundsätzlich angezweifelt.[10][11][12][13]
Durch die Deaktivierung fragwürdiger Zertifizierungsstellen im eigenen Browser lässt sich dieses Risiko jedoch weit-
gehend beseitigen.

                                                          13
14                                                                  KAPITEL 4. TRANSPORT LAYER SECURITY

In Verbindung mit einem virtuellen Server, zum Beispiel mit HTTP (etwa beim Apache HTTP Server über den VHost-
Mechanismus), ist es grundsätzlich als Nachteil zu werten, dass pro Kombination aus IP-Adresse und Port nur ein
Zertifikat verwendet werden kann, da die eigentlichen Nutzdaten des darüber liegenden Protokolls (und damit der
Name des VHosts) zum Zeitpunkt des TLS-Handshakes noch nicht übertragen wurden. Dieses Problem wurde mit
der TLS-Erweiterung Server Name Indication (SNI) im Juni 2003 durch die RFC 3546 behoben. Dabei wird bereits
beim Verbindungsaufbau der gewünschte Servername mitgesendet. Die ursprüngliche Erweiterung wurde für TLS
1.0 beschrieben, aufgrund der Kompatibilität der einzelnen TLS-Versionen zueinander wird SNI auch bei TLS 1.1
und TLS 1.2 entsprechend der Empfehlung umgesetzt.
Neben HTTPS als verschlüsselte Variante von HTTP sind weitere bekannte Anwendungsfälle für TLS beispielsweise:

     • POP3S für POP3
     • SMTPS für SMTP
     • NNTPS für NNTP
     • SIPS für SIP
     • IMAPS für IMAP
     • XMPPS für XMPP
     • IRCS für IRC
     • LDAPS für LDAP
     • MBS/IP-TLS
     • FTPS für FTP
     • EAP-TLS
     • TN3270-TLS
     • OpenVPN

4.1.1     Versionen

4.2 Geschichte
     • 1994, neun Monate nach der ersten Ausgabe von Mosaic, dem ersten verbreiteten Webbrowser, stellte Netscape
       Communications die erste Version von SSL (1.0) fertig.
     • Fünf Monate später wurde zusammen mit einer neuen Ausgabe des Netscape Navigator die nächste Version
       SSL 2.0 veröffentlicht.
     • Ende 1995 veröffentlichte Microsoft die erste Version seines Webbrowsers Internet Explorer. Kurz darauf
       wurde auch die erste Version ihres SSL-Pendants bekannt, PCT 1.0 (Private Communication Technology).
       PCT hatte einige Vorteile gegenüber SSL 2.0, die später in SSL 3.0 aufgenommen wurden.
     • Als SSL von der IETF im RFC 2246 als Standard festgelegt wurde, benannte man es im Januar 1999 um
       zu Transport Layer Security (TLS). Die Unterschiede zwischen SSL 3.0 und TLS 1.0 sind nur gering. Doch
       entstanden durch die Umbenennung Versionsverwirrungen. So meldet sich TLS 1.0 im Header als Version SSL
       3.1.
     • Später wurde TLS durch weitere RFCs erweitert:
          • RFC 2712 – Addition of Kerberos Cipher Suites to Transport Layer Security (TLS).
          • RFC 2817 – Upgrading to TLS Within HTTP/1.1 erläutert die Benutzung des Upgrade-Mechanismus in
            HTTP/1.1, um Transport Layer Security (TLS) über eine bestehende TCP-Verbindung zu initialisieren.
            Dies erlaubt es, für unsicheren und für sicheren HTTP-Verkehr die gleichen „well-known“ TCP Ports (80
            bzw. 443) zu benutzen.
4.3. FUNKTIONSWEISE                                                                                            15

         • RFC 2818 – HTTP Over TLS trennt sicheren von unsicherem Verkehr durch Benutzung eines eigenen
           Server-TCP-Ports.
         • RFC 3268 – Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)
           nutzt die Erweiterbarkeit von TLS und fügt den bisher unterstützten symmetrischen Verschlüsselungs-
           algorithmen (RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard
           (DES) und Triple DES) den Advanced Encryption Standard (AES) hinzu.
         • RFC 3546 – Transport Layer Security (TLS) Extensions führt das Konzept der Erweiterungen ein, durch
           welches optionale Datenfelder oder Header vor allem bei der anfänglichen Aushandlung übertragen wer-
           den können. Eine der wohl bekanntesten Erweiterungen ist Server Name Indication.

   • Im April 2006 wurde in RFC 4346 die Version 1.1 von TLS standardisiert und damit RFC 2246 obsolet. In
     TLS 1.1 wurden kleinere Sicherheitsverbesserungen vorgenommen und Unklarheiten beseitigt.

   • Im August 2008 erschien mit RFC 5246 die Version 1.2 von TLS, welche somit RFC 4346 obsolet machte.
     Als wesentliche Änderung wurde die Festlegung auf MD5/SHA-1 in der Pseudozufallsfunktion (PRF) und
     bei signierten Elementen fallen gelassen. Stattdessen wurden flexiblere Lösungen gewählt, bei denen die Hash-
     Algorithmen spezifiziert werden können.

   • Für die Version 1.3 liegt seit Januar 2015 ein Entwurf vor[veraltet] .[15]

   • Im Februar 2015 wurde RFC 7465[16] veröffentlicht, das RC4 für Verschlüsselung verbietet.[17]

   • Im Mai 2015 wurden mit RFC 7525,[18] basierend auf dem aktuellen Stand der Technik, Empfehlungen für den
     sicheren Einsatz von TLS und DTLS veröffentlicht. Diese spezifizieren, dass unter anderem SSLv2, SSLv3,
     RC4 und sonstige aufgrund von Exportbeschränkungen auf weniger als 112 Bit Schlüssellänge beschränk-
     te Verschlüsselungsalgorithmen nicht verwendet werden dürfen. Vom Einsatz von 3DES zur Verschlüsselung
     und RSA zum Schlüsselaustausch mit statischen Parametern wird abgeraten. Konkret zum Einsatz empfohlen
     werden Cipher Suites, die zum Schlüsselaustausch Ephemeral Diffie-Hellman in Kombination mit RSA ver-
     wenden, was Forward Secrecy bietet, zur Verschlüsselung AES im Galois/Counter Mode mit 128 oder 256 Bit
     Schlüssellänge sowie die Hashfunktion SHA-256 oder SHA-384 für die Pseudozufallsfunktion von TLS.[19]

4.3 Funktionsweise
Der Client baut eine Verbindung zum Server auf. Der Server authentifiziert sich gegenüber dem Client mit einem
Zertifikat. Der Client überprüft hierbei die Vertrauenswürdigkeit des X.509-Zertifikats und ob der Servername mit
dem Zertifikat übereinstimmt. Optional kann sich der Client mit einem eigenen Zertifikat auch gegenüber dem Server
authentifizieren. Dann schickt entweder der Client dem Server eine mit dem öffentlichen Schlüssel des Servers ver-
schlüsselte geheime Zufallszahl, oder die beiden Parteien berechnen mit dem Diffie-Hellman-Schlüsselaustausch ein
gemeinsames Geheimnis. Aus dem Geheimnis wird dann ein kryptographischer Schlüssel abgeleitet. Dieser Schlüssel
wird in der Folge benutzt, um alle Nachrichten der Verbindung mit einem symmetrischen Verschlüsselungsverfahren
zu verschlüsseln und zum Schutz von Nachrichten-Integrität und Authentizität durch einen Message Authentication
Code abzusichern.

4.3.1    TLS-Protokolle im Protokollstapel

Im OSI-Modell ist TLS in Schicht 5 (der Sitzungsschicht) angeordnet. Im TCP/IP-Modell ist TLS oberhalb der
Transportschicht (zum Beispiel TCP) und unterhalb Anwendungsprotokollen wie HTTP oder SMTP angesiedelt. In
den Spezifikationen wird dies dann zum Beispiel als „HTTP over TLS“ bezeichnet. Sollen jedoch beide Protokolle
zusammengefasst betrachtet werden, wird üblicherweise ein „S“ für Secure dem Protokoll der Anwendungsschicht
angehängt (zum Beispiel HTTPS). TLS arbeitet transparent, so dass es leicht eingesetzt werden kann, um Protokollen
ohne eigene Sicherheitsmechanismen abgesicherte Verbindungen zur Verfügung zu stellen. Zudem ist es erweiterbar,
um Flexibilität und Zukunftssicherheit bei den verwendeten Verschlüsselungstechniken zu gewährleisten.
Das TLS-Protokoll besteht aus zwei Schichten:
16                                                                     KAPITEL 4. TRANSPORT LAYER SECURITY

4.3.2      TLS Record Protocol
Das TLS Record Protocol ist die untere der beiden Schichten und dient zur Absicherung der Verbindung. Es setzt
direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste, die einzeln oder gemeinsam genutzt werden
können:

     • Ende-zu-Ende-Verschlüsselung mittels symmetrischer Algorithmen. Der verwendete Schlüssel wird dabei im
       Voraus über ein weiteres Protokoll (zum Beispiel das TLS Handshake Protocol) ausgehandelt und kann nur
       einmal für die jeweilige Verbindung verwendet werden. TLS unterstützt für die symmetrische Verschlüsselung
       unter anderem DES, Triple DES und AES
     • Sicherung der Nachrichten-Integrität und Authentizität durch einen Message Authentication Code, in der Regel
       HMAC.

Außerdem werden zu sichernde Daten in Blöcke von maximal 16.384 (214 ) Byte fragmentiert und beim Empfän-
ger wieder zusammengesetzt. Dabei schreibt der Standard vor, dass die Blockgröße diesen Wert nicht übersteigt,
außer der Block ist komprimiert oder verschlüsselt – dann darf die Blockgröße um 1024 Byte (bei Kompression)
bzw. 2048 Byte (bei Verschlüsselung) größer sein. Auch können die Daten vor dem Verschlüsseln und vor dem Be-
rechnen der kryptografischen Prüfsumme komprimiert werden. Das Komprimierungsverfahren wird ebenso wie die
kryptografischen Schlüssel mit dem TLS Handshake-Protokoll ausgehandelt.
Der Aufbau einer TLS-Record-Nachricht lautet wie folgt: Content Type (1 Byte: Change Cipher Spec = 20, Alert =
21, Handshake = 22, Application Data = 23) | Protokollversion Major (1 Byte) | Protokollversion Minor (1 Byte) |
Länge (1 Short bzw. zwei Byte)

4.3.3      TLS Handshake Protocol
Das TLS Handshake Protocol baut auf dem TLS Record Protocol auf und erfüllt die folgenden Funktionen, noch
bevor die ersten Bits des Anwendungsdatenstromes ausgetauscht wurden:

     • Identifikation und Authentifizierung der Kommunikationspartner auf Basis asymmetrischer Verschlüsselungs-
       verfahren und Public-Key-Kryptografie. Dieser Schritt ist optional eine Zwei-Wege-Authentifizierung (in die-
       sem Fall wird manchmal von mutual TLS gesprochen), für gewöhnlich authentifiziert sich aber nur der Server
       gegenüber dem Client.
     • Aushandeln zu benutzender kryptografischer Algorithmen und Schlüssel. TLS unterstützt auch eine unver-
       schlüsselte Übertragung.

Der Handshake selbst kann in vier Phasen unterteilt werden:

     1. Der Client schickt zum Server ein client_hello, und der Server antwortet dem Client mit einem server_hello.
        Die Parameter der Nachrichten sind:
           • die Version (die höchste vom Client unterstützte TLS-Protokoll-Version)
           • eine 32 Byte Zufallsinformation (4 Byte Timestamp + 28 Byte lange Zufallszahl), die später verwendet
             wird, um das pre-master-secret zu bilden (sie schützt damit vor Replay-Attacken)
           • eine Session-ID
           • die zu verwendende Cipher Suite (Algorithmen für Schlüsselaustausch, Verschlüsselung und Authentifi-
             zierung)
           • Optional den gewünschten FQDN für die Unterstützung von Server Name Indication
     2. Der Server identifiziert sich gegenüber dem Client. Hier wird auch das X.509v3-Zertifikat zum Client über-
        mittelt. Außerdem kann der Server einen CertificateRequest an den Client schicken. Diese Phase darf nur bei
        anonymem Key Agreement weggelassen werden.
     3. Hier identifiziert sich der Client gegenüber dem Server. Besitzt der Client kein Zertifikat, antwortete er früher
        mit einem NoCertificateAlert. TLS-konforme Systeme verwenden diesen Alert jedoch nicht. Der Client versucht
        außerdem, das Zertifikat, das er vom Server erhalten hat, zu verifizieren (bei Misserfolg wird die Verbindung
4.3. FUNKTIONSWEISE                                                                                                                                                      17

             public key client                                                                                                            public key server

             private key client
                                          Client                                                                          Server          private key server

                                                 generate random number          RNc
                                        RNc

                                                 client_hello (crypto information,     RNc    )
                                                                                                                                  RNc                          Phase 1
                                                                                 generate random number                 RNs

                                                                                                                                  RNc   RNs
                                  RNs   RNc
                                                                        server_hello (crypto information,          RNs        )

                                                                                       server certificate (incl.              )

                                                                                          demand client certificate
                                                                                                                                                               Phase 2
                                                 check server certificate
                                  RNs   RNc

                                                 client certificate (incl.   )

                                                                                             check client certificate

                                              hash over all previous messages (signed with                   )

                                                                                         check hash and signature
                                                                                                                                                               Phase 3
                                                                                                                                  RNc   RNs
                                                 generate random number pre-master-secret                PMS

                        PMS       RNs   RNc
                                                   PMS     encrypted with
                                                                                                                                  RNc   RNs   PMS

                                                     calculate Master-Secret from       PMS            RNs        RNc
                                  MS                                                                                                    MS

                                                 change to encrypted connection with              MS         as key

                                                 end SSL handshake

                                                         change to encrypted connection with                 MS       as key                                   Phase 4

                                                                                                  end SSL handshake

TLS-Handshake mit Zwei-Wege-Authentifizierung mittels Zertifikaten

        abgebrochen). Dieses Zertifikat enthält den öffentlichen Schlüssel des Servers. Wird die Cipher-Suite RSA
        verwendet, so wird das vom Client generierte pre-master-secret mit diesem öffentlichen Schlüssel verschlüsselt
        und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden. Alternativ
        kann hier auch das Diffie-Hellman-Verfahren verwendet werden, um ein gemeinsames pre-master-secret zu
        generieren. Werden die Diffie-Hellman Geheimnisse von Server und Client während des Handshakes frisch
        und zufällig gewählt, sind die Voraussetzungen für Perfect Forward Secrecy erfüllt. Diese Phase ist optional.

   4. Diese Phase schließt den Handshake ab. Aus dem vorhandenen pre-master-secret kann das Master Secret ab-
      geleitet werden und aus diesem der einmalige Sitzungsschlüssel (englisch „session key“). Das ist ein einmalig
      benutzbarer symmetrischer Schlüssel, der während der Verbindung zum Ver- und Entschlüsseln der Daten ge-
      nutzt wird. Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch
      verschlüsselt übertragen.

4.3.4     TLS Change Cipher Spec Protocol

Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht. Diese Nachricht ist ein Byte groß und
besitzt den Inhalt 1. Durch diese Nachricht teilt der Sender dem Empfänger mit, dass er in der aktiven Sitzung auf die
im Handshake Protocol ausgehandelte Cipher Suite wechselt. Ein wesentlicher Grund für die Definition eines eigenen
Protokolls für diese Nachricht besteht darin, dass TLS-Implementierungen mehrere Nachrichten eines Protokolls in
einem Record (also einer TLS-Dateneinheit) zusammenfassen können. Für die Nachricht „Change Cipher Spec“
ist das unerwünscht. Weil Records verschiedener Protokolle nicht zusammengefasst werden dürfen, ist das Problem
durch Definition eines eigenen Protokolls gelöst.[20]
18                                                                    KAPITEL 4. TRANSPORT LAYER SECURITY

4.3.5    TLS Alert Protocol
Das Alert Protocol unterscheidet etwa zwei Dutzend verschiedene Mitteilungen. Eine davon teilt das Ende der Sitzung
mit (close_notify). Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten
Zertifikate. Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden.
Der Aufbau einer Fehlermeldung lautet wie folgt: AlertLevel (1 Byte: Warning = 1, Fatal = 2) | AlertDescription (1
Byte: close_notify = 0, […], no_renegotiation = 100).
In der Spezifikation von TLS werden die folgenden schweren Fehlertypen definiert:
In der Spezifikation von TLS werden die folgenden Warnungen definiert:
In der Spezifikation von TLS 1.0 wurden folgende Warnungen ergänzt:[21]

4.3.6    TLS Application Data Protocol
Die Anwendungsdaten werden über das Record Protocol transportiert, in Teile zerlegt, komprimiert und in Abhän-
gigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt. Inhaltlich werden sie von TLS nicht näher interpretiert.

4.3.7    Berechnung des Master Secrets
Aus dem pre-master-secret wird in früheren Protokollversionen mit Hilfe der Hashfunktionen SHA-1 und MD5, in
TLS 1.2 mit Hilfe einer durch eine Cipher Suite spezifizierten Pseudozufallsfunktion das Master Secret berechnet. In
diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein. Die Verwendung beider
Hash-Funktionen sollte sicherstellen, dass das Master Secret immer noch geschützt ist, falls eine der Funktionen als
kompromittiert gilt. In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt.

4.4 Sicherheit
Auf SSL und TLS ist eine Reihe von Angriffen bekannt, die die Sicherheitsgarantien untergraben.[22] Die folgende
Liste stellt einen Teil der bekannten Angriffe dar.

4.4.1    Padding-Oracle-Angriffe
Der Kryptologe Serge Vaudenay entdeckte 2002, dass ein Man-in-the-Middle-Angreifer aus dem Padding einer mit
dem Cipher Block Chaining Mode (CBC) verschlüsselten Nachricht Informationen erhalten kann, die zur Entschlüs-
selung der Nachricht genutzt werden können. Durch gezielte Manipulation einer verschlüsselten Nachricht lernt der
Angreifer, ob der Server ein gültiges Padding meldet und damit ein Teil des Klartexts richtig erraten wurde.[23]
Als Schutzmaßnahme sollte der Server ungültige Nachrichten verwerfen, ohne dabei zu offenbaren, ob das Padding
oder die Nachrichtenauthentizität ungültig war. Allerdings kann ein Angreifer diese Information auch durch eine
Analyse der Antwortzeiten herleiten (Timing-Angriff). Betroffen sind SSL, TLS bis Version 1.2 und DTLS, sofern
eine Cipher Suite mit CBC verwendet wird. Cipher Suites mit Authenticated Encryption sind nicht betroffen.[24]
Im Oktober 2014 demonstrierten Sicherheitsforscher den POODLE-Angriff (Padding Oracle On Downgraded Lega-
cy Encryption), mit dem ein Angreifer ein Versions-Downgrade einer TLS-Verbindung erzwingt, um einen Padding-
Oracle-Angriff gegen SSL 3.0 durchzuführen. Zwecks Kompatibilität wurde SSL 3.0 trotz zu dem Zeitpunkt be-
kannter Sicherheitsschwächen noch von Webbrowsern und anderen Implementierungen unterstützt. Im Nachgang
hat die Internet Engineering Task Force SSL 3.0 als überholt gekennzeichnet[25] und ein Verfahren zum Schutz vor
Downgrade-Angriffen auf TLS spezifiziert.[26]

4.4.2    BEAST
SSL 3.0 und TLS 1.0 verwenden im CBC-Modus einen vorhersagbaren Initialisierungsvektor. Ein Angreifer kann
dadurch mit einem Chosen-Plaintext-Angriff unbekannte Teile des Klartexts ermitteln. Ein Angriffsszenario ist das
Stehlen von HTTP-Cookies, die verschlüsselt übertragen werden. Hierzu muss der Angreifer das Angriffsopfer auf
Sie können auch lesen
NÄCHSTE FOLIEN ... Stornieren