Protection de NGINX et NGINX Plus contre l'attaque POODLE contre SSLv3 (CVE-2014-3566)

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

Il ne s’agit pas d’une vulnérabilité dans une quelconque implémentation de SSL/TLS, mais plutôt d’une vulnérabilité dans la conception du protocole SSLv3 lors de l’utilisation de chiffrements par blocs. Comme tous les chiffrements de flux alternatifs présentent également des faiblesses, la seule mesure consiste à désactiver SSLv3 dans vos configurations NGINX et NGINX Plus.

Désactiver SSLv3 dans NGINX

SSLv3 est activé par défaut dans NGINX et NGINX Plus, et est potentiellement utilisé par les services HTTP et Mail.

[Éditeur – Le proxy et l’équilibrage de charge du trafic TCP n’étaient pas entièrement pris en charge lorsque cet article a été publié à l’origine. Par souci d'exhaustivité, les étapes suivantes ont été mises à jour pour inclure la protection du trafic TCP.]

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

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

   # dans la configuration http{} blockssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; # omettre SSLv3 à cause de POODLE (CVE‑2014‑3566)

2. 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.

   # dans les blocs de configuration mail{} sl_protocols TLSv1 TLSv1.1 TLSv1.2 ; # omettre SSLv3 à cause de POODLE (CVE‑2014‑3566)

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

   # dans les blocs de configuration stream{} sl_protocols TLSv1 TLSv1.1 TLSv1.2 ; # omettre SSLv3 à cause de POODLE (CVE‑2014‑3566)

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

   # dans chaque serveur{} bloquer ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ;# omettre SSLv3 à cause de POODLE (CVE‑2014‑3566)

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

   # nginx –s recharger

Quel est l’effet de ce changement ?

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

Le changement pourrait également affecter les robots d’exploration Web et d’autres trafics de robots automatisés.

L'avenir

Lors d'une attaque de 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'il est utilisé pour forcer la sélection de SSLv3, il 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 à SSL/TLS appelée TLS_FALLBACK_SCSV qui vise à empêcher les rétrogradations forcées de SSL/TLS. [Éditeur – L'extension a été adoptée en tant que RFC 7507 en avril 2015.] Cette extension pourrait éventuellement être acceptée dans OpenSSL, et la prise en charge côté client correspondante ajoutée aux principaux navigateurs. Cela permettra aux services Web de prendre en charge SSLv3, mais les clients hérités seront toujours vulnérables.

Néanmoins, cette vulnérabilité pourrait bien être le coup fatal pour SSLv3 – une solution globalement 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 pas en charge SSLv3. Cela vous protégera de cette attaque lorsque vous accéderez à des services qui n'ont pas été mis à jour pour désactiver SSLv3.

Lectures complémentaires

• Le rapport de vulnérabilité original
• Une explication plus concise de ImperialViolet
• Plusieurs fournisseurs ont publié des recommandations ; celle d'Ubuntu est particulièrement complète