Skip to content →

Tag: SSL

Perfect Forward Secrecy pour Postfix/Dovecot

Après mon article sur PFS pour Apache, j’ai mis Ă©galement en place PFS sur mon serveur de messagerie Postfix/Dovecot, le client K9-Mail pour Android supportant dĂ©sormais des versions plus rĂ©centes de TLS, TLSv1.1 et v1.2.

Voici ici quelques éléments pour réaliser cette configuration et augmenter la sécurisation des flux chiffrés.

One Comment

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.

Comments closed
en_USEN