Opérations Afnic : Vulnérabilités TLS de l'article "The most dangerous code"
La publication récente de l'article "The Most Dangerous Code in the World" a attiré l'attention sur des failles de sécurité dans des clients TLS [...]La publication récente de l'article « The Most Dangerous Code in the World : Validating SSL Certificates in Non-Browser Software » par Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh et Vitaly Shmatikov (CCS '12 Proceedings of the 2012 ACM conference on Computer and communications security Pages 38-49 ACM New York, NY, USA ©2012) a attiré l'attention sur des failles de sécurité très fréquentes dans d'innombrables clients TLS (ex-SSL), souvent critiques. Il est possible que cela concerne le client EPP que vous utilisez pour vous connecter au serveur EPP de l'AFNIC.
Si vous avez écrit ce client EPP vous-même, nous vous recommandons, à la lecture de l'article, de vérifier les points suivants :
Pour résumer l'article cité, des tas d’applications parfois peu connues et discrètes (par exemple pour réaliser la mise à jour des logiciels d’un système) utilisent, comme les navigateurs Web, TLS pour se protéger contre un méchant qui essaierait de détourner le trafic vers un autre serveur que celui visé. Mais, contrairement aux navigateurs Web, ces applications, souvent critiques (paiement entre cyber-marchands, par exemple) n’ont guère été étudiées et ont des vulnérabilités souvent énormes, permettant à un attaquant de se faire passer pour le serveur légitime, malgré TLS.
Les auteurs de l’article, après avoir cassé la sécurité de TLS dans des dizaines d’applications importantes, suggèrent des API mieux documentées, plus claires et de plus haut niveau, pour diminuer le risque que les programmeurs se trompent.
Une façon de tester que votre client gère correctement la sécurité est de créer un nom de domaine quelconque (par exemple epp.votre-domaine-à-vous.fr) et de le faire pointer vers l'adresse IP du serveur EPP de l'AFNIC, puis d'utiliser le client EPP pour s'y connecter. Cela devrait normalement échouer (le nom ne correspond pas). Il est important de ne pas tester seulement que le logiciel fonctionne quand tout est normal, mais aussi qu'il rejette la connexion lorsqu'un problème se présente.
Pour en lire plus...
La publication récente de l'article "The Most Dangerous Code in the World" a attiré l'attention sur des failles de sécurité dans des clients TLS [...]La publication récente de l'article « The Most Dangerous Code in the World : Validating SSL Certificates in Non-Browser Software » par Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh et Vitaly Shmatikov (CCS '12 Proceedings of the 2012 ACM conference on Computer and communications security Pages 38-49 ACM New York, NY, USA ©2012) a attiré l'attention sur des failles de sécurité très fréquentes dans d'innombrables clients TLS (ex-SSL), souvent critiques. Il est possible que cela concerne le client EPP que vous utilisez pour vous connecter au serveur EPP de l'AFNIC.
Si vous avez écrit ce client EPP vous-même, nous vous recommandons, à la lecture de l'article, de vérifier les points suivants :
- que le client EPP valide le certificat présenté par l'AFNIC
- que le client vérifie que le nom présenté dans le certificat corresponde au nom du serveur EPP demandé (la plupart des bibliothèques TLS ne le font pas automatiquement)
- que la bibliothèque est utilisée correctement. L'article cité plus haut fait remarquer que les API des bibliothèques TLS sont incohérentes, dangereuses et mal documentées.
Pour donner un exemple des erreurs qui se produisent : la bibliothèque cURL, très utilisée par d’innombrables applications, a un paramètre CURLOPT_SSL_VERIFYHOST. La documentation dit bien qu’il doit être mis à 2 (sa valeur par défaut) pour que le nom soit vérifié et à 1 pour couper la vérification. Bien des programmes écrits dans des langages sans typage fort (comme PHP), mettent ce paramètre à « true », donc à 1, coupant ainsi la validation par accident...
Pour résumer l'article cité, des tas d’applications parfois peu connues et discrètes (par exemple pour réaliser la mise à jour des logiciels d’un système) utilisent, comme les navigateurs Web, TLS pour se protéger contre un méchant qui essaierait de détourner le trafic vers un autre serveur que celui visé. Mais, contrairement aux navigateurs Web, ces applications, souvent critiques (paiement entre cyber-marchands, par exemple) n’ont guère été étudiées et ont des vulnérabilités souvent énormes, permettant à un attaquant de se faire passer pour le serveur légitime, malgré TLS.
Les auteurs de l’article, après avoir cassé la sécurité de TLS dans des dizaines d’applications importantes, suggèrent des API mieux documentées, plus claires et de plus haut niveau, pour diminuer le risque que les programmeurs se trompent.
Une façon de tester que votre client gère correctement la sécurité est de créer un nom de domaine quelconque (par exemple epp.votre-domaine-à-vous.fr) et de le faire pointer vers l'adresse IP du serveur EPP de l'AFNIC, puis d'utiliser le client EPP pour s'y connecter. Cela devrait normalement échouer (le nom ne correspond pas). Il est important de ne pas tester seulement que le logiciel fonctionne quand tout est normal, mais aussi qu'il rejette la connexion lorsqu'un problème se présente.
Pour en lire plus...
