Perfect Forward Secrecy für Webservices

Abstract

In meinem Blog beschreibe ich das Thema Perfect Forward Secrecy (PFS) generell. In diesem Beitrag dokumentiere ich speziell Elliptic Curve Cryptography basierte PFS für Websservices, wobei ich mich bemühe, die Informationen allgemein verständlich zu halten. Links verweisen auf eingehende Dokumentationen.

In meinem Blog beschreibe ich das Thema Perfect Forward Secrecy (PFS) generell, aber auch den Einsatz von PFS mittels Diffie-Hellman Ephemerals. In diesem Beitrag dokumentiere ich speziell Elliptic Curve Cryptography basierte PFS für Websservices, wobei ich mich bemühe, die Informationen allgemein verständlich zu halten. Links verweisen auf eingehende Dokumentationen.

Elliptic Curve Cryptography (ECC)

Es ist recht einfach, einen Kreisbogen zu konstruieren. Dazu werden nur zwei Werte benötigt, die Distanz zwischen einem Punkt auf dem Kreisauschnitt und dem Kreismittelpunkt sowie ein Winkelmaß, das Beginn und Ende des Kreisausschnitts bestimmt. Um eine Ellipse oder auch einen elliptischen Bogen zu konstruieren, sind viele Punkte und Daten erforderlich, denn eine Ellipse lässt sich nur punktweise konstruieren. Elliptic Curve Cryptography macht sich diese Erkenntnis zu Nutze, indem nur eine zufällige Auswahl von Punkten zur Generierung eines Keys herangezogen werden. Die mathematischen Funktionen und Operationen und den Aufbau einer named_curve beschreibt RFC 4492, Abschnitt 5.4 . Auch Wikipedia beschreibt die Problemstellung durch elliptische Kurven sehr ausführlich, so dass ich mich hier auf die Beschreibung der Anwendung beschränke. Die Federal Information Processing Standards (FIPS) beschreiben in dem Digital Signature Standard FIPS PUB-186-4 Section 6 den Aufbau von elliptischen Kurven. In Appendix 6 werden für das US Governement ausgewählte Kurven empfohlen.

Der kryptographische Einsatz von elliptischen Kurven ist nicht unumstritten, da durchaus die Möglichkeit besteht, in einer named_curve die zufällige Auswahl von Punkten zu beeinflussen und so das Ergebnis vorhersehbar zu gestalten. Es gibt mehrere Institutionen, die bei der Internet Assigned Numbers Authority IANA registrierte Kurven bereitstellen. Zum weiterführenden Verständnis und zur Hilfestellung bei der Auswahl der richtigen Kurve hilft SafeCurves .

Wie prüfe ich, welche PFS-Methode Webserver und Browser aushandeln?

Als Tool der Ersten Wahl zur Prüfung von TLS-Sessions bietet sich Openssl s_client an.

openssl s_client -msg -cipher 'ECDH' -connect www.sys4.de:443 | grep -A1 'ServerKeyExchange'

TLS 1.2 Handshake [length 014d], ServerKeyExchange
0c 00 01 49 03 00 17 41 04 2f ba a8 82 a5 42 99
...

In der folgenden Tabelle werden die obigen Hex-Werte erläutert, nachzulesen in RFC 4492, Section 5.4 ServerKeyExchange.

Hex-Wert Dezimal Beschreibung
0 1 explicit prime
c 2 explicit char2
00 01 49 329 bit Key length
03 curve type named _curve
00 17 23 secp256r1

RFC 4492, Section 5.1.1 (Supported Elliptic Curve Extension) listet unter der Nummer 23 den Type secp256r1, auch unter der Bezeichnung P-256 bekannt. Die nachstehende Tabelle listet die von der IETF empfohlenen Kurven auf.

Supported Elliptic Curves Extension
Supported Elliptic Curves Extension
1 sect163k1   9 sect283k1   17 secp160r2
2 sect163r1   10 sect283r1   18 secp192k1
3 sect163r2   11 sect409k1   19 secp192r1
4 sect193r1   12 sect409r1   20 secp224k1
5 sect193r2   13 sect571k1   21 secp224r1
6 sect233k1   14 sect571r1   22 secp256k1
7 sect233r1   15 secp160k1   23 secp256r1
8 sect239k1   16 secp160r1   24 secp384r1
25 secp521r1  

Keys mit der Endung k verwenden Algorithmen von Neal Koblitz, die Endung r steht für random.

Eine Arbeitsgruppe, die Standards for Efficient Cryptography Group SECG hat eine lesenswerte Empfehlung der Domain Parameter für elliptische Kurven veröffentlicht.

Welche Kurven unterstützt OpenSSL?

Dies ist relativ leicht mit dem Tool ecparam der OpenSSL-Tools zu ermitteln:

$ openssl ecparam -list_curves

Die ausgegebene Liste der Kurven ist entschieden länger als die von der IETF empfohlenen Kurven.

Welche dieser Kurven soll man nun für seine eigenen Anforderungen auswählen? Hierbei gilt es zu bedenken, dass Kurvenberechnung hohe Rechnerleistungen erfordert. Weiterhin ist die erforderliche TCP-Transportleistung zu berücksichtigen. Es gilt also, einen guten Mittelwert zu wählen, der sowohl die eigenen Sicherheitsanforderungen erfüllt als auch die Transportleistung nicht beeinträchtigt. Für Browser auf mobilen Endgeräten gelten also andere Anforderungen als an den Browser einer Workstation. Die folgende Tabelle zeigt in der ersten Spalte die zur Generierung eines Transport-Keys bereitgestellte Sicherheitsniveaus, die anderen beiden Spalten sind wohl selbsterklärend.

Symetric Key
(bits)
RSA und DH Key
Size (bits)
EC Key Size
(bits)
80 1024 160
112 2048 224
128 3072 256
192 7680 384
256 15260 521

EC-Keys mit 256 Bit oder 384 Bit scheinen wohl für die meisten Webservices die geeignete Wahl zu sein.

Konfiguration des Webservers

Hierzu habe ich nur verlässliche Informationen zu nginx und Apache. Beide Webserver setzen als Standardeinstellung prime256v1 ein, so dass keine weitere Konfiguration notwendig ist. Wer allerdings eine andere named_curve einsetzen möchte, hat die Möglichkeit, dies zu konfigurieren.

nginx

ssl_certificate                myHost.crt;
ssl_certificate_key            myHostKey.key;
ssl_ecdh_curve                 secp384r1;
# ssl_ecdh_curve               secp256k1; # dies nur als Alternative
ssl_ciphers                    TLSv1.2:SSLv3:HIGH:!RC4:!SHA:!MD5;
ssl_prefer_server_ciphers      on;

Apache

Im Apache Change Log für Version 2.4.7 findet sich der Eintrag:

mod_ssl: Improve handling of ephemeral DH and ECDH keys by allowing custom parameters to be configured via SSLCertificateFile

Zur individuellen Konfiguration von Apache ab Version 2.4.7 kann also ein Key-File mit ECC-Parametern erzeugt werden:

$ openssl ecparam -name secp384r1 -out ecparam.key -genkey
$ openssl ecparam -in ecparam.key -noout -text
  ASN1 OID: secp384r1

Mit dem Befehl in der zweiten Zeile lässt sich ecparam,key auslesen, das Ergebnis steht in der dritten Zeile.

Der generierte Key muss dann mittels des Konfigurationsparamters SSLCertificateFile in die Apache-Konfiguration eingepflegt werden.

SSLCertificateFile /path/to/host.crt
SSLCertificateKeyFile /path/to/host.key
SSLCertificateFile /path/to/ecparam.key
SSLCipherSuite     TLSv1.2:SSLv3:HIGH:!RC4:!SHA:!MD5
SSLHonorCipherOrder on

Note

Die Konfiguration von nginx und Apache ist hier nur beispielhaft. Es liegt im Ermessen eines jeden Administrators, sein System verantwortungsvoll den jeweiligen Anforderungen anzupassen.

Empfehlungen für eine Cipher-Liste

OpenSSL stellt mit dem Tool ciphers eine einfache Möglichkeit, eine Vorauswahl für eine eigene Liste von Ciphers zu erstellen. Die simpelste Möglichkeit ist:

openssl ciphers TLSv1.2:SSLv3:HIGH:-RC4:-SHA:-MD5 -v

Die nachstehende Cipher-Liste ist eine von mir getroffene reduzierte Auswahl.

  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-SHA256
  • ECDHE-RSA-AES256-SHA384
  • ECDHE-RSA-RC4-SHA
  • ECDHE-RSA-AES128-SHA
  • ECDHE-RSA-AES256-SHA
  • ECDHE-RSA-DES-CBC3-SHA
  • DHE-DSS-AES128-GCM-SHA256
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES-SHA256
  • DHE-DSS-AES128-SHA256
  • ADH-AES128-SHA256
  • ADH-AES128-GCM-SHA256
  • AES128-GCM-SHA256
  • AES256-GCM-SHA384
  • AES128-SHA256
  • AES256-SHA256

Die folgenden Ciphers sollten vermieden werden. Es gibt allerdings noch Browser der älteren Generation, die noch diese Ciphers benötigen. Der geneigte Administrator mag selbst über das Risiko entscheiden, dass das Anbieten dieser Ciphers in sich birgt.

  • RC4-SHA
  • AES128-SHA
  • AES256-SHA
  • DES-CBC3-SHA
Dieter Klünter, 09. February 2014

   ecc    tls    pfs