Apache und OpenSSL für Forward Secrecy konfigurieren

Hinweis: Bitte beachten Sie, dass dieser Artikel / diese Kategorie sich entweder auf ältere Software/Hardware Komponenten bezieht oder aus sonstigen Gründen nicht mehr gewartet wird. Diese Seite wird nicht mehr aktualisiert und ist rein zu Referenzzwecken noch hier im Archiv abrufbar.

Forward Secrecy - oder auch Perfect Forward Secrecy - hat vor allem durch die Heartbleed Sicherheitslücke an Popularität gewonnen. Durch die Lücke wurde offenbart, dass es der komplexen SSL-Welt an richtigen Server-Konfigurationen mangelt und Administratoren Hand an legen müssen. Die folgenden Abschnitte widmen sich dem Thema Forward Secrecy und der Konfiguration von Cipher Suites für Apache und OpenSSL.

Perfect Forward Secrecy (PFS)

Die Definition von PFS im Allgemeinen ist, dass die Kompromittierung eines verschlüsselten Nachrichtenaustausches es einem Angreifer nicht erlaubt, beliebige weitere verschlüsselte Nachrichten zu kompromittieren.

Im Kontext von HTTPS-Verbindungen bzw. OpenSSL spricht man auch davon, dass über long-term Keys (Private/Public Keys) ausgehandelte Sessions Keys nicht kompromittiert werden, falls in der Zukunft ein long-term Key kompromittiert wird. Mann will sich also davor schützen, dass in der Vergangenheit verschlüsselt aufgezeichnete Verbindungen entschlüsselt werden können, wenn ein long-term Key (z.B. ein RSA Private Key) kompromittiert wird. Dieses Szenario könnte in der Praxis wie folgt ablaufen:

• Ein Angreifer zeichnet kontinuierlich verschlüsselten HTTPS-Verkehr auf.
• Verwenden Client und Server keine SSL-Cipher-Suite, die auf PFS ausgelegt ist, befinden sich in diesen verschlüsselten Daten die symmetrischen Keys, die zur Verschlüsselung verwendet werden.
• Die symmetrischen Keys sind durch asymmetrische Verschlüsselung (long-term Keys, meist RSA) geschützt.
• Gelangt jedoch der Angreifer an diese asymmetrischen Keys (z.B. durch den Heartbleed Bug), kann er auch den kompletten in der Vergangenheit aufgezeichneten HTTPS-Verkehr entschlüsseln.

Um PFS zu erreichen, bedient man sich dem Diffie-Hellman Schlüsselaustausch-Verfahren - im Zuge von OpenSSL unter Key-Exchange anzutreffen. Mit Diffie-Hellman einigen sich zwei Parteien über einen unsicheren Kanal auf einen gemeinsamen Sitzungsschlüssel (Shared Secret, Session Key), ohne dass dabei der tatsächliche Schlüssel über das unsichere Medium übertragen wird. Zusätzlich verwenden die flüchtigen - ephemeral - Cipher-Varianten von OpenSSL (DHE, ECDHE) für jede Sitzung neue Parameter für die Aushandlung der Schlüssel und ermöglichen dadurch PFS.

OpenSSL konfigurieren

Ciphers Suites abfragen

Um alle von openssl unterstützten Cipher-Suiten anzuzeigen, verwenden Sie auf der Kommandozeile folgenden Befehl:

# openssl ciphers -v 'ALL:COMPLEMENTOFALL'

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
[...]

Wer nähere Informationen zu den Ciphern such, gibt beim openssl ciphers Kommando die Option -V an:

$ openssl ciphers -V 'ALL:COMPLEMENTOFALL@STRENGTH'
          0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD

Die hexadezimalen IDs zu Beginn der Ciphers werden in den eigentlichen RFCs verwendet:

• TLS Standards (en.wikipedia.org)
• Für ECDHE-RSA-AES256-GCM-SHA384 z.B. RFC 5289 (ietf.org)

SSLv3 in dieser Ausgabe bedeutet nicht das Protokoll SSLv3 an sich, sondern nur die Cipher Suiten aus diesem Standard:

The TLSv1.0 ciphers are flagged with SSLv3. No new ciphers were added by TLSv1.1.

Cipher Suite Konfiguration erstellen

Unter Apache werden die Cipher Suites in der Datei /etc/apache2/mods-enabled/ssl.conf statt.

Im ersten Schritt wird sicher gestellt, dass Clients die vom Server präferierte Cipher Suite Liste benutzen, und nicht umgekehrt. Dazu wird in der oben genannten ssl.conf:

SSLHonorCipherOrder     on

eingetragen.

Außerdem wird ein Cipher Suite Konfigurations-String für openssl erstellt, der die Reihenfolge der Cipher Suites für die Clients definiert. Dieser String kann anschließend in die mod-ssl Konfiguration von Apache übernommen werden. Folgende URLs sind bei der Auswahl von Cipher Suiten hilfreich:

• Server Side TLS (wiki.mozilla.org)
• Configuring apache/nginx for forward secrecy (community.qualys.com)

Mit Hilfe der oben genannten Links, wird eine Konfiguration mit Fokus auf:

• PFS
  • Kx=RSA und Kx=ECDH/RSA werden ans Ende gereiht: The ECDHE_ECDSA and ECDHE_RSA key exchange algorithms provide forward secrecy protection in the event of server key compromise, while ECDH_ECDSA and ECDH_RSA do not.
  • Bei SSLv3 ist auch EDH-RSA-DES-CBC3-SHA für PFS ausgelegt, da es DHE_RSA als Key Exchange verwendet.
• Verschlüsselungsstärke (Kein RC4, 3DES am Ende der Suite Liste als Fallback für Windows XP User)
• Deaktivierung unsicherer Cipher Suites (z.B. mit NULL-Authentication, MD5)
• Kompatibilität für ältere Browser (3DES bleibt in der Liste)

Achtung: Eine SSL-Konfiguration zu erstellen ist alles andere als trivial. Es gibt viele Dinge im Kontext der eingesetzten Umgebung zu beachten, die eine perfekte Konfiguration gibt es daher nicht!

Die folgende Cipher Suite Reihung erfüllt die oben genannten Anforderungen:

# vi /etc/apache2/mods-enabled/ssl.conf
SSLHonorCipherOrder on
SSLCipherSuite 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA:EECDH:EDH+AESGCM:EDH:+3DES:ECDH+AESGCM:ECDH+AES:ECDH:AES:HIGH:MEDIUM:!RC4:!CAMELLIA:!SEED:!aNULL:!MD5:!eNULL:!LOW:!EXP:!DSS:!PSK:!SRP'

Die resultierende Cipher Suite Liste finden Sie in der folgenden Datei (openssl -V + Cipher Suite String):

• Openssl-cipher-suite-list.txt

Ohne 3DES

Ohne 3DES werden Browser unter Windows XP ausgeschlossen. Soll dieser Cipher nicht mehr unterstützt werden, verwenden Sie folgenden Konfiguration:

# vi /etc/apache2/mods-enabled/ssl.conf
SSLHonorCipherOrder on
SSLCipherSuite 
'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA:EECDH:EDH+AESGCM:EDH:ECDH+AESGCM:ECDH+AES:ECDH:HIGH:MEDIUM:!RC4:!3DES:!CAMELLIA:!SEED:!aNULL:!MD5:!eNULL:!LOW:!EXP:!DSS:!PSK:!SRP'

OpenSSL Konfiguration prüfen

Die Cipher-Einstellungen für Perfect Forward Secrecy lassen sich mit mehreren Mitteln prüfen:

• ssllabs ssltest (ssllabs.com)
• sslyze (github.com)
• sslscan (sourceforge.net)
• sslaudit (code.google.com)
• testssl.sh (testssl.sh)

Wie gut Sie bei den Tests abschneiden hängt zum einen davon ab, welche Cipher-Suites ihr Server anbietet, welche Suites die Clients unterstützen und auf welche Suites sich die beiden beim HTTPS-Verbindungsaufbau einigen. Es muss daher sicher gestellt sein, dass ihr Server PFS Cipher-Suites beherrscht und in der richtigen Reihenfolge dem Client anbietet.

Hinweis: Nicht nur die OpenSSL-Version, sondern auch die Version des Web-Servers beeinflusst, welche Cipher-Suiten angeboten werden können.

OpenSSL Version

Seit OpenSSL Version 1.0.0h werden die aktuellsten Protokolle TLS 1.1 und TLS 1.2 unterstützt:

• 1.0.1f-1ubuntu2.4 - openssl package in Ubuntu 14.04 Trusty (packages.ubuntu.com)
• 1.0.1-4ubuntu5.16 - openssl package in Ubuntu 12.04 Precise (packages.ubuntu.com)
• 1.0.1e-2+deb7u11 - openssl package in Debian 7 wheezy (packages.debian.org)
• 0.9.8o-4squeeze14 - openssl package in Debian 6 squeeze (packages.debian.org)

Diese Versionsinformationen zeigen auch, dass unter Debian 6 squeeze die aktuellsten TLS -Protokolle nicht unterstützt werden. Das führt bei den ssllabs-Test unter anderem sofort zu einer "Note B" und dem Hinweis : The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B. .

Direkt auf dem System zeigt ein Aufruf von openssl version -a Details an

$ openssl version -a
OpenSSL 1.0.1f 6 Jan 2014
built on: Fri Jun 20 18:54:02 UTC 2014
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall 
-DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

Apache Version

Wie im vorhergehenden Abschnitt erwähnt, beeinflusst auch die Web-Server-Version die verfügbaren Cipher-Suites. Mit Apache ergeben sich dadurch folgende Probleme:

• Ubuntu 12.04 Precise und Debian 6 squeeze halten in Repos Apache-Version 2.2.22-1ubuntu1.7 (ubuntu.com) bzw. 2.2.16-6+squeeze12 (debian.org) vor.
  • ECDHE Support für Apache mod_ssl wurde mit Version 2.2.26 eingeführt. Mit Ubuntu 12.04 Precise und Debian 6 squeeze können daher keine ECDHE Cipher-Suites konfiguriert/angeboten werden.
  • Bei den ssllabs-Tests gelten IE 8-10 / Win 7, IE 11 / Win 7 und IE 11 / Win 8.1 als Referenz-Browser. Jedoch unterstützen IE 8-10 / Win 7 und IE 11 / Win 7 für PFS nur ECDHE oder DSS Cipher Suites. Seit IE 11 / Win 8.1 sind auch TLS_DHE_RSA_GCM Varianten verfügbar, die mit TLS zu PFS führen.
  • Bei den ssllabs führen unter Ubuntu 12.04 Precise bzw. Debian 6 sqeeze diese Umstände zum Hinweis: The server does not support Forward Secrecy with the reference browsers.

Unter der Voraussetzung, dass Packages aus den offiziellen Repos zum Einsatz kommen, ergibt sich zusammenfassend:

Server OS	Client Browser	PFS
Ubuntu 12.04 Precise	IE 8-10 / Win 7	nein (ausser mit DSS Keys/Zertifikaten)
	IE 11 / Win 7	nein (ausser mit DSS Keys/Zertifikaten)
	IE 11 / Win 8.1	ja (z.B. mit TLS_DHE_RSA_WITH_AES_256_GCM_SHA384)
Debian 6 sqeeze	IE 8-10 / Win 7	nein (ausser mit DSS Keys/Zertifikaten)
	IE 11 / Win 7	nein (ausser mit DSS Keys/Zertifikaten)
	IE 11 / Win 8.1	nein (ausser mit DSS Keys/Zertifikaten)
Debian 7 wheezy	IE 8-10 / Win 7	ja
	IE 11 / Win 7	ja
	IE 11 / Win 8.1	ja

Hinweis: Unter Debian 7 wheezy ist zwar auch Apache Version 2.2.22-13+deb7u3 (debian.org) in den Repos, bei diesem Package hat es aber mit der Version 2.2.22-13+deb7u2 einen Backport der ECDHE Ciphers gegeben:

apache2 (2.2.22-13+deb7u2) wheezy; urgency=medium
  * Backport support for SSL ECC keys and ECDH ciphers.

Unter Ubuntu 12.04 Precise gibt es diesen Backport jedoch bis lang nicht!

Cipher Suiten testen

Das bereits erwähnte Werkzeug sslyze testet auch IP-Adressen, und nicht nur Hostnamen:

$ python sslyze.py --regular 192.168.56.105:443|grep -A 1 -B 1 Preferred
  * TLSV1_2 Cipher Suites:
      Preferred:                    
                 ECDHE-RSA-AES256-GCM-SHA384   256 bits      HTTP 200 OK                        
  * TLSV1_1 Cipher Suites:
      Preferred:                       
                 ECDHE-RSA-AES256-SHA          256 bits      HTTP 200 OK                        
  * TLSV1 Cipher Suites:
      Preferred:                       
                 ECDHE-RSA-AES256-SHA          256 bits      HTTP 200 OK                        
  * SSLV3 Cipher Suites:
      Preferred:                       
                 ECDHE-RSA-AES256-SHA          256 bits      HTTP 200 OK

Ob die Verbindung mit einem bestimmten Cipher klappt, prüft auch openssl s_client (weitere Informationen zu s_client siehe TCP Port 443 (https) Zugriff mit openssl überprüfen):

$ openssl s_client -connect 192.168.56.105:443 -cipher ECDHE-RSA-AES256-GCM-SHA384

Aufbau eines Cipher Suite Namens

Im folgenden Beispiel wird ein Cipher der Kategorie LOW näher anlysiert:

$ openssl ciphers -v 'LOW'
EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
[..]

Der Aufbau des Cipher String ist im obigen Beispiel wie folgt:

1. Suite Name (EDH-RSA-DES-CBC-SHA)
2. Minimum Protocol Version (SSLv3)
3. Key Establishment Algorithm Kx=DH
4. Peer Authentication Algorithm Au=RSA
5. Bulk Data Encryption Algorithm Enc=DES
6. Message Authentication Code Mac=SHA1

Einzelnachweise

Autor: Georg Schönberger Georg Schönberger, Abteilung DevOps bei der XORTEX eBusiness GmbH, absolvierte an der FH OÖ am Campus Hagenberg sein Studium zum Bachelor Computer- und Mediensicherheit, Studium Master Sichere Informationssysteme. Seit 2015 ist Georg bei XORTEX beschäftigt und arbeitet sehr lösungsorientiert und hat keine Angst vor schwierigen Aufgaben. Zu seinen Hobbys zählt neben Linux auch Tennis, Klettern und Reisen.