La semaine dernière, le groupe de pirates THC (The Hacker’s Choice) a publié un outil intéressant qui permet de mener des attaques DoS sur la couche SSL/TLS. Cet outil exploite le fait que le serveur consomme beaucoup plus de ressources processeur que le client lors de la négociation d’une nouvelle connexion SSL. Par conséquent, si un grand nombre de requêtes de connexion SSL est envoyé chaque seconde, c’est l’ensemble des ressources processeur du serveur qui finira par être monopolisé. Par Ivan Ristic, responsable du laboratoire de recherche SSL chez Qualys.

La faille exploitée par cet outil n’est pas nouvelle. Par contre, ce qui est nouveau, c’est qu’il existe désormais un exploit fonctionnel très médiatisé qui nous oblige à faire toujours attention. En outre, l’outil utilise la capacité de renégociation, ce qui lui permet de contraindre un serveur à exécuter de nombreuses opérations cryptographiques coûteuses sur une connexion TCP unique. Il n’est pas établi que la renégociation facilite vraiment l’exécution d’attaques de type DoS (une analyse très pertinente des compromis est disponible sur le blog d’Eric Rescorla). Cependant, le fait que des outils d’atténuation des attaques DoS externes (par exemple, pour configurer la limitation de débit) ne voient qu’une seule connexion TCP permet certainement d’éviter sa détection.

Mais tout cela n’est possible que si votre serveur prend en charge la renégociation initiée par le client. Si ce n’est pas le cas, quiconque souhaitant mener une attaque DoS contre la couche SSL devra se contenter d’utiliser une connexion TCP pour une connexion SSL. IIS, par exemple, ne supporte pas la renégociation initiée par le client. Apache prenait cette renégociation en charge jusqu’au déploiement de la RFC 5746 qui a résolu la vulnérabilité TLS Authentication Gap. Même si vous utilisez un produit qui supporte la renégociation initiée par le client, vous pourrez probablement désactiver cette fonction sans peine. Et vous ne le regretterez pas, contrairement à la renégociation initiée par le serveur parfois nécessaire à certains sites qui exigent des certificats clients.

Pour vous aider à évaluer la sensibilité de vos systèmes à cette vulnérabilité, nous avons mis à jour l’outil d’évaluation SSL Labs. Ce dernier vérifie non seulement si la renégociation sécurisée est prise en charge (critère que nous testons depuis déjà un certain temps), mais il vérifie aussi si une renégociation initiée par un client sécurisée est activée. Jusqu’à maintenant, nous testions uniquement la renégociation initiée par le client non sécurisée.

Il est donc plus sage de vérifier si vos serveurs prennent en charge la renégociation initiée par le client et de la désactiver chaque fois que cela est possible. En effet, même si cela ne résoudra pas tous vos problèmes car se défendre contre des attaques DoS est une opération à la fois difficile et coûteuse, cette procédure renforcera vos défenses contre cette technique d’attaque spécifique.

Ivan Ristic, responsable du laboratoire de recherche SSL chez Qualys