© Galina Peshkova, 123RF

Hinter SSL und TLS stecken komplexe Technologien. Wer kein Krypto-Buch wälzen möchte, um zu einem sicheren HTTPS-Webserver zu kommen, findet in diesem Artikel praxistaugliche Empfehlungen in Sachen Sicherheit, Kompatibilität und Performance.

Die Komplexität von Transportverschlüsselung mit TLS und SSL bietet immer wieder Überraschungen. Das geht selbst dem Autor so, der diese Technologien schon seit den frühen Tagen von Netscape Navigator einsetzt. Wer denkt, er habe SSL endlich begriffen, dem tut sich bald ein neues Rätsel auf, dem er auf den Grund gehen muss.

Die meisten Admins haben aber keine Zeit für lange Recherchen. Sie möchten möglichst rasch zu einer sicheren HTTPS-Website kommen, um sich den nächsten Aufgaben zuzuwenden. Dieser Artikel gibt deshalb eindeutige Ratschläge für die Praxis, die schnell zu einer sicheren Konfiguration führen. Zum Abschluss gibt es Beispieldateien für Apache und Nginx.

1. Algorithmen und Schlüssellängen

Derzeit unterstützt TLS drei Schlüsselalgorithmen: DSA ist längst Vergangenheit, der Elliptische-Kurven-Kryptographie mit ECDSA gehört die Zukunft, doch ältere Clients unterstützen sie nicht. Damit bleibt für die Gegenwart RSA.

Bei der Schlüssellänge dürften für die meisten Zwecke 2048-Bit-RSA-Schlüssel oder 256-Bit-ECDSA-Schlüssel ausreichen. Sie bieten 112 beziehungsweise 128 Bits Verschlüsselungsstärke. Wer für viele Jahre vorsorgen möchte, wählt einen 3072 Bit langen RSA-Schlüssel, der ebenfalls 128 Bit bietet.

2. Schlüsselverwaltung

Bedeutender als die Schlüssellänge ist in der Praxis allerdings, wie der Admin mit den Schlüsseln umgeht. Vieles legt nahe, dass die erfolgreichsten Angriffe auf SSL die Verschlüsselung gar nicht knacken, sondern sie schlicht umgehen. Wer in einen Server einbrechen kann, um den privaten Schlüssel zu stehlen, oder auf anderem Wege Zugriff auf ihn erhält, braucht sich nicht die Zähne an der Kryptographie auszubeißen.

Die privaten Schlüssel müssen geheim bleiben. Auf diese wertvollen Dateien sollte nur ein möglichst kleiner Kreis von Mitarbeitern Zugriff haben, der gerade groß genug ist, um einen reibungslosen Betrieb zu gewährleisten.

Daneben sollte der Admin die Schlüssel per Passwort schützen und schon beim Erzeugen eine Passphrase eingeben. Das reduziert das Risiko, falls ein Backup des Systems in falsche Hände gerät.

Eine Kopie der Schlüssel sollte der Verantwortliche an einem sicheren Ort aufbewahren. Den Schlüssel für einen einzelnen Server zu verlieren ist nicht weiter schlimm, denn ein neuer lässt sich leicht generieren. Betreibt man aber eine eigene Certificate Authority (CA), sind deren Schlüssel nur äußerst aufwändig zu ersetzen.

3. Das Zertifikat

Das SSL-Zertifikat sollte von einer seriösen Zertifizierungsstelle stammen, doch zu viele Gedanken braucht sich niemand über die Auswahl zu machen. Bei Domain-validierten (DV) Zertifikaten darf der günstigste Preis entscheiden. Bei großem öffentlichen Interesse an der Site machen Zertifikate mit Extended Validation (EV) mehr Eindruck, erhöhen die technische Sicherheit aber kaum.

Das Zertifikat muss unbedingt alle verwendeten Hostnamen enthalten. Dazu gehören mindestens die Varianten mit und ohne WWW-Präfix, also »example.com« und »www.example.com« . Weitere Hinweise zur Verwendung für mehrere Hostnamen gibt der Kasten “Key- und Certificate-Sharing”.

Die Zertifizierungskette muss vollständig sein. Unterbrochene Ketten gehören zu den häufigsten Mängeln. Manche Browser können zwar damit umgehen, doch sie führen leicht zu schwer nachvollziehbaren Fehlern.

Die CA sollte ihre Zertifikate mittels SHA-256 unterzeichnen. Daneben sollte sie Informationen zum Zurückziehen mittels Certificate Revocation Lists (CRL) und Online Certificate Status Protocol (OCSP) einbetten. Wer selbst die Zertifizierungsstelle mimen will, liest den Kasten “Selbst signiert oder mit privater CA”.

Selbst signiert oder mit privater CA

Dieser Artikel geht davon aus, dass das verwendete Zertifikat von einer öffentlichen CA stammt. Daneben gibt es die Möglichkeit, das Zertifikat selbst zu signieren oder eine eigene Zertifizierungsstelle zu betreiben, die die hauseigenen Server mit Zertifikaten versorgt.

Diese drei Vorgehensweisen eignen sich für unterschiedliche Einsatzszenarien. Für eine öffentliche Website kommt ausschließlich ein Zertifikat von einer öffentlichen Zertifizierungsstelle in Frage.

Ein selbst signiertes Zertifikat lässt sich nur sehr eingeschränkt verwenden. Man kann es nämlich nur im Zusammenspiel mit Firefox sicher einsetzen. Ausschließlich der Mozilla-Browser erlaubt es dem Anwender nämlich, Ausnahmen für solche Zertifikate dauerhaft zu speichern (Abbildung 1). Hat er das ein Mal getan, ist er bei allen späteren Besuchen derselben Website sicher.

Abbildung 1: Warnung bei einem selbst signierten Zertifikat. Allein der Browser Firefox kann es sich für die Zukunft merken und sichert dem Anwender damit zu, dass es sich nicht geändert hat.

Andere Browser dagegen machen bei jedem Besuch eine neue Bestätigung erforderlich. Wer dabei nicht jedes Mal den Fingerprint des Zertifikats prüft – und wer tut das schon – bewegt sich auf dünnem Eis.

Aus diesen Gründen ist es empfehlenswert, eine eigene Certificate Authority zu betreiben, wenn man kein Zertifikat bei einer öffentlichen CA erwerben möchte. Das ist zwar zunächst aufwändiger, doch sobald die Infrastruktur steht und der Rootschlüssel sicher an alle Anwender verteilt ist, arbeitet sie so zuverlässig wie der Rest der PKI-Welt.

4. Protokolle

Eine öffentliche Website muss die Protokolle TLS 1.0, TLS 1.1 und TLS 1.2 unterstützen. SSL 2 ist obsolet und unsicher. SSL 3 gilt ebenfalls als veraltet und ist zwar nicht an sich unsicher, lässt aber viele wichtige Features modernerer Protokolle vermissen. Daher empfiehlt es sich, SSL 3 zu deaktivieren, wenn es keinen besonderen Hinderungsgrund gibt. So gut wie alle Clients unterstützen mindestens die TLS-Version 1.0.

5. Cipher-Suite-Präferenz

Die Möglichkeit, dem Server Cipher-Suites vorzugeben, die er bevorzugt verwenden soll, ist ein sehr nützliches Feature. Auf diese Weise kommen für moderne Clients die sichersten Verfahren zum Einsatz, während ältere Clients mit geeigneten Alternativen ebenfalls noch funktionieren. Da TLS die Integrität des Handshake sicherstellt, kann es dabei außerdem nicht passieren, dass ein Angreifer den Präferenz-Mechanismus missbraucht, um schwächere Verschlüsselung zu erreichen.

6. Wahl der Cipher-Suite

Es empfehlen sich starke Cipher, die 128-Bit-Verschlüsselung praktizieren. Das gilt für AES und Camellia gleichermaßen, aber AES bietet den Vorteil, dass es sich mit authentifizierten Suites einsetzen lässt, die den GCM-Betriebsmodus verwenden. Zudem ist es schneller. Die authentifizierten Suites stellen die beste Option für TLS dar und vermeiden potenziell unsichere Cipher-Block-Chaining-Suites. 3DES bietet 112 Bits Stärke und eignet sich für die Interoperabilität mit älteren Clients. RC4 dagegen sollte jeder Admin meiden, es ist unsicher.

Cipher-Block-Chaining-Suites, die SHA-256 und SHA-384 zur Validierung der Integrität verwenden, sollte er ebenfalls außen vor lassen. Sie sind merklich langsamer als SHA-1, bringen aber keinen bedeutenden Sicherheitsvorteil. Die Mängel in SHA-1 spielen in diesem Fall keine Rolle, weil die Validierung HMAC einsetzt. GCM-Suites tragen zwar ebenfalls SHA-256 und SHA-384 im Namen, doch da sie als authentifizierte Suites anders arbeiten, kommt der Performance-Unterschied nicht zum Tragen.

Beim Schlüsselaustausch per ECDHE bietet die Kurve »secp256r1« die beste Performance und 128-Bit-Security. Andere Kurven sind entweder viel langsamer oder schlecht unterstützt. Gegenüber DHE ist stets ECDHE zu bevorzugen, um auch bei 2048 Bit Schlüssellänge gute Performance zu erreichen.

Den RSA-Schlüsseltausch sollte der Admin besser nicht einsetzen, ohne durch äußere Umstände dazu gezwungen zu sein, denn er bietet keine Forward Secrecy. Sicherer ist es, im Namen der Cipher-Suite nach dem Kürzel ECDHE oder DHE zu suchen. So erreicht man Forward Secrecy, was bedeutet, dass jede einzelne Verbindung zur Website mit einem individuellen Schlüssel geschützt ist.

Ohne Forward Secrecy hängt die Sicherheit aller Verbindungen von der Vertraulichkeit des privaten Serverschlüssels ab. Sollte dieser je gestohlen oder geknackt werden, lässt sich gespeicherter Netzwerkverkehr im Nachhinein entschlüsseln. Eine geeignete Konfiguration schließt das aus.

Für die Open-SSL-Version 1.0.1 mit aktivierter Elliptic-Curve-Kryptographie empfiehlt sich nach all diesen Erwägungen die Auswahl und Reihenfolge der Suites aus Listing 1. Die Auflistung ist durch eine Leerzeile in zwei Gruppen aufgeteilt. Wer einen Anwenderkreis mit moderner Software hat, darf auf die letzten fünf Suites verzichten. Sie verwenden den RSA-Schlüsseltausch und bieten keine Forward Secrecy. RC4-SHA sollte am Ende hinzufügen, wer es unbedingt zur Interoperabilität benötigt.

01 ECDHE-ECDSA-AES128-GCM-SHA256
02 ECDHE-ECDSA-AES256-GCM-SHA384
03 ECDHE-RSA-AES128-GCM-SHA256
04 ECDHE-RSA-AES256-GCM-SHA384
05 DHE-RSA-AES128-GCM-SHA256
06 DHE-RSA-AES256-GCM-SHA384
07 ECDHE-ECDSA-AES128-SHA
08 ECDHE-ECDSA-AES256-SHA
09 ECDHE-ECDSA-DES-CBC3-SHA
10 ECDHE-RSA-AES128-SHA
11 ECDHE-RSA-AES256-SHA
12 ECDHE-RSA-DES-CBC3-SHA
13 DHE-RSA-AES128-SHA
14 DHE-RSA-AES256-SHA
15 EDH-RSA-DES-CBC3-SHA
16
17 AES128-GCM-SHA256
18 AES256-GCM-SHA384
19 AES128-SHA
20 AES256-SHA
21 DES-CBC3-SHA

Wie die Konfiguration der Suites für bestimmte Server konkret aussieht, zeigen Listings weiter unten in diesem Artikel.

7. OCSP-Stapling

Die Stapling-Erweiterung des Online Certificate Status Protocol (OCSP) erlaubt es dem Betreiber einer Website, Rückrufinformationen zu Zertifikaten auf dem eigenen Server anzubieten. Ohne Stapling muss ein Client die CA kontaktieren, um sicherzustellen, dass ein Zertifikat nicht zurückgezogen wurde. Stapling macht die Site schneller, die Anwender brauchen der CA nicht mitzuteilen, welche Seiten sie besuchen, und die Site wird unabhängig von der Performance des OCSP-Responders der Zertifizierungsstelle.

8. Schadensbegrenzung

Wie bei jeder Software besteht auch beim TLS/SSL-Stack die Möglichkeit, dass ernsthafte Sicherheitslücken auftauchen. In den meisten Fällen lassen sich die Löcher mit Patches stopfen. Im Interesse der Sicherheit sollte sich der Admin mit den wichtigsten Angriffen gegen Transportverschlüsselung vertraut machen, die unter den Namen Beast, Crime, Time, Breach, RC4-Bias, Lucky 13 und Triple-Handshake-Attacke bekannt sind.

9. Heartbleed

Den Namen Heartbleed trägt eine Sicherheitslücke in der weit verbreiteten freien Krypto-Bibliothek Open SSL, die seit April 2014 bekannt ist [1]. Sie hat nichts mit Kryptographie an sich zu tun, sondern wurde durch einen Programmierfehler verursacht. Die Folgen für einen verwundbaren Server sind verheerend, denn über das Loch können Angreifer an den privaten Schlüssel gelangen. Fertige Angriffswerkzeuge gibt es zum Herunterladen, daher sollte jeder Serverbetreiber mit Heartbleed vertraut sein.

Folgende Schritte muss der Admin beachten, wenn er entdeckt, dass sein Server durch Heartbleed verwundbar ist:

• Die betroffenen Systeme aktualisieren, um die Lücke zu schließen.
• Neue private Schlüssel generieren, neue Zertifikate beschaffen und die alten zurückrufen.
• Beim Einsatz von Sessiontickets die Ticketschlüssel ersetzen.
• Beurteilen, ob andere vertrauliche Daten durch die Lücke entwendet wurden. In den ausgelesenen Speicherbereichen können sich zum Beispiel Passwörter befunden haben. Dann sollte er die Anwender benachrichtigen und zum Ändern auffordern.

10. HTTP

Obwohl SSL und TLS zum Sichern beliebiger verbindungsorientierter Protokolle entwickelt wurden, war das wichtigste Bedürfnis, HTTP zu schützen. Auch heute ist der verschlüsselte Zugriff auf Websites der häufigste Anwendungsfall für TLS. Das WWW hat sich allerdings von einem einfachen System zum Ausliefern von Dokumenten zu einer komplexen Anwendungsplattform entwickelt. Das macht auch den Einsatz von Transportverschlüsselung komplizierter.

10.1 Kein Mixed Content

Verschlüsselung gehört nicht zur Standardausstattung von HTTP. Daher verzichten auch viele Websites darauf, obwohl sie gerechtfertigt wäre. Oft liegt der Grund dafür im zusätzlichen Aufwand und erforderlichen Know-how. Manche Webbrowser komplizieren die Situation zusätzlich, indem sie es Anbietern erlauben, sichere und unsichere Inhalte innerhalb einer HTML-Seite zu mischen.

Aus Sicherheitsgründen ist es am besten, Transportverschlüsselung für die komplette Domain einschließlich ihrer Subdomains einzurichten. Mittels HTTP Strict Transport Security (HSTS) verhindert der Admin zudem Mixed Content von derselben Domain, mittels Content Security Policy unsichere Inhalte von Dritten.

10.2 Cookie Security

HTTP-Cookies, die der Entwickler nicht als sicher deklariert hat, reißen eine Sicherheitslücke ins Konzept. Selbst bei vollständig verschlüsselten Websites kann ein Angreifer im Netzwerk sie auslesen. Ein Punkt, der bei der Qualitätssicherung in Webprojekten besondere Aufmerksamkeit verdient.

Darüber hinaus machen es zu lockere Cookie-Regeln einem Angreifer leicht, Cookies in andere Webanwendungen zu injizieren. Typischerweise verwendet er dazu eine Anwendung auf einer verwandten Subdomain, er greift also »www.example.com« über »blog.example.com« an oder verwendet eine erfundene Subdomain. An vertrauliche Informationen gelangt er so zwar nicht, aber ein geschickter Angreifer könnte damit seine Berechtigungen in der Anwendung erhöhen.

Als Gegenmittel empfehlen sich Cookie-Verschlüsselung oder eine Integritätsprüfung. Dabei ist die erste Maßnahme sicherer, die zweite lässt sich aber auch dann einsetzen, wenn die Cookies für Javascript lesbar sein sollen.

10.3 HSTS

HTTP Strict Transport Security (HSTS), beschrieben in RFC 6797 [2], setzt strenge Regeln für die Verschlüsselung von Websites um. Dabei teilt der Server kompatiblen Browsern die Policies im HTTP-Response-Header mit (Abbildung 2). Ist HSTS aktiviert, kommuniziert ein konformer Webbrowser ausschließlich über TLS mit einer Website. Das stopft einige Sicherheitslöcher, die ansonsten kaum zu schließen sind: Besuche über Plaintext-Bookmarks oder -Links, unsichere Cookies, SSL-Stripping und Mixed Content auf derselben Domain.

Abbildung 2: Twitter teilt per HTTP-Header mit, dass es HTTP Strict Transport Security (HSTS) einsetzt.

Daneben forciert Strict Transport Security einen sicheren Umgang mit ungültigen Zertifikaten. Ohne HSTS lassen Webbrowser bei ungültigen Zertifikaten den Anwender entscheiden, was zu tun ist. Die meisten Benutzer können aber nicht zwischen Angriffen und Fehlkonfigurationen unterscheiden. Das macht sie zu potenziellen Opfern von Netzwerkangriffen. Mit HSTS dagegen bleiben ungültige Zertifikate ungültig und lassen sich nicht umgehen. Am sichersten ist es, Strict Transport Security für eine komplette Domain inklusive ihrer Subdomains zu aktivieren.

Konfigurationsempfehlungen

Die folgenden Beispielkonfigurationen setzen Unterstützung für Elliptic Curve Cryptography (EC) voraus, die für ein zeitgemäßes SSL-Deployment erforderlich ist. Leider ist sie nicht überall verfügbar. Im Apache-Webserver hielt sie mit Version 2.2.6 Einzug, viele ältere Installationen enthalten das Feature also nicht. Doch die Versionsnummer allein ist nicht aussagekräftig.

Manche Distributionen wie etwa Debian haben EC für ihre Apache-Pakete zurückportiert. Der Blick in die Release Notes ist also unerlässlich. Bis vor kurzem haben Fedora und Red Hat EC noch deaktiviert, hier sollte inzwischen ein Update Abhilfe schaffen. Im Notfall kann der Admin Apache 2.4.x aus den Quellen mit statisch gelinktem Open SSL übersetzen. Der Autor gibt unter [3] eine Anleitung.

Listing 2 zeigt die Anweisungen für die globale SSL-Konfiguration. Sie ist bei unterschiedlichen Distributionen in unterschiedlichen Dateien zu finden. Beim Orginal-Quelltext von Apache 2.4.x ist das die »$SERVER_ROOT/conf/extra/httpd-ssl.conf« , unter Debian und Ubuntu »/etc/apache2/mods-available/ssl.conf« und bei Red Hat »/etc/httpd/conf.d/ssl.conf« . Die SSL-Konfigurationsanweisungen für Apache sind im Mod_SSL-Handbuch nachzulesen [4].

01 SSLProtocol all -SSLv2 -SSLv3
02 SSLHonorCipherOrder On
03 SSLCipherSuite "ECDHE-ECDSA-AES128-GCM-SHA256 \
04  ECDHE-ECDSA-AES256-GCM-SHA384 \
05  ECDHE-RSA-AES128-GCM-SHA256 \
06  ECDHE-RSA-AES256-GCM-SHA384 \
07  DHE-RSA-AES128-GCM-SHA256 \
08  DHE-RSA-AES256-GCM-SHA384 \
09  ECDHE-ECDSA-AES128-SHA \
10  ECDHE-ECDSA-AES256-SHA \
11  ECDHE-ECDSA-DES-CBC3-SHA \
12  ECDHE-RSA-AES128-SHA \
13  ECDHE-RSA-AES256-SHA \
14  ECDHE-RSA-DES-CBC3-SHA \
15  DHE-RSA-AES128-SHA \
16  DHE-RSA-AES256-SHA \
17  EDH-RSA-DES-CBC3-SHA \
18  AES128-GCM-SHA256 \
19  AES256-GCM-SHA384 \
20  AES128-SHA \
21  AES256-SHA \
22  DES-CBC3-SHA"
23
24 # Only with Apache 2.2.24+ and Apache 2.4.3+
25 SSLCompression Off
26
27 SSLSessionCache shmcb:/path/to/ssl_scache(1024000)
28 SSLSessionCacheTimeout 3600
29
30 # Only with Apache 2.4.x
31 SSLUseStapling On
32 SSLStaplingCache shmcb:/path/to/stapling_cache(128000)
33 # HSTS policies are persistent; learn more
34 # about HSTS before enabling the following
35 # rule for best security.
36 #Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

01 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
02 ssl_prefer_server_ciphers on;
03 ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-DES-CBC3-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA ECDHE-RSA-DES-CBC3-SHA DHE-RSA-AES128-SHA DHE-RSA-AES256-SHA EDH-RSA-DES-CBC3-SHA AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA AES256-SHA DES-CBC3-SHA";
04 ssl_session_cache shared:ssl_session_cache:1M;
05 ssl_session_timeout 60m;
06 # Only with Nginx 1.4.x and newer
07 ssl_stapling on;
08
09 # HSTS policies are persistent; learn more about HSTS
10 # before enabling the following rule for best security.
11 #add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

In Listing 3 findet sich die Konfiguration für den Webserver Nginx. Die Anweisungen gehören in den »http« -Abschnitt der Datei, die meist unter »/etc/nginx/nginx.conf« zu finden ist. Bei der Anweisung »ssl_ciphers« müssen übrigens alle Angaben in einer einzigen Zeile stehen. Die SSL-Dokumentation für Nginx ist unter [5] verfügbar.