Nous avons toujours des besoins de sécurité sur nos échanges SSL, et il est bon de savoir ce qui est utilisé aujourd’hui dans le mystère des handshake SSL. Les quelques points suivants vont vous donner quelques explications et exemples concrets d’application, besoin ou contrainte d’une méthode d’échange de clé crypté couramment utilisée : Elliptic curve Diffie–Hellman.
ECDHE en deux mots
La méthode d’échange de clé crypté Diffie-Hellman, permettant de limiter l’usage de la clé privée pour l’authentification de la négociation SSL, peut s’appuyer sur une cyptographie basée sur les courbes elliptiques. Ces courbes elliptiques assurent un niveau de sécurité équivalent à RSA, avec l’utilisation de clé plus petite. Les courbes elliptiques impliquent une négociation et validation des paramètres à utiliser entre client et serveur dans le handshake SSL. (client Hello et server Hello)
La version mathématique pour les amateurs
(Repris de : http://vincent.bernat.im/fr/blog/2011-ssl-perfect-forward-secrecy.html )
Le serveur choisit un entier aléatoire aaa et calcule aGaGaG, où GGG est un point générateur sur une courbe elliptique préalablement définie. Ce résultat, aGaGaG, est ensuite envoyé en clair, mais signé avec la clé privée du serveur pour garantir son authenticité. Cette signature et aGaGaG sont inclus dans un message appelé Server Key Exchange.
À réception de ce message, le client vérifie la validité de la signature pour s'assurer que les données proviennent bien du serveur légitime. Ensuite, le client choisit à son tour un entier aléatoire bbb. Il calcule bGbGbG et envoie ce résultat au serveur dans un message nommé Client Key Exchange. Simultanément, le client calcule le produit b⋅aG=abGb \cdot aG = abGb⋅aG=abG, qui constitue le premier secret. Ce secret initial est ensuite utilisé pour dériver le secret maître.
Lorsque le serveur reçoit bGbGbG du client, il effectue le calcul a⋅bG=abGa \cdot bG = abGa⋅bG=abG, obtenant ainsi le même secret initial que le client. Grâce à ce secret partagé, le serveur peut également dériver le secret maître.
Un espion, observant la communication, peut voir les valeurs aGaGaG et bGbGbG transmises entre le client et le serveur. Cependant, en raison des propriétés mathématiques des courbes elliptiques, il n'existe actuellement aucun moyen connu de calculer efficacement le produit abGabGabG à partir de ces seules valeurs et des paramètres de la courbe. Cette difficulté repose sur la complexité du problème du logarithme discret dans le contexte des courbes elliptiques, rendant ainsi le protocole sûr contre les tentatives d'interception et de calcul du secret partagé par des tiers non autorisés.
ECDHE mieux que DHE
Des meilleures performances
L'utilisation de ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) offre des performances supérieures comparées aux méthodes traditionnelles de cryptographie à clé publique pour un niveau de sécurité équivalent. En raison de la taille plus petite des champs utilisés dans les calculs de cryptographie elliptique, les opérations sont plus rapides. Par exemple, une courbe elliptique de 224 bits offre un niveau de sécurité comparable à celui d'une clé RSA de 2048 bits. Cette efficacité accrue permet également de réduire l'utilisation des ressources, notamment le CPU, et de diminuer les besoins en stockage.
Des messages plus petits
Les messages échangés dans le cadre de ECDHE sont également plus compacts. Une courbe elliptique de 224 bits est encodée sur 56 octets, tandis qu'une clé publique classique DH de 2048 bits nécessite 256 octets. Cela se traduit par un gain de 400 octets sur deux messages échangés lors de la phase de handshake SSL, améliorant ainsi l'efficacité du protocole et réduisant la latence des communications sécurisées.
Un tri des clients
L'imposition de l'utilisation de ECDHE entraîne une sélection naturelle des clients, rejetant les versions anciennes de navigateurs ou de systèmes d'exploitation qui ne sont pas compatibles avec ce chiffre. Par exemple, ECDHE est compatible à partir de Windows Vista et Internet Explorer 8, ainsi qu'avec OpenSSL 1.0.0. Cela assure que seules les plateformes modernes et sécurisées sont utilisées, renforçant la sécurité globale des communications.
Compatible et recommandé ?
Exemple Il est possible de configurer des Cipher String prioritaire sur les serveurs, et nous pouvons voir que le ECDHE, lorsqu’il est compatible, est souvent sélectionné le premier. Cela permet de prioriser la méthode sécurisé et performance, et au besoin la compatibilité. Vous ne voulez pas voir certain cipher sélectionné dans vos échanges SSL, vérifiez la configuration de vos équipements. Il est toujours possible de paramétrer les limitations SSL de vos serveurs et OS. Petit cas pratique : Prenons par exemple un équipement F5 en version récente 11.4.1 Un profile SSL va vous permettre de sélectionner les Ciphers, et protocoles souhaités. Par défaut il va autoriser les ciphers string suivants : NATIVE:!MD5:!EXPORT:!DES:!DHE:!EDH:@SPEED Incluant donc les protocols TLS 1.x et SSLv3 (attention Poodle), et les Key exchange RSA ou ECDHE. Nous souhaitons une utilisation exclusive du ECDHE, avec l’utilisation de key supérieur à 128bits, et l’utilisation du protocol TLSv1.1. Nous pouvons à ce moment la remplacer : tmm --clientciphers ECDHE+HIGH+TLSv1_1 Modifications appliquées selon la contrainte. Les nouvelles négociations SSL utiliseront cette méthodes.
Qu’est-ce que vous pouvez vérifier
Pour s'assurer que votre serveur est correctement configuré pour fonctionner avec le chiffrement ECDHE, vous pouvez utiliser la commande OpenSSL suivante :
bashCopier le code<code>openssl s_client -tls1 -cipher ECDH -connect 127.0.0.1:443 </code>
Cette commande tente de se connecter à votre serveur local sur le port 443 en utilisant le chiffrement ECDHE et le protocole TLS 1.0. En exécutant cette commande, vous pouvez vérifier si votre serveur accepte les connexions sécurisées utilisant ECDHE.
Vérification de serveurs distants
De la même manière, vous pouvez tester la compatibilité des serveurs distants (par exemple, vos sites web) avec ECDHE. Remplacez simplement 127.0.0.1 par l'adresse IP ou le nom de domaine du serveur distant que vous souhaitez tester. Par exemple :
bashCopier le code<code>openssl s_client -tls1 -cipher ECDH -connect www.example.com:443 </code>
En utilisant cette méthode, vous pouvez vous assurer que tous les serveurs que vous administrez ou utilisez supportent le chiffrement ECDHE, garantissant ainsi des communications sécurisées et modernes.
Il y a toujours la possibilité faire un scan SSL avec l’outil de Qualys en ligne : https://www.ssllabs.com/ssltes...
Déjà vu au support
Bien que le Cipher ECDHE soit supporté par les différents nœuds, navigateur client et serveur web, nous avons pu constater que certains sites étaient inaccessibles... Attention, certains proxy ne le supportent pas encore ! C’est en particulier le cas sur les proxySG de Bluecoat. Rien au niveau navigateur ou logs sur le Proxy(une erreur global SSL au mieux), ne va vous mettre sur la piste du ECDHE Il faudra pour cela, identifier l’utilisation de ce cipher dans une capture réseau montrant le handshake SSL entre le proxy et le serveur. Et Dans ce cas, effectuer des tests depuis un client non-compatible ECHDE (navigateur web ancien, ou utilisation forcé de protocole SSL ou Ciphers plus vieux) Vous pouvez également tester et appliquer le workaround possible : - Bypass du site en mode proxy transparent - Désactivation du detect protocol sur le site en mode proxy explicit.
N’oubliez pas De lire la RFC 4492 (http://tools.ietf.org/html/rfc4492#section-2).
