Petit durcissement de son serveur TLS

Et oui, ceci est n-ième article sur TLS : la preuve (ou pas) que tout ne semble pas avoir été écrit…

http ou hyper text transfer protocol est très certainement le protocole applicatif le plus utilisé sur l’internet. Il permet de télécharger les pages web d’un serveur et de les afficher dans votre navigateur. Les informations transitent en clair sur les réseaux. C’est à dire que n’importe quelle machine sur le trajet peut lire ces données. Avouez qu’en termes de confidentialité, il y a mieux. Il est parfois utile, désirable, impératif de s’assurer que personne d’autre que nous ne puisse lire ces informations. Prenons le cas de nos données bancaires, par exemple : nous ne voulons que notre voisin sache combien nous avons sur notre compte.
Le protocole HTTP peut donc être couplé avec un autre protocole appelé TLS et il devient alors HTTPS.
TLS (ou Transport Security Layer) a été créé pour offrir un moyen de sécuriser simplement les flux de données mais pour tout type d’application et service. Il n’est pas la chasse gardé de l’http et on peut le retrouver sur d’autres protocols (IMAP, SMTP, FTP, …). Historiquement TLS est une évolution de SSL (Secure Socket Layer) développé par NetScape

Notamment, TLS regroupe trois fonctionnalités importantes :
– L’authentification
– L’échange de clé
– Le chiffrement des données

Afin de pouvoir permettre le chiffrement et le contrôle d’intégrité des données, les deux parties (que nous appellerons de façon très originale : client et serveur) doivent se mettre d’accord sur une suite cryptographique composée :

• D’un algorithme d’échange de clé {RSA|DHE|ECDHE}
• D’un algorithme d’authentification {RSA|ECDSA}
• D’un algorithme de chiffrement {AES-128|AES-256|3DES-EDE|DES|RC4|…}
• D’un mode (si applicable) {CBC|GCM|CCM|…}
• D’une fonction pseudo-aleatoire ou d’un MAC : {MD5|SHA|SHA256|…}

Le tout est préfixé d’un TLS  pour TLSv1 et supérieur, SSL pour SSLv3 et SSL_CK pour SSLv2.  Ainsi vous pouvez tomber sur :

|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
|       SSL_RSA_WITH_AES_128_CBC_SHA

Une grosse partie de la sécurité TLS repose sur la confiance. Le modèle actuel est ce qu’il est : fonctionnel mais assez imparfait.

Il est possible d’obtenir simplement un certificat valide : Notamment, plusieurs autorités de certification proposent gratuitement de signer un certificat. Citons par exemple RapidSSL, ComodoSSL et StartSSL. Il est intéressant de voir que ces 3 entités offrent avec ce service avec différents niveaux de sécurité.

Diagnostic de Performance SSL :

Le site SSLLabs n’est plus à présenter : il permet notamment d’évaluer la configuration d’un site https. Le système de notation évolue régulièrement dans le temps et permet à chaque nouveau scandale SSL/TLS de tester si le site en question est vulnérable ou non. Cependant, il faut rester vigilant quand à son utilisation, si nous n’y prenons pas gardes, nos domaines peuvent être l’objet d’une publicité parfois gênante.

Nous mettons ici à titre informatif, les configurations nginx et apache2 pour obtenir une note A+ et un score de 4×100 au 8 Juin 2015.

######################
# NGINX HTTPS server #
######################
server {
        listen 443 default_server;
        listen [::]:443 default_server ipv6only=on;
        add_header Strict-Transport-Security max-age=15768000;
        root /usr/share/nginx/html;
        index index.html index.htm;
        ssl on;
        ssl_certificate /etc/ssl/certs/comodoCert.pem;
        ssl_certificate_key /etc/ssl/private/comodoKey.key;
        ssl_dhparam /etc/ssl/certs/dhparam.pem;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1.2;
        ssl_ciphers -ALL:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA256:ECDHE-RSA-AES256-SHA256:ECDHE-RSA-AES256-SHA;
        ssl_prefer_server_ciphers on;
        location / {
                try_files $uri $uri/ =404;
        }
}

###########
# Apache2 #
###########
VirtualHost _default_:443>
    ServerAdmin webmaster@localhost

    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
    SSLEngine on
    Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
    SSLCipherSuite -ALL:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA256:ECDHE-RSA-AES256-SHA256:ECDHE-RSA-AES256-SHA
    SSLHonorCipherOrder off
    SSLCompression off
    SSLInsecureRenegotiation off
     SSLCertificateFile     /etc/ssl/certs/comodoCertAlone.pem
    SSLCertificateKeyFile   /etc/ssl/private/comodoKey.key
    SSLCertificateChainFile /etc/ssl/certs/comodoChain.pem

    <FilesMatch "\.(cgi|shtml|phtml|php)$">
                    SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
                    SSLOptions +StdEnvVars
    </Directory>

    BrowserMatch "MSIE [2-6]" \
                    nokeepalive ssl-unclean-shutdown \
                    downgrade-1.0 force-response-1.0
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>

Notons ici que la taille de l’exposant public RSA (ou moduli) minimum est 4096 bits pour obtenir un score de 100 dans la catégorie « Key Exchange ». En effet, apache2 dans ces dernières versions dérive la taille des paramètres DHE de la taille de la clé… Pour nginx, malgré un dhparam de 4096 bits, si notre clé RSA est de 2048 bits nous n’obtenons pas 100% dans cette catégorie.

Ces paramètres ont été trouvés pour la plus part itérativement. Mais en fait Ivan Ristić détaille régulièrement sa méthode de notation et son évolution en fonction des nouvelles vulnérabilités et/ou faiblesses du protocole.

Pourtant le système utilisé de notation est parfois critiquable : Le premier exemple est bien sur la nécessité de n’autoriser que le TLSv1.2 et donc rendre son site inaccessible à tous les OS anciens (Mais rassurez-vous, y en a presque plus des XP !). Cela est encore compréhensible d’un point de vue sécurité. Cependant sur la partie cryptographique, la notation valorise davantage le DHE-RSA-AES256-CBC-SHA par rapport au mécanisme ECDHE-RSA-AES128-GCM-SHA256. Cela nous laisse sensiblement dubitatif.

La commande nmap suivante permet aussi de voir ce qui est ou non actif sur son serveur TLS :

%> nmap --script ssl-enum-ciphers.nse cryptobourrin.wordpress.com

Notez également l’existence de testssl.sh pour faire tout cela en local (si par exemple vous êtes sur des sites déconnectés de la toile).

Voilà maintenant vous n’avez plus d’excuses pour ne pas avoir une bonne note sur ce test.