introduction
Le 14 octobre 2014, une vulnérabilité de la version 3 du protocole de cryptage SSL a été révélée. Cette vulnérabilité, baptisée POODLE (Padding Oracle On Downgraded Legacy Encryption), permet à un attaquant de lire des informations chiffrées avec cette version du protocole en texte brut à l'aide d'une attaque de type "man-in-the-middle".
Bien que SSLv3 soit une ancienne version du protocole qui est principalement obsolète, les logiciels demany retombent toujours sur SSLv3 si de meilleures options de cryptage ne sont pas disponibles. Plus important encore, il est possible pour un attaquant de forcer les connexions SSLv3 s'il s'agit d'une alternative disponible pour les deux participants tentant une connexion.
La vulnérabilité POODLE affecte tous les services ou clients permettant de communiquer avec SSLv3. Comme il s'agit d'une faille dans la conception du protocole et non d'un problème d'implémentation, le logiciel deevery qui utilise SSLv3 est vulnérable.
Pour en savoir plus sur la vulnérabilité, consultez les informations CVE trouvées surCVE-2014-3566.
Quelle est la vulnérabilité de POODLE?
La vulnérabilité POODLE est une faiblesse de la version 3 du protocole SSL qui permet à un attaquant situé dans un contexte d'interception de déchiffrer le contenu en texte brut d'un message chiffré SSLv3.
Qui est concerné par cette vulnérabilité?
Cette vulnérabilité concerne tous les logiciels pouvant être forcés de communiquer avec SSLv3. Cela signifie que tout logiciel mettant en œuvre un mécanisme de secours incluant la prise en charge de SSLv3 est vulnérable et peut être exploité.
Certains logiciels courants susceptibles d'être affectés sont les navigateurs Web, les serveurs Web, les serveurs VPN, les serveurs de messagerie, etc.
Comment ça marche?
En bref, la vulnérabilité POODLE existe car le protocole SSLv3 ne vérifie pas correctement les octets de remplissage qui sont envoyés avec les messages chiffrés.
S'ils ne peuvent pas être vérifiés par la partie destinataire, un attaquant peut les remplacer et les transmettre à la destination voulue. Lorsqu'elle est effectuée de manière spécifique, la charge utile modifiée sera potentiellement acceptée par le destinataire sans plainte.
Une moyenne d'une demande sur 256 sera acceptée à la destination, permettant à l'attaquant de déchiffrer un seul octet. Cela peut être répété facilement afin de décrypter progressivement des octets supplémentaires. Tout attaquant capable de forcer de manière répétée un participant à renvoyer des données à l'aide de ce protocole peut rompre le cryptage en très peu de temps.
Comment puis-je me protéger?
Des mesures doivent être prises pour que vous ne soyez pas vulnérable dans vos rôles de client et de serveur. Étant donné que le cryptage est généralement négocié entre les clients et les serveurs, il s'agit d'un problème impliquant les deux parties.
Les serveurs et les clients devraient prendre des mesures pour désactiver complètement la prise en charge de SSLv3. De nombreuses applications utilisent un meilleur cryptage par défaut, mais implémentent la prise en charge de SSLv3 en tant qu'option de secours. Cela doit être désactivé, car un utilisateur malveillant peut forcer la communication SSLv3 si les deux participants l'autorisent comme méthode acceptable.
Comment protéger les applications courantes
Ci-dessous, nous verrons comment désactiver SSLv3 sur certaines applications serveur courantes. Veillez à évaluer vos serveurs afin de protéger tout service supplémentaire pouvant s’appuyer sur le cryptage SSL / TCP.
Comme la vulnérabilité POODLE ne représente pas un problème de mise en œuvre et constitue un problème inhérent à l’ensemble du protocole, il n’existe aucune solution de contournement et la seule solution fiable consiste à ne pas l’utiliser.
Serveur Web Nginx
Pour désactiver SSLv3 sur le serveur Web Nginx, vous pouvez utiliser la directivessl_protocols. Celui-ci sera situé dans les blocsserver ouhttp de votre configuration.
Par exemple, sur Ubuntu, vous pouvez soit l'ajouter globalement à/etc/nginx/nginx.conf à l'intérieur du blochttp, soit à chaque blocserver dans le répertoire/etc/nginx/sites-enabled.
sudo nano /etc/nginx/nginx.confPour désactiver SSLv3, votre directivessl_protocols doit être définie comme ceci:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;Vous devez redémarrer le serveur après avoir apporté la modification ci-dessus:
sudo service nginx restartServeur Web Apache
Pour désactiver SSLv3 sur le serveur Web Apache, vous devrez ajuster la directiveSSLProtocol fournie par le modulemod_ssl.
Cette directive peut être définie au niveau du serveur ou dans une configuration d'hôte virtuel. En fonction de la configuration Apache de votre distribution, la configuration SSL peut être située dans un fichier distinct provenant de sources.
Sur Ubuntu, la spécification à l'échelle du serveur pour les serveurs peut être ajustée en éditant le fichier/etc/apache2/mods-available/ssl.conf. Simod_ssl est activé, un lien symbolique connectera ce fichier au sous-répertoiremods-enabled:
sudo nano /etc/apache2/mods-available/ssl.confSur CentOS, vous pouvez ajuster ceci dans le fichier de configuration SSL situé ici (si SSL est activé):
sudo nano /etc/httpd/conf.d/ssl.confÀ l'intérieur, vous pouvez trouver la directiveSSLProtocol. Si ce n'est pas disponible, créez-le. Modifiez ceci pour supprimer explicitement le support de SSLv3:
SSLProtocol all -SSLv3 -SSLv2Enregistrez et fermez le fichier. Redémarrez le service pour activer vos modifications.
Sur Ubuntu, vous pouvez taper:
sudo service apache2 restartSur CentOS, ce serait:
sudo service httpd restartHAProxy Load Balancer
Pour désactiver SSLv3 dans un équilibreur de charge HAProxy, vous devrez ouvrir le fichierhaproxy.cfg.
Ceci est situé à/etc/haproxy/haproxy.cfg:
sudo nano /etc/haproxy/haproxy.cfgDans votre configuration frontale, si SSL est activé, votre directivebind spécifiera l'adresse IP publique et le port. Si vous utilisez SSL, vous voudrez ajouterno-sslv3 à la fin de cette ligne:
frontend name
bind public_ip:443 ssl crt /path/to/certs no-sslv3Enregistrez et fermez le fichier.
Vous devrez redémarrer le service pour implémenter les modifications:
sudo service haproxy restartServeur VPN OpenVPN
Les versions récentes d'OpenVPN n'autorisent pas SSLv3. Le service n'est pas vulnérable à ce problème spécifique, vous n'aurez donc pas besoin d'ajuster votre configuration.
Serveur SMTP Postfix
Si votre configuration Postfix est configurée pour exiger le chiffrement, elle utilisera une directive appeléesmtpd_tls_mandatory_protocols.
Vous pouvez le trouver dans le fichier de configuration principal de Postfix:
sudo nano /etc/postfix/main.cfSi un serveur Postfix est configuré pour utiliser le cryptage à tout moment, vous pouvez vous assurer que SSLv3 et SSLv2 ne sont pas acceptés en définissant ce paramètre. Si vous ne forcez pas le cryptage, vous n'avez rien à faire:
smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3Enregistrez votre configuration. Redémarrez le service pour implémenter vos modifications:
sudo service postfix restartDovecot IMAP et serveur POP3
Afin de désactiver SSLv3 sur un serveur Dovecot, vous devrez ajuster une directive appeléessl_protocols. Selon les méthodes de conditionnement de vos distributions, les configurations SSL peuvent être conservées dans un autre fichier de configuration.
Pour la plupart des distributions, vous pouvez ajuster cette directive en ouvrant ce fichier:
sudo nano /etc/dovecot/conf.d/10-ssl.confÀ l'intérieur, si vous utilisez Dovecot 2.1 ou supérieur, définissez la directivessl_protocols pour désactiver SSLv2 et SSLv3:
ssl_protocols = !SSLv3 !SSLv2Si vous utilisez une version de Dovecot inférieure à 2.1, vous pouvez définir lessl_cipher_list pour interdire SSLv3 comme ceci:
ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL:!SSLv3Enregistrez et fermez le fichier.
Redémarrez le service afin de mettre en œuvre vos modifications:
sudo service dovecot restartProchaines étapes
Outre vos applications côté serveur, vous devez également mettre à jour les applications clientes.
En particulier, les navigateurs Web peuvent être vulnérables à ce problème en raison de leur négociation de protocole progressive. Assurez-vous que vos navigateurs n'autorisent pas SSLv3 en tant que méthode de cryptage acceptable. Cela peut être ajustable dans les paramètres ou via l'installation d'un plugin ou d'une extension supplémentaire.
Conclusion
En raison de la prise en charge généralisée de SSLv3, même lorsque le cryptage renforcé est activé, cette vulnérabilité est considérable et dangereuse. Vous devrez prendre des mesures pour vous protéger en tant que consommateur et fournisseur de toute ressource utilisant le cryptage SSL.
Assurez-vous de vérifier tous vos services accessibles au réseau qui peuvent tirer parti de SSL / TLS sous n’importe quelle forme. Souvent, ces applications nécessitent des instructions explicites pour désactiver complètement les formes de chiffrement plus faibles telles que SSLv3.