Mettre un certificat SSL sur un service ne veut pas dire qu’il est sécurisé « out of the box ». SSL regroupe plusieurs protocoles et versions différentes.
SSLv2.0, SSLv2.0+, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2 que de versions
Ces versions sont souvent là pour garder une rétro-compatibilité avec des clients anciens. Autant cela pourrait être toléré dans un réseau interne avec des progiciels qui ne sont plus maintenue et où le coût de mise à jour est souvent reporté sur un projet de migration. Autant quand il s’agit de services ouverts sur internet on se doit de faire le nécessaire pour ne pas exposer des protocoles anciens ou être sensible à certaines faiblesses ou failles de la négociation SSL.
Sur Internet une seule règle, utiliser les dernières versions des protocoles SSL et TLS et désactiver le support des anciennes versions et des types de hachages faibles. Mais cela peut couper l’accès à des clients légèrement ancien sans être obsolètes.
Or les algorithmes proposés peuvent à eux seuls mettre à mal la « sécurité » de la communication.
Etude de cas
Avec des outils comme sslscan ou tout simplement gnutls-cli on peut étudier tous les composants du services SSL / TLS et mettre en évidence les algorithmes de chiffrement qui sont disponibles.
Prenons par exemple la méthode TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 qui chiffre sur une clef de longueur de 40bits. A première vue certains diront que 40bits ce n’est pas beaucoup, d’autres auront remarqué que l’on utilise RC2 au lieu d’RC5 et les plus avertis verront l’usage de CBC peu recommandable avec RC4. Cette de méthode de chiffrement est vulnérable et il serait complètement fou pour s’authentifier sur un site web dit « sécurisé » avec cette algorithme. Et pourtant cette méthode est utilise en ce début 2012 par une grande banque mondiale pour l’authentification de ses clients.
Problèmes des configurations de base
On trouve un peu partout des tutoriels expliquant comment générer son CSR, demander son certificat officiel ou auto signé et l’installer sur son serveur Apache ou Nginx. Mais beaucoup de ces tutoriels omettent certains arguments indispensables dans la configuration de ces outils.
Voici ce que l’on peut trouver comme configuration de base et que nous ne recommandons pas pour la configuration d’Apache :
SSLEngine On SSLCertificateFile /etc/apache2/ssl/www.mydomain.com.crt SSLCertificateKeyFile /etc/apache2/ssl/www.mydomain.com.key
et pour Nginx :
listen 443 ssl; ssl_certificate /etc/nginx/ssl/www.mydomain.com.crt; ssl_certificate_key /etc/nginx/ssl/www.mydomain.com.key;
Or avec ces configurations, quels algorithmes, quelle longueur de clef sont utilisés? Pour cela il faut chercher les valeurs par défaut pour la version du serveur web que l’on a. Avouez que l’on passe totalement à côté de notre configuration.
Les premières failles SSL TLS
Puis sont arrivés les premières failles sur SSL et TLS. SSL v2.0 tout d’abord mais qui n’est normalement plus utilisé (sauf surprise pour notre fameuse banque). Beaucoup de médias ont vu en l’été 2011 la fin possible de la sécurité sur internet sachant que la faille nommée « BEAST Attack » qui a fait grand bruit n’exploite une faille connue depuis 2002 et qui a conduit à sortir la version 1.1 de TLS en 2006 et en 2004 pour l’implémentation de TLS dans OpenSSL.
Si la faille est corrigée, pourquoi certains paniquent sur ce sujet et pourquoi des services dit « sécurisés » utilisent encore ces méthode de chiffrement? Le problèmes est l’inertie des clients (web, messagerie, vpn, communication instantanée, … ou tout logiciel qui a besoin de sécurisé une transaction avec un serveur). Ces clients utilisent très majoritairement la librairie NSS pour bénéficier des fonctionnalités de chiffrement des communication. Cette librairie tarde à prendre en compte les différentes risques de TLSv1.0 et ne supporte pas les versions TLSv1.1 et TLSv1.2 ce qui fait que la grande majorité des navigateurs web mêmes récents ne savent pas communiquer en TLSv1.1 et supérieur.
Lorsque l’on met en ligne des services proposant SSL et/ou TLS, la moindre des choses est de proposées un environnement applicatif à jour en proposant une parade à chaque nouveau risque et en mettant à jour sa plateforme quitte à la faire complètement évoluer. De là certains pourront se dire si on désactive TLSv1.0 comme SSLv2.0, on enlève tout soucis, dans l’absolue oui mais il va falloir faire avec vos clients.
Si l’on reste sur le domaine des sites web, il n’y a (en septembre 2011) seulement Internet Explorer 9 et Opéra 10 qui supportent les trois versions de TLS v1.0, v1.1, v1.2. On tape souvent sur le dos de ces deux navigateurs mais ils nous montrent ici qu’ils restent au plus proche de l’évolution de la sécurité. Safari d’Apple, Firefox de Mozilla et Chrome de Google ne supportent (en janvier 2012) que TLS v1.0, des demandes ont pourtant été faites dans les bugtrackers, certains ont proposés des patchs notamment pour Chromium mais sans plus d’actions.
Pour en revenir à la faille « BEAST », cette dernière serait complètement inopérante à partir de TLSv1.1 mais comme TLSv1.0 a encore de l’avenir sur nos serveurs, il faut filtrer les méthodes de chiffrement utilisées. Dans le cas de cette attaque c’est la méthode RC4 qu’il faut éviter. Pour cela il faut donc forcer les services à ne proposer que les bonnes méthodes.
Configuration SSL/TLS sur Apache et Nginx
Nous allons reprendre nos exemples sur les serveurs web.
Apache et GnuTLS avec mod_gnutls
Tout d’abord sur Apache nous allons remplacer OpenSSL par GnuTLS pour apporter le support des versions récentes de TLS et le support de SNI pour mettre plusieurs certificats différents sur une même adresse ip.
L’exemple vaut ici pour un serveur Debian, tout d’abord on install la librairie gnutls pour Apache 2 ainsi que les utilitaires GnuTLS pour la manipulation des certificats. Il faut penser à désactiver le module ssl car les deux vont alors vouloir écouter sur le port 443 https par défaut et Apache ne va pas démarrer alors qu’un apache2ctl -t pensera que la configuration est bonne.
apt-get install libapache2-mod-gnutls gnutls-bin a2enmod gnutls a2dismod ssl
Ensuite vous pouvez retirer toute référence au module ssl, c’est à dire tous les blocs ou bien toutes les déclarations SSL*.
Dans la configuration du vhost :
GnuTLSEnable on GnuTLSCertificateFile /etc/ssl/certs/www.mydomain.com.pem GnuTLSKeyFile /etc/ssl/private/www.mydomain.com.key GnuTLSPriorities NONE:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+AES-256-CBC:+DHE-RSA:+RSA:+SHA1:+COMP-NULL:+COMP-DEFLATE Header always set Strict-Transport-Security "max-age=500; includeSubDomains"
La syntaxe est à peu près identique au module SSL, on active le module TLS, on spécifie le chemin vers le certificat, le chemin vers la clef du certificat. A noter qu’il n’y a pas d’équivalent à la déclaration SSLCertificateChainFile sur GnuTLS il faut comme chez Nginx mettre les certificats intermédiaires et la racine à la suite du certificat du domaine dans le fichier www.mydomain.com.pem.
La ligne GnuTLSPriorities définie les méthodes cipher, la méthode pour l’échange de clef, cette pour l’authentification et les options qui vont être utilisés. On part de NONE et on ajoute ce dont on a besoin. On précise donc que l’on souhaite gérer TLSv1.2 TLSv1.1 et TLSv1.0, puis on donne les méthodes TLS_RSA_WITH_AES_256_CBC_SHA et TLS_DHE_RSA_WITH_AES_256_CBC_SHA toutes deux avec des clefs de 256bits, enfin on utilisera RSA pour l’échange de clef et SHA1 pour l’authentification. Enfin on précise avec COMP-NULL et COMP-DEFLATE que l’on supporte des flux non compressés et la compression des flux en zlib.
Enfin on force Apache à communiquer tous les éléments d’une page de manière sécurisée en ajoutant la directive Strict-Transport-Security dans les headers de la réponse au client.
Nginx SSL/TLS
Depuis le 16 janvier 2012, Nginx supporte les versions TLSv1.1 et TLSv1.2 mais dans la version de développement uniquement, la version stable se base exclusivement sur OpenSSL et ne support donc pas plus que TLSv1.0 pour le moment.
listen 443 ssl; ssl_certificate /etc/ssl/certs/www.mydomain.com.crt; ssl_certificate_key /etc/ssl/private/www.mydomain.com.key; ssl_protocols TLSv1; ssl_ciphers AES256-SHA:DHE-RSA-AES256-SHA; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; keepalive_timeout 70; add_header Strict-Transport-Security max-age=500;
Ici comme pour Apache nous retrouvons deux lignes de configurations pour le chemin du certificat (avec les certificats intermédiaire et racine à la suite dans le même fichier) et le chemin de la clef. On force l’utilisation de TLSv1 en attendant de pouvoir activer les versions ultérieures. On précise les méthodes que l’on souhaite autoriser TLS_RSA_WITH_AES_256_CBC_SHA et TLS_DHE_RSA_WITH_AES_256_CBC_SHA. Avec l’option ssl_prefer_server_ciphers on force le client a utiliser une des méthodes du serveur uniquement. Les paramètres ssl_session* et keepalive_timeout permettent de garder les sessions ouvertes plus longtemps que pour le http non crypté afin de ne pas renégocier les sessions à chaque page visitée, c’est un paramétrage pour alléger le traitement cpu. Enfin on ajoute le header strict transport security pour que le navigateur ne charge aucun élément de page en dehors du canal https.
L’important de bien choisir ses Ciphers SSL TLS
Comme vous avez pu le voir, proposer des services sécurisés ne consiste pas à juste faire une demande de certificat le plus « trusted » qui soit et l’installer de base sur votre serveur applicatif. Nous avons pu croiser chez quelques clients des aberrations de configuration souvent due au fait qu’on laisse les options par défaut sans savoir réellement ce qu’elles proposent. Ces avertissements valent pour toutes les communications SSL/TLS et nous vous recommandons fortement de vérifier vos VPN-SSL et la configuration de ces derniers, il serait dommage de faciliter l’accès à votre entreprise parce qu’un employer s’est connecté sur votre VPN à partir d’un réseau wifi ouvert que l’on trouve dans les hôtels / restaurants.
