5 janvier 2015

Au vu des derniers épisodes durant l’année 2014, un petit How To s’impose sur la protection d’une publication en ligne à travers le protocole HTTPS incluant donc la couche SSL ou TLS.

Vous avez certainement lu nos derniers articles sur ce sujet, le but n’est donc pas de les ré-expliquer à nouveau mais d’appliquer les fixes!

Vous avez déjà une publication ou vous souhaitez en faire une et la sécuriser ? suivez le guide !

Step 1: Vérifier les failles de son site Internet

Pour cela, nous vous conseillons d’utiliser l’outil de notre partenaire Qualys permettant d’effectuer un scan SSL.

https://www.ssllabs.com/ssltest/index.html

Tout y passe : certificat, ciphers supportés, SSL/TLS et une piqure de rappel sur les failles qui sont exploitables à l’heure actuelle sur votre site.

Une notation est par la suite effectuée, elle se base sur la faille remontée la plus critique. Allant de la note A (sécurisé) à F (pas sécurisé).

 

Astuce : Je vous conseille fortement de cocher la petite case « Do not show the results on the boards » surtout si votre site à une note de F !

 

Step 2: Combler les failles identifiées

Cette étape se décompose en 4 points. Nous allons reprendre les critères sélectionnés par Qualys.
Cela comprend donc : Certificat, Protocoles supportés, échange de clés etun.

Nous allons prendre comme exemple notre site Internet nomios.fr

• Certificate

On y retrouve facilement une note de 100 (note maximale) mais il est tout de même possible de pousser un peu plus de sécurité à ce niveau.

En effet, tous les certificats qui ont été généré depuis quelques temps avec votre organisme de certification (VeriSign, GoDaddy…) délivraient une signature basé sur un algorithme en SHA1. Depuis les derniers événements, les nouvelles générations de certificats sont maintenant délivrées en SHA256.
Cela ne coute rien de générer à nouveau votre certificat via votre organisme si vous êtes comme ici, en SHA1.

Quelques précisions supplémentaires sur le SHA1 :
https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know

Info : En Novembre 2013, Microsoft a annoncé que les certificats SHA1 ne seraient plus acceptés à partir de 2016.

15% des sites utilisent des certificats SHA256 en Septembre 2014.

• Protocol Support

A cause de la faille POODLE, une dégradation de votre note peut rapidement se faire si votre site accepte les échanges SSL.

Plus de précision ici :
https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack

De plus notre site accepte encore un protocole obsolète qui est le SSLv2.
Qualys sanctionne cela et nous attribue la pire notation qui est la note de F !

Pour désactiver le SSL 2.0 et SSL 3.0

o Serveur IIS, il faut passer par le registre.

Je vous invite à lire cet article :
https://www.sslshopper.com/article-how-to-disable-ssl-2.0-in-iis-7.html

o Serveur WEB – Apache

Pour désactiver SSLv3 dans apache, cela se passe dans le fichier suivant
/etc/apache2/mods-available/ssl.conf
Dans ce fichier, cherchez la ligne SSLProtocol et modifiez la comme suit :
SSLProtocol all -SSLv2 -SSLv3
Vous pouvez en profiter pour modifier les algorithmes qui seront supportés avec les lignes suivantes :
SSLCipherSuite AES256+EECDH:AES256+EDH:HIGH:!LOW:!MEDIUM:!aNULL:!MD5:!RC4
SSLHonorCipherOrder on
C’est tout, pensez à relancer apache.

o Serveur WEB – lighttpd

L’emplacement du fichier de configuration sera laissé à la guise du lecteur, voici les options à renseigner :
ssl.honor-cipher-order = « enable »
ssl.cipher-list = « AES256+EECDH:AES256+EDH:HIGH »
ssl.use-compression = « disable »
ssl.use-sslv2 = « disable »
ssl.use-sslv3 = « disable »
Une petite précision sur l’ajout de l’option use-compression, cela permet d’éviter une autre attaque baptisée BEAST.

o Serveur WEB – Nginx

Tout comme pour lighttpd, je laisse chercher l’emplacement du fichier
ssl_ciphers « AES256+EECDH:AES256+EDH:HIGH »;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;

Nous acceptons cependant tous les protocoles TLS.
Pour ceux qui souhaitent l’activer sur le serveur IIS, je vous conseille d’utiliser le Powershell et de récupérer le fichier fourni sur ce lien :
http://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12

• Key Exchange

L’échange de clé va s’établir sur les différents ciphers supportés.
Les notes sur ce point sont généralement bonnes mais si vous souhaitez obtenir le maximum, il faudra gérer le point suivant.

• Cipher Strength

Pour communiquer en toute sécurité, vous devez d’abord vérifier que vous communiquez directement avec la partie souhaitée (et non par quelqu’un d’autre qui va vous espionner), ainsi que l’échange de données en toute sécurité. En SSL et TLS, les ciphers suites sont utilisés pour définir la façon dont la communication sécurisée a lieu. Ils sont composés de divers blocs de construction avec l’idée de sécuriser l’ensemble. Si l’un des blocs se trouve être faible, vous devriez être capable de passer à un autre.

Votre objectif doit être donc de n’utiliser que des suites qui fournissent une authentification et un chiffrement de 128 bits ou plus. Tout le reste doit être évitée.

Support des Ciphers sous IE :
https://github.com/client9/sslassert/wiki/IE-Supported-Cipher-Suites

 

D’autres points pourraient être encore abordés comme le déploiement du Forward Secrecy mais l’objectif était principalement de se focaliser sur la protection des dernières failles actuelles.

Si cet article vous a intéressé, nous pourrons aller plus en détail sur les Best Practices à suivre pour le déploiement d’un site Internet via le SSL.

 

En vous souhaitant une bonne année 2015 avec ce petit palindrome 11111011111 !

 

Sébastien.

Partager :

Auteurs