openSUSE:Security Perfect Forward Secrecy
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