# openSUSE:Security Perfect Forward Secrecy

## Contents

# TLS with Perfect Forward Secrecy

Given recent reports about mass scale network surveillance and privacy breaches, one
particular feature in network traffic encryption
has become more interesting and mandatory, namely *Perfect Forward Secrecy* (PFS).

Since there is a lot of confusion what PFS is about and what possible limitations are, we will outline the most important parts with respect to SUSE products.

The wikipedia page Perfect Forward Secrecy has more background and references about PFS.

During the SSL/TLS handshake (TLS is basically SSL version 3.1) which is necessary
to establish a secure connection, a so called *pre-master-secret* is generated
and exchanged. This secret is used for deriving encryption keys (**Enc**) for the upcoming
secure communication based on symmetric algorithms such as AES.
Traditionally TLS is using (public) RSA keys inside its X509 certificates which are
sent to the client, among other things such as a list of supported symmetric ciphers etc.
The client uses this public RSA key of the server to encrypt the *pre-master-secret* before
it is sent to the server.
Attackers which recorded these handshakes and which are eventually able to obtain
the private part of the RSA key can decrypt all communication that they are hold of.
Even after a lot of time (decades) has passed between recording and breaking the key.

PFS is about to change that.

PFS is implemented via *Ephemeral Keying* (EK). Both terms can be used interchangeably.
EK means that the key used for encrypting the *pre-master-secret* is unique to each handshake.
PFS splits the process of encrypting the Key-Exchange (**Kx**) from the process of protecting
its integrity. For TLS this means that RSA can still be used to protect (**Au**) the integrity
of the Kx by signing/verifying the exchanged messages.
For transfering the encryption-secret a different algorithm
is used: Diffie Hellmann (DH). Because of its Ephemeral nature (keys are unique to the Kx), its called DHE or formerly EDH, meaning the same.

You can read more about the DH Kx here: DH Kx

As there are now four different algorithms involved with the TLS handshake,
(the forth algorithm is the Hash function (**Mac**) used with RSA for signing, such as SHA)
one says that the cipher used is DHE + RSA + AES + SHA or DHE_RSA_AES_SHA.

As generating new DH Keys on the fly for each new client is a quite expensive operation, a faster approach using Elliptic Curve Cryptography (ECC) was developed which allows for use of shorter keys, speeding up the computation during the Kx, named ECDHE or EECDH): ECDHE.

Note that ECC per se has nothing to do with PFS. PFS works still *Perfect* without
ECC, yet its a bit slower as it is using larger keys. The E with respect
to PFS inside ECDHE or DHE means *Ephemeral*, not Elliptic!

Other algorithms which can subsitute RSA for the Au are DSS or ECDSA.

## Availability

To check which ciphers your OpenSSL installation supports, you can use the **openssl** program. The OpenSSL API allows programs such as **apache** to set a list of prefered
ciphers. By default, OpenSSL orders them by itself, but you can force PFS by
choosing an appropriate cipher list. For a remote site that configured
its webserver to use PFS, an example connect shows:

user@host:~> openssl s_client -connect www.ccc.de:443 [...] SSL handshake has read 4818 bytes and written 646 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 4096 bit [...]

The **DHE-RSA-AES256-SHA** shows that Ephemeral DH is used, which is PFS.

SUSE Linux Enterprise 11 currently installs openssl version 0.9.8j, which supports
Diffie Hellman Kx (DHE) and which makes it PFS capable, even if ECC is not supported.
You can check this with **openssl** command:

user@sle11-sp1:~> openssl ciphers -v DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DES-CBC3-MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5 EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export

openSUSE 12.2 and newer versions use openssl 1.0.1 and so support TLS versions 1.0 up to 1.2 with DHE as well as ECDHE, among others.

## Apache configuration

The SSL Vhost has a setting to limit the available cryptographic ciphers by specifying **SSLCipherSuite**.

Currently the suggested string in the template is

SSLCipherSuite ALL:!aNULL:!eNULL:!SSLv2:!LOW:!EXP:!MD5:@STRENGTH

For current openSUSE and also SUSE Linux Enterprise Server, please follow the instructions in the following Qualys blog post or the Mozilla Server Side TLS recommendation page.

You can find the list of ciphers that you can specify for the **SSLCipherSuite**
here

You can verify the ciphers used locally on your machine with the *openssl* commandline tool,

openssl ciphers -v 'kEDH:ALL:!kRSA:!ADH:!RC4:!LOW:!EXP:HIGH:!MD5:!aNULL:@STRENGTH' DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1

## Limitations

The P inside PFS is not really perfect. Even if said before that attackers cannot decrypt sessions that have been recorded before the RSA key has been compromised, there are some pitfalls:

If attackers can solve the underlying Discrete Logarithm problem on which
the DH Kx is based, they *can* decrypt recorded sessions backward-in-time.
PFS only protects you against a compromise of your servers RSA key.

The same is true for the symmetric algorithm which is in use. If you use single DES,
not even PFS can protect you. The above cipher-suite excludes such weak cipers
via the `!LOW`

and `!EXP`

specification.

PFS does not protect against Man-on-a-side (MoaS) or Man-in-the-Middle (MiM) attacks,
as the DH happens with the attacker, not the legit endpoint. Therefore,
the attacker already has the *pre-master-secret* at the time the handshake happens.
To prevent such attacks you have to setup your own certificate authority (CA), as
recently has become clear that the public CA's can easily be forced by their juristication
to sign wrong/evil certificates and that network traffic is indeed re-routed in order to
mount such attacks:
petrobras