Découvrez comment configurer Akamai pour confirmer la vulnérabilité par renégociation découverte par le Security Rating.
Sommaire :
- Fonctionnalité de renégociation initiée
- Configuration dans Akamai
- Remontée par le Security Rating
- Utilisation des certificats clients
Fonctionnalité de renégociation initiée
La fonctionnalité de renégociation initiée est une fonctionnalité historique du protocole SSL/TLS, qui était nécessaire pour initier une renégociation vers des suites de chiffrement plus sécurisé, lorsque le chiffrement faisait l'objet de régulation stricte dans beaucoup de pays, avec une limitation à 56bit des clés RSA.
Elle fut maintenue pendant un temps avec l'argumentaire d'environnement contraints (CPU / RAM), qui pourraient par défaut utiliser une méthode plus légère, et volontairement bascule vers une méthode plus sécurisée pour la transmission d'informations considérées plus sensibles.
Aujourd'hui, elle est désormais totalement obsolète, et a disparu de la spécification du TLSv1.3. Dans la quasi intégralité des cas, le désactiver pour TLSv1.2 et inférieur ne prête à aucune conséquence opérationnelle.
Avec son utilisation à grande échelle pour des opérations de déni de service (renégocier des clés de chiffrements / refaire un échange diffie-helman peut représenter un coût conséquent en CPU et met à mal l'entropie des générateurs de nombre aléatoire, mais est également 15 fois plus couteux pour le serveur que le client), il est conseillé par défaut de le désactiver, ou d'implémenter des contre-mesures, telle que la limitation à moins de 10 renégociations dans une même session, ou une pause exponentielle entre chaque tentative de renégociation.
Configuration dans Akamai
Il existe un problème sur les vhosts exposés par les équipements Akamai, appelé "Secure Client-Initiated Renegociation".
Vous pouvez trouver dans les paramètres de profil Akamai les possibilités suivantes :
- "Secure" Correspond à la fonctionnalité initiale, qui fait l'objet du test. Il existait également une version considérée comme non sécurisée, à laquelle la version "sécurisée" a succédée.
- "Warning" correspond à la version historique non sécurisée. Cette dernière est à bannir, et tous les équipements f5 ou autres sont supposés supporter la version "sécurisée").
- "Disallow" correspond à la désactivation de la renégociation.
Il est recommandé dans la documentation Akamai d'utiliser le paramètre "disallow" afin d'avoir un mode avec des contre-mesures (limitation à moins de 5-10 renégociation par exemple).
Remontée par le Security Rating
Le Security Rating utilise une combinaison d'outils d'analyse, dont une version corrigée de testssl.sh / sslyse pour ce test.
Testssl.com utilise une version non corrigée de testssl.sh.
Vous pouvez trouver le correctif dans la branche 3.0 ou 3.2 sur github, mais ce dernier n'a pas fait l'objet d'une release.
En tirant la version 3.0 ou 3.2 directement de github, vous obtiendrez alors une version non buggée de l'outil permettant de confirmer le diagnostic du Security Rating. L'outil sslyse confirmera également le même diagnostic.
Utilisation des certificats clients
Le serveur peut, à tout moment, lancer une renégociation pour exiger un certificat client lors d'accès à des URL protégées par authentification à certificat. Seuls certaines mauvaises implémentations ou historique de client et/ou serveur forcent l'utilisation de la renégociation client pour l'usage d'un certificat client.
Tout application client/serveur moderne utilisant une authentification par certificat supporte le TLSv1.3.
Sous cette version, la renégociation client n'existe pas, et donc la comptabilité avec un tel paramétrage ne se pose pas.
Des tests de qualification doivent être réalisés pour confirmer que vous n'êtes pas dans un cas où la renégociation à l'initiative du client vous est nécessaire, et donc si des ajustements/travaux additionnels sont nécessaires pour vous en passer.