Home Wiki > openSUSE:Security Perfect Forward Secrecy
Sign up | Login

openSUSE:Security Perfect Forward Secrecy

tagline: From openSUSE

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


References