Il y a moins d'un an, RC4 était l'algorithme préféré des ciphersuites. 6 mois plus tard, des doutes commençaient à émerger, et maintenant c'est un paria que tous rejettent. Une partie de la communauté cryptographique supporte Perfect Forward Secrecy, alors qu'une autre le refuse pour cause de lenteur. Il est même possible que AES-256 ne fournisse pas le niveau de sécurité attendu! Les exemples de désaccord sur la meilleure façon de configurer ses serveurs avec HTTPS sont nombreux. C'est un paysage qui change en permanence. Et si le débat est utile aux experts, il est presque impossible pour un non-initié de naviguer la nébuleuse TLS, et d'en extraire une configuration de référence.

Mozilla héberge de nombreux sites web, logiciels et services. Plusieurs centaines, en réalité, sont hébergés sur des infrastructures diverses et variées. Au dernier décompte, un peu moins de 1200 domaines avaient un pied sur l'Internet en HTTPS. L'héritage de Netscape et de NSS (Network Security Services, la librarie TLS de Firefox et Chrome) est fort, et nous prenons à cœur d'améliorer notre support de TLS côté infrastructure en permanence.

Au début de l'été 2013, l'équipe Operations Security (OpSec) de Mozilla a décidé d'écrire un guide de configuration du TLS pour les administrateurs. Ce qui devait prendre quelques heures a, en fait, pris plusieurs mois, et impliqué de nombreux contributeurs. Le résultat se trouve sur https://wiki.mozilla.org/Security/Server_Side_TLS .

Dans cet article, nous allons revenir sur les point clés de la recommandation, et présenter un état des lieux de TLS. Nous discuterons des différents algorithmes, du support des différents constructeurs, et des outils pour évaluer nos configurations. Mais, le véritable objectif de cette descente au coeur de TLS, c'est de trouver la ciphersuite optimale pour nos besoins. Et pour cela, plusieurs questions se posent:

• Comment activer Perfect Forward Secrecy, avec les bons paramètres Diffie-Hellman ?
• AES CBC, GCM, 128, 256 ?
• RC4 ou 3DES ?
• Quelle place pour les courbes elliptiques ?
• Comment maintenir la rétro-compatibilité avec les anciens navigateurs et clients?

En répondant à tout cela, on arrivera à la ciphersuite suivante:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

<note> Le nommage des suites TLS, pourtant normalisé par la Internet Assigned Numbers Authority (IANA), est différent d'une librairie à une autre. IANA, OpenSSL, GnuTLS et NSS utilisent des noms différents pour les mêmes suites. Dans le suite de cet article, nous préférerons le nommage de l'IANA. </note>

Si la majorité de cet article discute des priorités dans une ciphersuite, il importe tout d'abord de comprendre pourquoi cela est nécessaire. Lors de la négociation TLS, le client envoi un message CLIENT HELLO qui contient une liste de ciphers supporté. Le serveur a le droit de choisir le cipher qui lui plaît dans cette liste. Nginx, Apache, Haproxy, F5, etc…, possèdent une option qui indique au serveur de faire ce choix en accord avec ses propres priorités. De fait, fournir au serveur une ciphersuite qui contient un ordre précis permet de contrôler les ciphers qui seront utilisés entre les clients et le serveur.

La ciphersuite ci-dessus préfère la suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ECDHE-RSA-AES128-GCM-SHA256 chez OpenSSL) en premier. On voit également que RC4 est relégué tout en bas. La commande openssl ciphers -V '<ciphersuite>' peut être utilisé pour obtenir une meilleure vue de ces priorités.

Perfect Forward Secrecy (“confidentialité persistante parfaite”) a occupé nombre de discussions au cours des derniers mois. Pour beaucoup d'équipe en charge de sécurité opérationnelle, les clés privées, rarement renouvelées, sont un facteur d'attaque important. Sans PFS, une communication TLS, même enregistrée plusieurs années auparavant, peut être décryptée en utilisant uniquement la clé privée. Des millions de sessions TLS sont ainsi protégées par une seule et unique clé RSA, qui peut être volée par un attaquant. Le concept de PFS permet de couvrir ce risque: pour chaque session TLS, client et serveur négocie une clé qui n'est jamais transmise sur le réseau, et est détruite à la fin de la session. La clé privée du serveur est utilisée pour signer un échange Diffie-Hellman entre le client et le serveur. La clé pre-maître ainsi obtenue est fournie à l'algorithme de dérivation. Comme la clé pre-master est spécifique à la session entre le client et le serveur, et n'est pas réutilisée (sauf en cas de redémarrage de session), elle est appelée éphémère.

Avec PFS, si un individu entre en possession de la clé privée du serveur, il sera incapable de déchiffrer les communications passées. La clé privée est utilisée uniquement pour signer l'échange Diffie-Hellman, qui ne permet pas de connaître la clé pre-maître. La sécurité de Diffie-Hellman est équivalente à celle de RSA pour des tailles de clés identiques. PFS ne réduit donc pas le niveau de sécurité fournit par TLS.

Pour bien comprendre PFS, il faut décortiquer la négociation de session TLS. Quand un algorithme qui supporte Ephemeral-Diffie-Hellman (DHE), prenons TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, est utilisé, les étapes suivantes ont lieu:

1. La négociation commence lorsque le client envoi CLIENT HELLO au serveur. Ce dernier répond avec SERVER HELLO et CERTIFICATE.
2. Le serveur envoi ensuite au client un message SERVER KEY EXCHANGE. Ce message contient:
   1. p, un nombre premier
   2. g, un générateur
   3. A, la partie publique de l'opération A = g^X mod p, où X est un entier aléatoire qui doit rester secret.
   4. S, la signature RSA des éléments précédant, calculé avec la clé privée du serveur
3. Le client vérifie la signature S en utilisant la clé publique du serveur, contenue dans le certificat
4. Le client envoi au serveur un message CLIENT KEY EXCHANGE, qui contient la réponse Diffie-Hellman:
   1. B, la partie publique de l'opération B = g^Y mod p, où Y est un entier aléatoire qui doit rester secret.
5. Le serveur et le client calculent la clé pré-maître de la façon suivante:
   1. Le serveur calcule PMS = B^X mod p
   2. Le client calcule PMS = A^Y mod p
6. Enfin, le client envoi un message CHANGE CIPHER SPEC au serveur, et les deux parties continuent la session en utilisant des messages chiffrés.

Lors de la négociation TLS, le client et le serveur commence par négocier une clé pré-maître, qui est ensuite transformé en clé maître, puis dérivée en deux clés de session, pour la signature, et le chiffrement.

La sécurité de DHE dépend du nombre premier p. La taille de p limite la taille de la clé pre-maître et des valeurs A et B, à cause de l'opération modulo de Diffie-Hellman. Plus ce nombre est grand, plus Diffie-Hellman sera difficile à casser. p est public, et peut être généré à l'avance. Avec OpenSSL, il peut être généré avec la commande 'openssl dhparam'.

Idéalement, dhparam devrait être de la même taille que le modulo des clés RSA. Si les clés ont un modulo de 2048 bits, qui est la norme recommandée actuellement, alors dhparam devrait être de 2048 bits. Seulement voilà, il existe des clients dont les couches TLS ne supportent pas les dhparam d'une taille supérieure à 1024 bits (ne te cache pas, Java 6, c'est bien toi dont je parle). Dans la pratique, on est donc contraint à utiliser un algorithme DHE qui réduit la taille des clés à 1024 bits, jusqu'à ce que tous les clients aient migrés.

La question est donc de choisir le moins pire des deux, entre prioriser une ciphersuite qui n'utilise pas PFS, ou préférer PFS avec un dhparam de 1024 bits. A Mozilla, nous avons opté pour la seconde solution, en poussant les clients qui utilisent des librairies obsolètes à se mettre à jour.

Diffie-Hellman a un autre inconvénient, celui d'être lent. L'étape supplémentaire de négociation de la clé pre-maître rend DHE un peu plus de trois fois plus lent qu'une négociation classique. Dans la pratique, c'est un problème opérationnel majeur, qui a participé au manque d'adoption de PFS.

PFS avec DHE n'est pas parfait. Mais Mozilla est une organisation où les questions de confidentialité l'emporte sur la performance pure. Pour cette raison, nous avons choisi de préférer PFS, en plaçant TLS_DHE_RSA_WITH_AES_*_CBC_SHA devant ses homologues non-PFS.

AES est un algorithme résistant, c'est son implémentation dans TLS qui lui a joué des tours. BEAST et Lucky13 sont deux attaques sur le mode CBC d'AES. BEAST, en particulier, a poussé bon nombre de sites à préférer RC4 à AES-CBC, y compris mozilla.org.

Qu'en est-il réellement? BEAST est une attaque sur le vecteur d'initialisation (IV) du mode CBC. Hors cette attaque ne fonctionne que pour SSLv3/TLSv1. La génération des IV a été corrigée dans TLSv1.1. Et pour les sites qui utilisent TLSv1, les navigateurs ont mis en place une astuce appelée “1/n-1 record splitting”, qui mélange l'IV et corrige la faille. En pratique, il est acceptable d'utiliser AES-CBC aujourd'hui. Nous lui préférerons toutefois sont remplaçant, AES-GCM, dont le mode d'opération permet de s'écarter définitivement de CBC, qui a tant nui à AES.

La question qui se pose ensuite est celle de la longueur des clés. Il serait naturel de préférer AES-256 à AES-128. Mais dans la pratique, le bénéfice d'AES-256 n'est pas évident.

Tout d'abord, il est plus lent, que ce soit avec AES-NI (jeu d'instructions AES exécutée dans le CPU), ou sans, AES-256 est environ 30% plus lent que son petit frère. Sur un Intel Xeon, avec des blocs de 8Ko, et AES-NI, AES-128 a une bande passante de 736Mo/s. AES-256, par contre, n'atteint que 531Mo/s. Évidemment, ces nombres sont suffisamment élevés pour un particulier. Mais sur un serveur qui sert un site a fort trafic, la différence à de l'importance.

Ensuite, il a été montré [1] qu'AES-256 est sensible aux attaques par canal séparé. AES-256 ne sera que 6 à 7 fois plus difficile à attaquer qu'AES-128.

Bien que cela reste très théorique, ces deux raisons sont suffisantes pour préférer AES-128 à AES-256. Du moins pour le moment.

Une anecdote en passant: en effectuant des recherches sur les performances d'AES avec différentes plate-formes (un simple 'openssl speed' vraiment), je me suis rendu compte que mon téléphone portable, un Galaxy S3, calculait AES plus rapidement qu'une instance Amazon EC2 et qu'un Intel Atom. C'est un détail intéressant, car il détruit le mythe du téléphone portable incapable d'utiliser HTTPS rapidement. Si les prochaines générations de processeur ARM ajoute les instructions AES-NI, nous aurons de vrai outils de cryptographie directement dans nos poches.

Ayant atteint la conclusion qu'AES doit se trouver tout en haut de notre ciphersuite, reste à discuter le cas de RC4.

RC4 est un vétéran crée en 1987. Nous savions depuis une dizaine d'année que les premiers octets du flux de RC4 sont biaisés. Cela a été utilisé dans les attaques contre WEP (wifi). TLS semblait immunisé, jusqu'à ce qu'en mai 2013, il fut démontré [2] que les 256 premiers octets du flux soient vulnérables à une attaque par analyse statistique. C'est une attaque encore très théorique, car elle nécessite des milliards de requêtes à analyser. Toutefois, le petit monde de la cryptographie s'accorde sur le fait que RC4 ne va plus tenir bien longtemps, et qu'il est grand temps de le remplacer. Ce ne serait pas un problème, si, encore une fois, tout le monde était à jour. Ce n'est malheureusement pas le cas, et une importante partie des internautes utilisent encore Windows XP, et sa librairie 'schannel' qui ne supporte pas AES. Pour ces derniers, deux solutions: RC4 ou 3DES. Dans l'absolu, 3DES fournit un meilleur niveau de protection. Mais il est également terriblement lent! Lors de tests avec Nginx, qui comparent TLS_RSA_WITH_3DES_EDE_CBC_SHA avec TLS_RSA_WITH_RC4_128_SHA, 3DES ressort 30x plus coûteux que RC4.

Il est donc difficile de recommander 3DES plutôt que RC4 sans connaître le détail du trafic servi par le site. Pour mozilla.org, il nous faudra une étude complète du trafic avant de faire ce choix, car il est nécessaire que les utilisateurs de Windows XP puisse nous contacter dans de bonne conditions. En attendant, RC4 conserve sa place dans la ciphersuite, mais tout en bas.

Alors que RSA résiste vaillamment aux attaques, la recherche autour des courbes elliptiques (ECC) prépare l'époque post-RSA. Les ECC sont encore très peu déployées coté serveur. Les questions autour du brevetage des courbes ont certainement ralenti leurs adoption, mais cela semble désormais résolu. Google et Facebook servent désormais leurs page d'accueil avec TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. NSS, OpenSSL et GnuTLS supporte ECDHE et ECDSA. En dehors du monde TLS, d'autres outils, comme OpenSSH et GnuPG, supportent ECDSA depuis longtemps.

ECDHE est un protocole de négociation de clé qui utilise les courbes elliptiques et Diffie-Hellman pour négocier une clé pré-maître. Son fonctionnement est très similaire à DHE, à la différence que le client envoi dans le CLIENT HELLO un liste de courbes qu'il supporte. Les opérations sont ensuite effectués sur une courbe de cette liste choisie par le serveur. La capture d'écran ci-dessous montre les courbes envoyés par Firefox 28.0a1 (Nightly) à Google lors du CLIENT HELLO. Trois courbes sont supportées: secp256r1, secp384r1 et secp521r1.

L'avantage de ECDHE est la vitesse. Google a contribué, en 2011, du code pour OpenSSL qui améliore les performances de ECDHE en 64 bits. Coté serveur, ECDHE est désormais trois fois plus rapide que le classique DHE, et seulement 15% plus lent qu'une négociation classique (RSA sans PFS) [3]. A ce niveau de performance, les questions de lenteurs de PFS ne se posent plus.

ECDSA est un mécanisme d'authentification qui utilise les courbes elliptiques et l'algorithme de signature DSA (une variante d'ElGamal) pour signer les paramètres Diffie-Hellman. Alors qu'ECDHE est relativement simple à activer dans la couche TLS, ECDSA requiert un nouveau type de clé dans les certificats X509. Pour utiliser ECDSA, les certificats doivent contenir n'ont pas une clé publique RSA, mais une clé publique DSA et une courbe. Quelques autorités de certificats proposent déjà ce type de clé, mais ce n'est pas la norme aujourd'hui.

Des exemples de clés ECDSA et RSA sont ci-dessous, et montrent les différences de génération, et de format, avec openssl.

$ openssl ecparam -out ec_key.pem -name sect283r1 -genkey 

$ openssl ec -in ec_key.pem -text
read EC key
Private-Key: (282 bit)
priv:
    02:35:96:72:6d:cd:df:0d:0c:27:c9:d3:de:34:...
pub: 
    04:01:d5:49:d9:f9:a9:33:78:9e:34:ff:03:34:...
ASN1 OID: sect283r1
NIST CURVE: B-283
writing EC key
-----BEGIN EC PRIVATE KEY-----
MIGAAgEBBCQCNZZybc3fDQwnydPeNFr6bSfIMqRKYw8KoZDS1EvVjFxzC+KgB...
-----END EC PRIVATE KEY-----

$ openssl genrsa -out rsa_key.pem 2048
Generating RSA private key, 2048 bit long modulus
.........................................................+++
e is 65537 (0x10001)

$ openssl rsa -in rsa_key.pem -text
Private-Key: (2048 bit)
modulus:
    00:a3:3c:5c:d7:b1:96:d7:2e:8c:86:73:2b:fd:...
publicExponent: 65537 (0x10001)
privateExponent:
    05:94:4a:98:14:b9:d3:21:04:2c:94:43:2c:a9:...
prime1:
    00:d6:f9:9b:e3:4c:6f:de:87:cc:ab:44:22:8e:...
prime2:
    00:c2:63:15:a6:57:12:fd:c3:3c:b0:02:8e:8f:...
exponent1:
    00:d5:e6:2d:26:ff:f2:3b:b0:51:84:83:da:02:...
exponent2:
    2a:b0:ca:1b:6a:fa:1f:c3:15:fb:ed:c3:d3:78:...
coefficient:
    00:9b:d6:24:3e:c8:71:4c:28:a7:e0:f7:9a:3...
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAozxc17GW1y6MhnMr/dOTOJbio0nWpe4GUgDnEAV94wkDgSGL
...
-----END RSA PRIVATE KEY-----

ECDSA est plus rapide que RSA, pour le même niveau de sécurité. La taille de clé étant dix fois moindre, l'opération de signature est d'autant plus rapide. La commande 'openssl speed' ci-dessous montre cette différence. C'est particulièrement intéressant pour les serveurs qui signent plusieurs milliers de négociations TLS par seconde. En revanche, l'opération de vérification est nettement plus coûteuse avec ECDSA que RSA, mais comme ce coût est absorbé coté client, ce n'est pas réellement un problème.

$ openssl speed ecdsap224 rsa2048
                              sign    verify    sign/s  verify/s
rsa 2048 bits              0.001123s 0.000033s   890.1  30381.4
224 bit ecdsa (nistp224)   0.0001s   0.0004s   10929.3   2799.5

Maintenant que nous avons étudié les différents éléments de choix, composer une ciphersuite solide n'est pas trop difficile. Pour résumer, nous voulons:

1. ECDHE+AESGCM en premier. Bien que ces algorithmes soit réservée à TLSv1.2, et peu supporté pour le moment, leurs adoption s'améliore rapidement.
2. PFS est préféré, avec ECDHE d'abord, puis DHE.
3. AES-128 est préféré à AES-256, pour des raisons de performance, et parce que AES-256 ne fournit pas forcément le niveau de sécurité attendu.
4. AES est préféré à RC4
5. RC4 est maintenant dans la ciphersuite, mais 3DES pourrait l'y replacer à l'avenir

Nous allons également prendre soin d'écarter les algorithmes qui fournissent une sécurité médiocre. Les mots clés suivant sont spécifiques à OpenSSL:

• aNULL contient les algorithmes qui n'authentifie pas les négociations PFS, et sont vulnérables à des attaques de type Man-In-The-Middle (MITM)
• eNULL contient les algorithmes qui ne fournissent pas de chiffrement
• EXPORT, DES, SSLv2 et MD5 contiennent des suites obsolètes

En compilant ces critères, nous retrouvons la ciphersuite présentée en début d'article:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

En fonction de la version d'OpenSSL utilisée, certain algorithmes ne seront pas disponibles. OpenSSL les ignorera silencieusement, ce qui permet de toujours utiliser la ciphersuite complète.

Il est possible de convertir la ciphersuite ci-dessus pour GnuTLS, ou IANA, en utilisant les valeurs hexadécimales de chaque algorithme. J'ai écris un outil en Bash qui fait cela, et est disponible à https://github.com/jvehent/tlsnames .

OCSP Stapling est une extension à TLS qui permet à un serveur d'envoyer une réponse OCSP à un client directement. L'idée est d'éviter au client d'aller chercher lui-même l'enregistrement OCSP chez le répondeur de l'autorité de certificat, car cela ralentit l'établissement de session TLS. Un client qui supporte OCSP Stapling ajoute une extension 'status_request' au CLIENT HELLO. Le serveur, s'il supporte lui aussi OCSP Stapling, répondra avec la même extension dans le SERVER HELLO, et enverra une copie de l'enregistrement OCSP le concernant dans un message CERTIFICATE STATUS. C'est un mécanisme simple et intéressant d'un point de vue des performances. De fait, Firefox, Chrome et Internet Explorer poussent pour une adoption rapide d'OCSP Stapling. Malheureusement, à l'écriture de cet article, seuls IIS, Nginx et Apache avec OpenSSL supportent OCSP Stapling. Aucun des vendeurs de répartiteurs de charge avec qui nous travaillons ne le supporte.

HTTP Strict Transport Security (HSTS) est un en-tête renvoyé par un site dans une réponse HTTP, par un serveur vers un client, qui indique au client de toujours utiliser HTTPS pour accèder au site. L'en-tête, nommé “Strict-Transport-Security”, contient une valeur de temps pendant laquelle le client conservera cette indication. HSTS permet de réduire le risque de redirection malveillante de HTTPS vers HTTP. C'est un mécanisme trivial à implémenter, une fois que l'infrastructure permet de supporter HTTPS sur l'ensemble des pages d'un site.

Voyons comment les critères ci-dessus peuvent être mis en place dans une configuration Nginx. Ici encore, les versions de Nginx et OpenSSL ont de l'importance. Il est préférable de compiler ces derniers soit-même pour avoir un support complet.

server {
    listen 443;
    ssl on;
    # certificats envoyés dans le SERVER HELLO sont concaténé
    # dans un seul fichier
    ssl_certificate     /chemin/vers/cert_serveur_et_inter;
    ssl_certificate_key /chemin/vers/cle_privee;
    # dhparam de taille 2048 ou superieure
    # (1024 si compatibilite java6 requise)
    ssl_dhparam         /chemin/vers/dhparam;
    ssl_session_timeout 5m;
    ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         '<notre ciphersuite complete>';
    ssl_prefer_server_ciphers on;
    # cache de session TLS pour le redémarrage (resumption)
    ssl_session_cache   shared:SSL:50m;
 
    # cache l'enregistrement HSTS pour une durée de 6 mois
    add_header Strict-Transport-Security max-age=15768000;
 
    # OCSP Stapling
    # Indique à Nginx d'aller chercher un enregistrement OCSP
    # à l'adresse indiqué dans 'Authority Information Access'
    ssl_stapling on;
    # Vérifie la signature OCSP, nécessite l'accès au certificats
    # root et intermediaire de l'autorité
    ssl_stapling_verify on;
    ssl_trusted_certificate /chemin/vers/cert_root_et_inter;
    # Nginx a également besoin d'un répondeur DNS pour trouver
    # l'IP du répondeur OCSP
    resolver <IP répondeur DNS>;
 
    ....
}

Pour clore notre tour d'horizon, il convient de présenter quelques outils de test. L'outil de référence est sans aucun doute l'excellent SSL Labs, par Qualys, à https://www.ssllabs.com/ . Cette plate-forme de test couvre l'ensemble des points discutés dans cet article, et donne également une revue complète des extensions supportées.

Cipherscan est un outil console qui évalue uniquement la ciphersuite d'un site, et la taille de clés éphémères pour PFS. Je l'ai écrit afin de visualiser ces préférences en quelques secondes, quand SSL Labs peut prendre plusieurs minutes. Il se trouve à https://github.com/jvehent/cipherscan .

La commande ci-dessous montre la sortie de Cipherscan sur un serveur Nginx qui utilise la configuration de référence discutée précédemment.

$ ./CiphersScan.sh jve.linuxwall.info:443
prio  ciphersuite                  protocol  pfs_keysize
1     ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2   ECDH,P-256,256bits
2     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2   ECDH,P-256,256bits
3     DHE-RSA-AES256-GCM-SHA384    TLSv1.2   DH,4096bits
...

L'écosystème de TLS change si souvent, que maintenir un état de l'art est presque un travail à temps plein. S'il est bénéfique de voir la recherche avancer rapidement, les implémentations coté serveur ne suivent pas au même rythme. Il y a, évidemment, un problème de support, et la majorité des constructeurs de répartiteurs de charge sont en retard (TLSv1.2 a été publié en 2008). Mais aussi une question d'éducation, que nous espérons améliorer avec cette recommandation. Mozilla a, comme beaucoup, du travail pour supporter, coté serveur, le niveau de sécurité proposé par Firefox et Chrome. La première étape était de définir les besoins, la seconde sera de mettre à jour notre infrastructure.

[1] http://eprint.iacr.org/2007/318.pdf

[2] http://www.isg.rhul.ac.uk/tls/

[3] http://vincent.bernat.im/fr/blog/2011-ssl-perfect-forward-secrecy.html