Nachdem Edward Snowden offen gelegt hat was die NSA so treibt ist das Sicherheitsbewusstsein in Deutschland gewachsen. Wo fängt man also an mit Sicherheit? Wie wär’s beim Webserver?

Ich benutze nginx als Reverse Proxy und hab dahinter den Apache 2.2 laufen. Zum anpassen gibt’s bei nginx eine Menge Optionen (siehe Dokumentation), aber wie setze ich die richtig und was sagt mir das über die Sicherheit aus?

Zum bewerten der Verbindung eignet sich vor allem der SSL Server Test von Qualys SSL Labs. Mein Server wird mittlerweile mit A+ bewertet jedeglich der Protocol Support und der Key Exchange hat noch ein bisschen potenzial. Das Ziel ist es eine Perfect Forward Secrecy (PFS) Konfiguration zu haben und so eine ziemlich sichere Verbindung zu haben. Orientiert habe ich mich am SSL Server Rating Guide und in Folge dessen hat mir Google bei der Suche nach optimalen Einstellungen sehr geholfen.

Fangen wir mal im Bewertungsraster oben an:

1. Certificate

Dieser Abschnitt ist noch am einfachsten auf 100 Punkte zu bringen, da es hier reicht ein gültiges Zertifikat, d.h. es ist nicht revoked, expired etc.,  zu besitzen und eine gültige Zertifikatkette zu imlpentieren.

2. Protocol Support

Hier kommt die erste Entscheidung: Wie viel Rückwärtskompatibilität möchte ich bieten?

Ich verzichte auf SSLv2 und SSLv3, da diese veraltet sind und mittlerweile alle Clienten mind. TLS1.0 unterstützen. Der Verzicht auf die alten Versionen trägt schonmal dazu bei, dass wir FIPS-ready und PCI compliant werden können.

Die nötige nginx Anweisung ist:

 ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;

3. Key Exchange

Hier wirds was kniffliger, da hier mehrere Faktoren Einfluss haben und durch einen stärkeren Schlüsselaustausch wieder einige Clienten ausgeschlossen werden. Wir möchten ja PFS anbieten und dafür brauchen wir Diffie-Hellman (dh) Parameter. Solche können einfach mit openSSL generiert werden.

openssl dhparam 4096

Hierbei wird ein 4096 Bit dh-Schlüssel erzeugt (als Parameter können auch 1024 oder 2048 angegeben werden).  1024 Bit gilt als gerade noch ausreichend, 2048 Bit als sicher heutzutage und 4096 Bit als zukunftssicher (fürs erste).  Mit dem 4096 Bit Schlüssel wird z.B.  der Internet Explorer unter Windows XP ausgeschlossen, aber wer so ein altes Betriebssystem und Browser benutzt ist selber schuld.

Das nützt uns bis jetzt schon relativ viel, aber auf 100 Punkte komme ich nicht, da mein RSA Key (von SSL Zertifikat) nur 2048 Bit hat. 4096 Bit würden zu 100%  führen, aber je größer die Schlüssel werden, desto mehr Platz benötigen diese in den TCP-Paketen. Außerdem benötigt es mehr CPU-Zeit vom Server die Verbindung zu verschlüsseln.

Den Pfad zum dh-Parameter können wir so festlegen:

ssl_dhparam /etc/dhparam.pem;

4. Cipher Strength

In diesem Bereich können wir festlegen, welche  Cipher Suite dem Clienten angeboten wird. Damit die volle Punktzahl erreicht wird, ist es wichtig, dass  die Cipher  256Bit Verfahren beinhaltet und unsichere Verfahren nicht zulässt.

ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:AES256:!LOW:!MD5:!aNULL:!eNULL:!3DES:!EXP:!PSK:!SRP:!DSS:!RC4;
ssl_prefer_server_ciphers   on;

Die erste Anweisung gibt die Cipher an, welche u.a. alle schwachen Verfahren nicht zulässt (gekennzeichnet mit einem ! vor dem Verfahren) und nur PFS und AES256 Cipher beinhaltet. Die Zweite besagt, dass der Client die vom Server angebotenen Cipher bevorzugen soll.

Konkret ergeben sich folgende Cipher:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA

Von oben nach unten werden die Cipher schwächer.

Im zweiten Block (ECDHE,DHE,RSA) steht das verwendete Schlüsselaustauschverfahren. Heutzutage gilt das Ellipitc Curve Diffie Hellman Exchange (ECDHE) Verfahren als sicherstes. Der Vorteil von ECDH gegenüber von DH ist, dass beim ECDH kürzere Schlüssel berechnet werden müssen, welche aber genau so sicher sind wie ein langer RSA Schlüssel. Zum Beispiel ist ein 384 Bit EC Schlüssel vergleichbar mit einem 7680Bit RSA Schlüssel. Eine Stellschraube für die Berechnung der elliptischen Kurve ist die folgende nginx Anweisung:

ssl_ecdh_curve secp384r1;

Die Anweisung erlaubt uns das Verfahren zur Berechnung festzulegen. Obige Kurve berechnet einen 384Bit großen Schlüssel mit Zufallszahlen als Parameter (erkennbar am r). Das Problem bei der Kurve ist, dass nicht komplett erkennbar ist wie die Kurve entsteht (siehe diesen Heise Bericht). Alternativen findet man z.B. auf dieser Seite, aber viele dieser Kurven sind nicht weit verbreitet und Firefox unterstützt nur die NIST Kurven (z.B. obige).

5. Weitere Empfehlungen

• SSL SessionCaching ermöglicht es, die Session eine Zeit lang aufrecht zuhalten, sodass die Verbindung nicht immer wieder neu aufgebaut werden muss.

      ssl_session_cache shared:SSL:10m;
      ssl_session_timeout         10m;
  

• OCSPStapling ist eine Variante zu überprüfen, ob ein Zertifikat widerrufen worden ist. Bei mir z.B. mitStartSSL und Googles DNS Server zum Auflösen der Adresse

      ssl_stapling on;
      ssl_stapling_responder http://ocsp.startssl.com/sub/class2/server/ca;
      resolver 8.8.8.8;
  

• Strict Tansport Security (HSTS) hier als Apache Anweisung und nur bei sicheren Verbindungen setzen (sprich in derconfig nur bei :443 setzen)

  Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains"

• SPDY! Googles Entwicklung zum Nachfolger von HTTP1.1
• Zu letzt empfehle ich noch openSSL aktuell zu halten, damit Bugs schnell gefixed werden können (z.B. Heartbleed!)

6. Abschließende Bewertung

Der Server sollte nun recht solide SSL Verbindungen aufbauen und ein hohes Maß an Sicherheit bieten. Es stellt sich natürlich immer die Frage wieviel Sicherheit man braucht, da z.B. fraglich ist, ob der „Aufwand“ von AES128 und AES256 gerechtfertigt ist. Zu mal „normale“ Webseiten nicht wie Fort Knox abgesichert sein müssen. Ich für meinen Teil finde eine gute und fortschrittliche Sicherheit wichtig sei es nur damit die NSA oder andere böse Jungs meinen Netzwerkverkehr nicht mitlesen können.

Zu letzt sei noch gesagt, dass alles nichts nützt, wenn der Private Key oder der/die Rechner kompromittiert wurden.