Vous êtes ici

SSL/TLS : Sauvons les meubles

Portrait de ivan
Les derniers mois auront été rudes pour TLS. Après le désormais célèbre bug Goto Fail de l'implémentation Apple et son petit cousin linuxien, une nouvelle catastrophe vient d'être annoncée, cette fois-ci pour OpenSSL (CVE-2014-0160 répondant au doux nom de HeartBleed). La bibliothèque cryptographique semble vulnérable depuis 2012 à un problème de débordement de tampon qui permet de lui faire cracher jusqu'à 64k de sa mémoire. Un cas classique de memcpy-gone-wild où une taille contrôlée par l'attaquant est utilisée aveuglément pour allouer puis remplir un buffer. Le patch mettant en évidence le code incriminé est accessible ici.

En théorie, ces 64k qui fuitent permettraient d'extraire les clefs privées des processus utilisant OpenSSL, même si les premiers avis laissent penser que l'exploitation n'a rien de trivial. On ne contrôle pas bien où dans le heap cette mémoire sera lue, et une certaine gymnastique avec l'allocateur paraît indispensable pour pouvoir récupérer les informations intéressantes. Toujours est-il que les découvreurs de la vulnérabilité prétendent y être parvenus.

Et maintenant ? On met sa distribution à jour et on change ses certificats SSL. En prime, si on est quelqu'un d'important, on révoque les anciens sous peine de voir ses clients recevoir des tentatives de phishing diablement convaincantes.

Mise en place de STARTTLS pour Zimbra

Pour commencer, il faut savoir que mettre votre distribution à jour ne suffira pas à endiguer HeartBleed. Zimbra embarque sa propre version d'OpenSSL qui est bien sûr vulnérable... Il va donc falloir attendre la prochaine version, pas trop longtemps on espère. Le bug est suivi à cette adresse.
EDIT (19h00) : Le patch est disponible ! Voir ce commentaire.

C'est tout de même l'occasion de faire un petit ménage de printemps dans l'écosystème cryptographique de votre machine... Et quitte à avoir les mains dans le cambouis, autant faire quelques améliorations dans la foulée. Commençons par Zimbra. Les révélations d'Edward Snowden ont fait couler suffisamment d'encre pour que chacun ait une idée des capacités d'interception massives de certains services de renseignement.
Pourtant, de nombreux e-mails transitent encore en clair sur le réseau tels de vulgaires cartes postales exposées aux indiscrétions du facteur. La raison pour cela, c'est que pour instaurer un chiffrement global des courriels, il faudrait mettre à jour tous les serveurs mails de la planète : une tâche impensable. Aussi, le chiffrement dit "opportuniste" a été inventé. Son principe est simple : lorsque deux serveurs communiquent, ils affichent leur capacité à établir des connexions sécurisées. Et si les deux en sont capables, ils négocient alors une session chiffrée.
Évidemment, pour garantir une confidentialité des échanges, il faut que tous les serveurs mails de la chaîne utilisent ce protocole (et les e-mails ne seront pas chiffrés une fois stockés chez le destinataire). La seule chose qui soit en votre pouvoir ici, c'est de faire en sorte que votre relais à vous, au moins, soit configuré de manière moderne. Et pour tout ce qui est vraiment sensible, utilisez GPG.

Votre serveur mail supporte-t-il cette fonctionnalité ? Peut-être. Pour le savoir, identifiez-le (nslookup -query=MX domaine.com) puis initiez un échange SMTP avec celui-ci :

$ nc -vv domaine.com 25
Connection to domaine.com 25 port [tcp/smtp] succeeded!
220 domaine.com ESMTP Postfix
>EHLO world
250-domaine.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS # OK !
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Si la ligne 250-STARTTLS apparaît, tout est bon... Enfin, peut-être. Car il ne suffit pas d'activer la fonctionnalité, il faut aussi la configurer correctement pour se débarrasser de certains paramètres obsolètes qui mettent à mal la sécurité de l'ensemble. En particulier, il faut refuser plusieurs méthodes de chiffrement qui sont aujourd'hui dépassées (ou sabotées par la NSA), faute de quoi vous récoltez une bulle à votre audit PCI-DSS (item 4.1).

En ce qui concerne Zimbra, le chiffrement opportuniste n'est activé par défaut que depuis la très récente version 8.0.6. Voici la suite de commandes à taper pour y remédier :

# Activation de StartTLS :
postconf -e smtp_use_tls=yes
postconf -e smtp_tls_security_level=may
zmlocalconfig -e smtp_use_tls=yes
zmlocalconfig -e smtp_tls_security_level=may
# Purge des algorithmes faibles
postconf -e smtpd_tls_ciphers=high
postconf -e smtpd_tls_protocols=SSLv3,TLSv1,\!SSLv2
postconf -e smtpd_tls_mandatory_ciphers=high
postconf -e smtpd_tls_exclude_ciphers="aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA"
zmlocalconfig -e smtpd_tls_ciphers=high
zmlocalconfig -e smtpd_tls_protocols=SSLv3,TLSv1,\!SSLv2
zmlocalconfig -e smtpd_tls_mandatory_ciphers=high
zmlocalconfig -e smtpd_tls_exclude_ciphers="aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA"

Le site StartTLS.info vous permettra de vérifier que tout est en ordre (et dans le cas contraire, assénera un "F" écarlate assez culpabilisant).

Mise à niveau de TLS pour nginx

Les tutoriaux pour activer SSL ou générer des certificats pour nginx ne manquent pas. Pour résumer à l'extrême, générez un nouveau couple clé/CSR et rendez-visite à votre autorité de certification pour qu'elle vous fournisse les fichiers mis à jour.

$ openssl req -nodes -newkey rsa:4096 -keyout post_heartbleed.key -out post_heartbleed.csr

Concentrons-nous sur la partie moins souvent abordée : le filtrage des algorithmes faibles. Editez /etc/nginx/sites-available/default (ou tout autre fichier adéquat) pour y ajouter les lignes suivantes en lieu et places de celles qui seraient déjà présentes pour les paramètres spécifiés :

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "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";

EDIT du 22/05/2015 : Suite à l'attaque Logjam sur TLS, il convient également de générer de nouveaux nombres premiers pour l'échange de clefs Diffie-Hellman :

sudo openssl dhparam -out /etc/nginx/dhparams.pem 4096
sudo cp /etc/nginx/dhparams.pem /opt/zimbra/ssl/dhparams.pem
sudo -u zimbra zmlocalconfig -e smtpd_tls_dh1024_param_file="/opt/zimbra/ssl/dhparams.pem"
sudo -u zimbra postconf -e smtpd_tls_dh1024_param_file="/opt/zimbra/ssl/dhparams.pem"

Dans la configuration nginx, il faut également ajouter : SSLDHParametersFile /etc/nginx/dhparams.pem

Redémarrez le serveur web et vous devriez être pas mal du tout. Le site SSL Labs vous permettra là aussi de vérifier que vous n'avez rien oublié, mais aussi de vous gausser des copains qui acceptent le NULL cipher.