Skip to content →

Perfect Forward Secrecy pour Apache

Lors de l’utilisation d’un protocole comme SSL/TLS pour le chiffrement et la sĂ©curisation des donnĂ©es sur des rĂ©seaux non sĂ»rs, il est important de garantir la confidentialitĂ© totale des communications, mĂŞme en cas de capture du trafic chiffrĂ©.

TLS n’est en effet pas un protocole unique, mais une multitude de briques permettant la sĂ©curisation des Ă©changes, grâce Ă  :

  • L’authentification du serveur (et optionnellement du client). On utilise en gĂ©nĂ©ral un certificat x509v3 dĂ©livrĂ© par une autoritĂ© de certification.
  • La confidentialitĂ© des donnĂ©es, en utilisant les suites de chiffrement disponibles dans les CipherSpecs.
  • L’intĂ©gritĂ© des donnĂ©s, en utilisant des fonctions de hachage disponibles dans les CipherSpecs.

Un des problèmes de TLS est que pour que cela fonctionne, il faut bien un clĂ© master symĂ©trique dĂ©finie dans l’Ă©tape client key exchange. Heureusement, celle-ci est chiffrĂ©e par la clĂ© publique du certificat serveur, empĂŞchant sa lecture par un tiers autre que le serveur.

Un des problèmes est que si l’on rĂ©cupère la clĂ© master et la clĂ© privĂ©e du serveur, mĂŞme Ă  postĂ©riori, il est techniquement possible (mĂŞme si cela n’est pas Ă  la portĂ© de quiconque !) de dĂ©chiffrer l’ensemble d’une capture du trafic par exemple. On perd ainsi la confidentialitĂ© des donnĂ©es transmises, ce qui n’est pas acceptable pour un protocole de sĂ©curisation de donnĂ©es. Quand on connait les impacts potentiels de la faille HeartBleed, on se rend compte que l’obtention de la clĂ© privĂ©e est possible (mĂŞme si encore une fois, cela reste une attaque très complexe et non garantie, cela reste possible et envisageable).

Afin d’Ă©viter cela, nous allons utiliser la propriĂ©té Perfect Forward Secrecy, qui va faire appel Ă  des suites de chiffrement basĂ©es sur les Ă©changes de clĂ© DH (au lieu de RSA) qui ne sont pas faillibles (en thĂ©orie) Ă  ce principe, car les clĂ©s Ă©changĂ©es sont Ă©phĂ©mères et signĂ©es. Cette propriĂ©tĂ© permet d’Ă©viter le dĂ©chiffrement Ă  postĂ©riori d’une capture, mĂŞme en possession de la clĂ© privĂ©e du serveur. Attention, ceci est vrai si le groupe DH est suffisamment grand et valide, et uniquement sur des communications antĂ©rieures Ă  l’obtention de la clĂ© privĂ©e.

Il est possible de renforcer ce mĂ©canisme de Perfect Forward Secrecy en utilisant la cryptographie basĂ©e sur des courbes elliptiques (ECDHE pour l’Ă©change de clĂ©s Ă©phĂ©mères, et ECDSA pour l’authentification du serveur), rĂ©putĂ©e plus sĂ»re que la cryptographie par factorisation.

Par exemple, sur le logiciel Apache, on peut utiliser les CipherSuites suivantes pour renforcer la sécurité de nos échanges basés sur TLS :

# Activation du mod_ssl dans Apache
SSLEngine on

# On désactive SSLv2 et SSLv3 pour n'utiliser que TLS v1.x
SSLProtocol all -SSLv2 -SSLv3

# Au lieu de préférer les suites du client (mécanisme par défaut), on privilégie les suites proposées par le serveur
SSLHonorCipherOrder on

# On propose les suites avec ECDHE, ECDSA uniquement pour PFS
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"
 
# On autorise les clients non compatibles SNI à accéder à ce vhost
SSLStrictSNIVHostCheck on

# Certificat, clé et chîne de certification
SSLCertificateFile      /etc/ssl/certs/cert_beufa.net.cert
SSLCertificateKeyFile   /etc/ssl/private/cert_beufa.net.key
SSLCertificateChainFile /etc/ssl/certs/CAcert_chain.pem

Ces options sont bien sĂ»r Ă  activer avec prĂ©caution en cas de forte charge sur vos serveurs Apache. En effet, la baisse de performances liĂ©es Ă  l’usage de la propriĂ©tĂ© Perfect Forward Secrecy entraĂ®ne des baisses de performances importantes, de l’ordre de 15% Ă  20% en fonction de la longueur des clĂ©s et CipherSpecs utilisĂ©s.

Published in Linux Sécurité

en_USEN