Protéger NGINX et NGINX Plus contre l’attaque POODLE visant SSLv3 (CVE-2014-3566)

Owen GarrettDirecteur senior de la gestion des produits

Une vulnérabilité récemment signalée dans la version 3 du protocole SSL (SSLv3) peut être exploitée dans le cadre d’une attaque de l’homme du milieu afin d’extraire des parties d’une transmission en texte clair chiffrée avec HTTPS. Des chercheurs de Google ont publié une explication détaillée décrivant comment une telle attaque pourrait être menée.

Il ne s’agit pas d’une vulnérabilité propre à une implémentation de SSL/TLS, mais d’une faille dans la conception du protocole SSLv3 lors de l’utilisation d’algorithmes de chiffrement par blocs. Comme tous les autres algorithmes de chiffrement par flot présentent également des faiblesses, la seule solution consiste à désactiver SSLv3 dans vos configurations NGINX et NGINX Plus.

Désactivation de SSLv3 dans NGINX

SSLv3 est activé par défaut dans NGINX et NGINX Plus, et peut être utilisé par les services HTTP et de messagerie.

[Note de la rédaction – La mise en proxy et la répartition de charge du trafic TCP n’étaient pas entièrement prises en charge lors de la publication initiale de cet article. Par souci d’exhaustivité, les étapes suivantes ont été mises à jour afin d’inclure la protection du trafic TCP.]

Effectuez les étapes suivantes sur toutes les instances NGINX et NGINX Plus :

1. Supprimez SSLv3 de l’ensemble des protocoles utilisés pour le trafic HTTP. Ajoutez la directive suivante ssl_protocols au bloc http{} si elle n’existe pas, ou modifiez la directive existante afin de supprimer SSLv3 de la liste des paramètres.

# in the http{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)

1. Créez ou modifiez la même directive dans le bloc de configuration mail{} si vos instances NGINX ou NGINX Plus gèrent le trafic de messagerie.

# in the mail{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)

1. Créez ou modifiez la même directive dans le bloc de configuration stream{} si vos instances NGINX ou NGINX Plus gèrent du trafic TCP.

# in the stream{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)

1. Repérez toutes les autres occurrences de la directive ssl_protocols dans votre configuration (elle peut être incluse dans un bloc de configuration server{} au sein des blocs http{}, mail{} et stream{}). Nous vous recommandons de supprimer ces directives ssl_protocols, mais vous devez au minimum retirer SSLv3 de la liste des paramètres :

# in every server{} block ssl_protocols TLSv1 TLSv1.1 TLSv1.2;# omit SSLv3 because of POODLE (CVE‑2014‑3566)

1. Exécutez la commande suivante pour recharger la configuration :

# nginx –s reload

Quel est l’effet de cette modification ?

Tous les navigateurs modernes et clients d’API prennent en charge TLSv1 et les versions ultérieures. La désactivation de SSLv3 gênera les utilisateurs de WindowsXP qui naviguent avec Internet Explorer 6 ; CloudFlare estime que 1,12 % des utilisateurs de WindowsXP (qui représentent 3,12 % de son trafic) seront concernés, soit environ 1 utilisateur sur 3 000.

Cette modification pourrait également affecter les robots d’indexation et le trafic généré par d’autres robots automatisés.

L’avenir

Lors d’une attaque par rétrogradation SSL, l’attaquant peut perturber les négociations SSL/TLS et amener le client et le serveur à sélectionner une version antérieure de SSL/TLS. Lorsqu’elle est utilisée pour forcer la sélection de SSLv3, cette attaque peut rendre la connexion SSL/TLS vulnérable à l’attaque POODLE. La désactivation de SSLv3 sur le serveur rend cette attaque impossible.

Google a proposé une extension de SSL/TLS nommée « TLS_FALLBACK_SCSV », qui vise à empêcher les rétrogradations forcées de SSL/TLS. [Note de l’éditeur – L’extension a été adoptée sous la référence RFC 7507 en avril 2015.] Cette extension pourrait à terme être intégrée à OpenSSL, et la prise en charge correspondante côté client ajoutée aux principaux navigateurs. Les services web pourront ainsi prendre en charge SSLv3, mais les clients anciens resteront vulnérables.

Néanmoins, cette vulnérabilité pourrait sonner le glas de SSLv3, ce qui constituerait globalement une solution plus simple et plus fiable.

Que puis-je faire d’autre ?

Nous vous recommandons de mettre à jour votre logiciel client afin qu’il ne prenne plus en charge SSLv3. Vous serez ainsi protégé contre cette attaque lorsque vous accéderez à des services qui n’ont pas encore été mis à jour pour désactiver SSLv3.

Pour aller plus loin

• Le rapport initial sur la vulnérabilité
• Une explication plus concise d’ImperialViolet
• Plusieurs fournisseurs ont publié des recommandations ; celle d’Ubuntu est particulièrement complète

À propos de l’auteur

Owen GarrettDirecteur senior de la gestion des produits

Autres articles de Owen Garrett