Qu'est-ce que Logjam et comment puis-je l'empêcher?
J'ai entendu qu'il y avait une "nouvelle" vulnérabilité TLS nommée Logjam , que fait-elle et comment puis-je la prévenir?
TL; DR
Le client et le serveur SSL/TLS acceptent d'utiliser une cryptographie faible. Eh bien, il s'avère que le crypto faible est faible.
En détail
Lorsqu'un protocole SSL/TLS est exécuté, le client envoie une liste des suites de chiffrement prises en charge et le serveur en choisit une. À la fin de la poignée de main initiale, certains messages Finished sont échangés et cryptés/protégés avec les algorithmes de cryptographie nouvellement négociés, et le contenu de ces messages est un hachage de tous les messages précédents.
L'idée est qu'un attaquant actif (une attaque MitM ) pourrait essayer de manipuler la liste des suites de chiffrement envoyées par le client pour supprimer toutes les suites de chiffrement "fortes", en ne gardant que les plus faibles que le client et le serveur soutien. Cependant, cela casserait les messages Finished. Ainsi, ces messages sont destinés (entre autres rôles) à détecter de telles attaques downgrade.
En théorie, c'est bien; à moins que le client et le serveur ne prennent tous les deux en charge une suite de chiffrement si faible que l'attaquant MitM puisse la casser tout de suite, démêler toute la couche cryptographique et corriger un message Finished dans temps réel. C'est ce qui se passe ici.
Encore plus de détails
Lors de l'utilisation des suites de chiffrement "DHE" (comme dans "Diffie-Hellman Ephemeral"), le serveur envoie les "paramètres DH" (module et générateur) avec lesquels le client et le serveur effectueront un échange de clés Diffie-Hellman . De plus, le serveur signe ce message avec sa clé privée (généralement une clé RSA, car tout le monde utilise RSA en pratique). Le client vérifie cette signature (la clé publique est celle du certificat de serveur), puis utilise le paramètre DH pour terminer l'échange de clés.
Il se trouve qu'au siècle précédent, il y avait des réglementations d'exportation américaines assez strictes sur la cryptographie, ce qui a provoqué des "suites de chiffrement à l'exportation", c'est-à-dire une cryptographie faible qui était compatible avec ces réglementations. De nombreux serveurs SSL prennent toujours en charge ces "suites de chiffrement d'exportation". En particulier, certaines suites de chiffrement qui utilisent DHE et exigent un module DH ne dépassant pas 512 bits. De plus, la plupart des SSL des serveurs utilisent le module idem, car il est plus facile d'utiliser celui fourni avec la bibliothèque SSL que d'en générer le vôtre. Réutiliser le même module que tout le monde n'est pas un gros problème; DH tolère cela très bien. Cependant, cela signifie que si un attaquant investit beaucoup de calculs pour casser une instance DH qui utilise un module donné p, le même attaquant peut réutiliser presque tout le travail pour casser d'autres instances qui utilisent le même module p.
Donc, l'attaque se déroule comme ceci:
- L'attaquant est en position MitM; où il peut modifier les flux de données en temps réel,
- L'attaquant modifie la liste des suites de chiffrement envoyées par le client pour spécifier l'utilisation d'une suite de chiffrement DHE d'exportation,
- Le serveur est conforme et envoie un module de 512 bits p,
- Le client est toujours persuadé qu'il fait un DHE non-export, mais un module DH est un module DH, donc le client accepte très bien le module faible/export du serveur,
- L'attaquant utilise ses précalculs sur cette valeur p pour casser le DH en temps réel et corriger les messages
Finished.
Les auteurs article de Logjam appellent cela une "faille de protocole" car le message ServerKeyExchange qui contient les paramètres DH d'exportation n'est pas étiqueté comme "pour l'exportation", et est donc indiscernable (sauf pour le longueur du module) à partir d'un message ServerKeyExchange contenant des paramètres DH non exportables. Cependant, je dirais que le vrai défaut n'est pas là; le vrai problème est que le client et le serveur acceptent d'utiliser un module DH de 512 bits même s'ils savent tous les deux qu'il est faible.
Que devez-vous faire?
Eh bien, la même chose que toujours: installez les correctifs de vos éditeurs de logiciels. En fait, cela devrait aller de soi.
Côté client, Microsoft a déjà patché Internet Explorer pour refuser d'utiliser un module trop petit. Un correctif pour Firefox sous la forme d'un plugin par Mozilla est disponible ici maintenant. Il est prévu que d'autres éditeurs de navigateurs (Opera, Chrome ...) suivront bientôt.
Côté serveur, vous pouvez explicitement désactiver la prise en charge des suites de chiffrement "d'exportation" et générer vos propres paramètres DH. Voir cette page pour plus de détails. Notez que IIS est un peu à l'abri de tout cela car apparemment, il n'a jamais pris en charge les suites de chiffrement DHE avec autre chose qu'un certificat de serveur DSS, et personne n'utilise DSS.
Notez que [~ # ~] ecdhe [~ # ~] les suites de chiffrement, dans lesquelles "EC" signifiant "courbe elliptique", ne sont pas menacées ici, car:
- Il n'y a pas de suites de chiffrement ECDHE "d'exportation" (les suites de chiffrement ECDHE ont été définies après la levée considérable de la réglementation américaine en matière d'exportation).
- Les clients en général ne prennent en charge que quelques courbes spécifiques (généralement seulement deux d'entre elles, P-256 et P-384) et aucune n'est suffisamment faible pour être cassée (pas maintenant, pas dans un avenir prévisible non plus).
Et qu'en est-il du NSA?
Les chercheurs de Logjam ont discuté de la façon dont certains "attaquants dotés de ressources d'État-nation" pourraient percer la DH 1024 bits. C'est tout à fait un tronçon. D'après mon expérience, les États-nations ont en effet beaucoup de ressources et dépensent bien, mais ce n'est pas la même chose que de réussir à briser la crypto dure.
Néanmoins, si vous craignez que le DH de 1024 bits soit "trop faible", optez pour le 2048 bits (c'est celui qui est recommandé de toute façon), ou ECDHE.
Ou acceptez simplement que les gens avec des ressources écrasantes ont vraiment des ressources écrasantes et ne seront pas vaincus par une simple taille de module. Ceux qui peuvent dépenser des milliards de dollars pour des machines de craquage peuvent également soudoyer vos enfants avec quelques centaines de dollars pour parcourir vos fichiers informatiques et votre portefeuille.
Logjam ne devrait pas vraiment être appelé une "nouvelle" vulnérabilité - c'est une refonte de FREAK qui cible DH de qualité exportation plutôt que RSA de qualité exportation.
L'exploitation pratique repose sur les défauts suivants:
- Le protocole TLS est vulnérable à la dégradation de son protocole d'échange de clés par un attaquant.
- Les serveurs prennent toujours en charge Diffie-Hellman de qualité export (par exemple, les clés 512 bits)
- Pour des raisons de performances, de nombreuses implémentations codent en dur un nombre premier commun. Cette nuance peut être utilisée à mauvais escient afin de précalculer une partie d'une attaque à l'avance pour tout serveur qui utilise ce premier.
L'attaque permet essentiellement à un attaquant de précalculer un ensemble de données pour un nombre cible cible connu pour être utilisé par un service TLS dans son implémentation DH. Pour la DH 512 bits, cela prend environ une semaine. Une fois cela fait, l'attaquant peut casser les échanges de clés DH avec ce service en environ 1-2 minutes par échange. Une fois l'échange rompu, l'attaquant accède aux clés de session, leur permettant de décrypter tout le trafic.
Ce problème peut être résolu de la manière suivante:
- Désactivez les chiffres de qualité export.
- Utilisez la courbe elliptique DH (ECDHE) plutôt que le champ fini DH. Cela rend l'attaque beaucoup plus difficile dans la pratique en raison du moindre avantage du précalcul.
- Générez un groupe DH unique pour une grande taille principale telle que 2048 bits, et utilisez-le à la place d'un groupe largement partagé par défaut.
En remarque, l'un des facteurs intéressants de ce bogue est qu'il correspond aux capacités signalées de la NSA dans le domaine du décryptage du trafic TLS et IKE (VPN). Dans le cas de la capture et du décryptage de trafic de masse, l'attaque de pré-calcul devient particulièrement efficace et effective, en raison de la grande quantité de données disponibles qui est susceptible d'être associée à un nombre premier partagé connu.
Plus de détails disponibles:
Logjam est une attaque de déclassement de chiffrement où un homme au milieu peut tromper les points finaux en utilisant un chiffrement faible. Un chiffrement faible permettrait à l'homme au milieu de décrypter facilement le trafic intercepté.
Comme pour toutes les autres attaques de déclassement de chiffrement, la meilleure façon de l'empêcher est de désactiver les chiffrements faibles en premier lieu. Si des chiffrements faibles ne sont pas disponibles, même une rétrogradation de chiffrement réussie entraînera un cryptage fort.
Pour éviter Logjam, vous pouvez suivre les recommandations du Guide to Deploying Diffie-Hellman for TLS qui vous aideront à configurer votre serveur (Apache HTTP Server, nginx, IIS, Lighttpd, Tomcat, Postfix, Sendmail, Dovecot , HAProxy, OpenSSH, Amazon Elastic Beanstalk):
- Testez si votre serveur est sûr
- Créer un groupe Diffie-Hellman fort et unique
- Déployer les suites de chiffrement ECDHE
- Désactiver les suites de chiffrement d'exportation
Mozilla SSL Configuration Generator est également un bon outil de configuration.