Outils NSS de contrôle des CRL et CA
NSS (Network Security Services) est un ensemble de librairies OpenSource utilisées par différents projets, en particulier les produits Mozilla (Firefox, Thunderbird, Seamonkey, etc.). L'un des modules livrés par NSS est la librairie libnssckbi.so qui contient les certificats des autorités de certification et les droits associés. NSS supporte également les CRLs (LRC en français = Liste de Révocation de Certificats), mais les produits finaux sous utilisent ces propriétés.
Quel est le problème avec les autorités de certification pré-chargées par NSS ?
Que ce soit les produits Microsoft ou ceux basés sur NSS, la plupart des outils de navigation web implémentant SSL/TLS sont livrés avec une liste d'autorité de certification (CA) activés par défaut, et donc considérés comme "de confiance" par l'utilisateur lambda. Evidement il faut bien reconnaitre que pour l'utilisateur lambda, la présence d'une liste par défaut de CA lui évite d'avoir à se poser la question quel organisme est "de confiance". L'éditeur du produit a choisi pour lui, sur des critères inconnus (financiers, technique, etc.)...
Pourtant cette problématique de la confiance se pose de plus en plus. Les autorités sont plus ou moins libre de choisir le niveau de vérification fait pour émettre un certificat, à partir du moment où il est documenté dans leur CPS (DPC en français = Déclaration des Pratiques de Certification). Et avec les années, des autorités ont émis des certificats avec des niveaux de vérification très variables. Nous estimons que certaines pratiques sont douteuses pour ne pas dire dangereuses (certificats 1-facteur), et nuisent à la confiance que l'utilisateur place dans dans son navigateur SSL/TLS.
Chez TBS Internet, nous baignons dans ces problématiques de confiance depuis 1996, depuis que nous délivrons des certificats SSL (nous sommes un acteur majeur du courtage en certificat en France). Il nous fallait trouver une solution pour que les postes de nos utilisateurs ne reconnaissent que les certificats des autorités de certification auxquelles nous accordons notre confiance. Il s'agit principalement des autorités de certification avec lesquelles nous travaillons et qui délivrent des certificats serveur de type 3-facteur ou EV.
Nous avons donc développé un outil simple qui permet de désactiver tous les certificats des autorités que nous ne reconnaissons pas comme "de confiance", et qui permet d'imposer des droits sur les certificats des autorités que nous reconnaissons.
Quel est le problème avec les CRLs des produits utilisant NSS ?
Les produits se basant sur NSS ont un défaut majeur: ils n'utilisent pas les fonctions de CRL. Dans Firefox 3 par exemple, il y a bien la possibilité de configurer des CRLs à consulter, mais aucune CRL n'est configurée par défaut ! C'est tout de même un comble que plus de 120 autorités de certification (CA) soient livrés par défaut, mais 0 CRL permettant de vérifier les certificats émis par ces mêmes CA. Néanmoins l'utilisateur peut manuellement importer une CRL... mais il sera ensuite confronté à un bug dangereux : la mise à jour automatique des CRL ne fonctionne pas ! (voir bug 371522)
Il y a donc deux failles majeures : les CRLs des autorités par défaut ne sont pas livrées, et quand bien même, une CRL importée ne se met pas à jour ! Nous avons donc développé un outil simple qui télécharge et importe les CRLs dans la base utilisateur NSS. Evidement ce n'est pas la panacée car la liste des CRLs à importer est statique, et ne contient pas toutes les CRLs des certificats intermédiaires potentiellement utilisées par les CA "de confiance".
Il est important de prendre conscience que IE7 et Opera 9.5 implémentent correctement, et consultent par defaut les CRLs. Depuis la révocation massive de certificats dues au bug OpenSSL Debian, la fonctionnalité de consultation automatique des CRLs est impérative. Firefox 3 est à ce titre un mauvais élève, et nous attendons avec impatience l'implémentation des crlDistributionPoint (voir bug 321755).
Pré-requis pour utiliser nos outils
Nous fournissons ici, sous licence Artistic, les outils mis au point et utilisés dans notre entreprise, pour nos propres besoins. Ils sont fonctionnels sous Linux, mais il est certainement possible de les adapter pour Windows ou MacOS. Nos outils sont livrés avec nos bases de données, qui devront être personnalisées par vos soins pour s'ajuster à VOS besoins.
Nos outils nécessitent :
- les binaires certutil et crlutil livrés dans la plupart des distributions dans le paquet libnss3-tools ou mozilla-nss-tools. Nous recommandons d'utiliser une version de NSS 3.11 ou supérieure (non testé en dessous).
- bash
- perl
- curl
- cron
Faites une sauvegarde des fichiers cert8.db et key3.db avant de commencer.
nss_update_crl : mise à jour des CRLs
Le programme nss_update_crl prend un seul paramètre : le chemin vers le répertoire contenant votre fichier cert8.db. Il y a un répertoire pour chaque profil utilisateur créé par votre produit mozilla (Firefox, Mozilla, Seamonkey, Thunderbird). Regardez dans ~/.mozilla/firefox/(Nom du profil)/ ou ~/.thunderbird/(Nom du profil)>/ ou ~/.mozilla-thunderbird/(Nom du profil)/ . Le Nom du profil est de la forme xxxxxxxx.slt ou xxxxxxxx.default.
Pour lancer le programme, il faut appeler nss_update_crl ~/.mozilla/firefox/(Nom du profil)/ sur une ligne de commande. Nous vous conseillons de placer le programme dans ~/bin/.
Le programme lit un fichier de données qui contient les CRLs à charger. Ce fichier doit se trouver par défaut dans ~/bin/nss_update_crl.list. ATTENTION : le fichier que nous vous proposons est le notre, c'est à dire celui qui convient à notre politique de sécurité (liste réduite des autorités de confiance, voir plus bas). C'est votre responsabilité de le passer en revue et d'y ajouter les éventuelles autres CRL des autorités auxquelles vous faites confiance.
La structure de ce fichier ~/bin/nss_update_crl.list est simple : toutes les lignes contiennent les URLs à charger, sauf les lignes qui commencent par un dièse (#) qui sont des commentaires.
En cas d'erreur d'importation (cela arrive !), un répertoire ~/tmp/nss_update_crl-error-xxxxxxxxxx/ est laissé avec l'URL chargée, le message d'erreur, et le fichier CRL en lui même.
Une fois le programme testé à la main, nous vous invitons à utiliser cron pour lancer périodiquement et automatiquement la mise à jour des CRLs. Pour se faire, utilisez une ligne comme celle ci-dessous, en choisissant une valeur entre 0 et 59 à la place de ZZ au hazard (afin de ne pas tous télécharger les CRL à la même minute). Vous pouvez également modifier les heures (9,11,15,19).
ZZ 9,11,15,19 * * * ~/bin/nss_update_crl ~/.mozilla/firefox/(Nom du profil)/nss_restrict_ca : restriction des CA de confiance
Le programme nss_restrict_ca prend un paramètre : le chemin vers le répertoire contenant votre fichier cert8.db. Il y a un répertoire pour chaque profil utilisateur créé par votre produit mozilla (Firefox, Mozilla, Seamonkey, Thunderbird). Regardez dans ~/.mozilla/firefox/(Nom du profil)/ ou ~/.thunderbird/(Nom du profil)>/ ou ~/.mozilla-thunderbird/(Nom du profil)/ . Le Nom du profil est de la forme xxxxxxxx.slt ou xxxxxxxx.default.
Le programme travaille par défaut sur le magasin de sécurité logiciel. Il peut aussi travailler sur le magasin fourni par libnssckbi.so : le Builtin Object Token ; dans ce second cas il faut indiquer --builtin en premier paramètre.
Le programme lit un fichier de données qui contient les certificats à configurer. Ce fichier doit se trouver par défaut dans ~/bin/nss_restrict_ca.list. ATTENTION : le fichier que nous vous proposons est le notre, c'est à dire celui qui convient à notre politique de sécurité (liste réduite des autorités de confiance). C'est votre responsabilité de le passer en revue et d'y ajouter les éventuelles autres autorités auxquelles vous faites confiance. Pensez aussi à sauvegarder votre fichier cert8.db avant première utilisation.
La logique du programme est simple : toute autorité trouvée dans le magasin traité et qui n'est pas documenté dans notre fichier de données est désactivé. Si une correspondance est trouvée, alors les droits définis dans notre fichier sont appliqués. Ainsi nous imposons que seules les autorités déclarées dans notre fichier et les droits associés sont en vigueur.
La syntaxe du fichier de données est soit des lignes de commentaires (commencent par par un dièse (#)), soit des lignes sous la forme :
(Nom de l'autorité) (drapeaux NSS)Le Nom de l'autorité doit correspondre exactement à ce que la base NSS contient, c'est à dire le nom visible avec :
certutil -L -d chemin_vers_votre_profil ou certutil -L -h "Builtin Object Token" -d chemin_vers_votre_profilPour la signification des drapeaux NSS, voir la documentation NSS de trustargs
Pour constituer votre version du fichier de droits, vous pouvez commencer par modifier les lignes que nous avons laissé en commentaire, ou rajouter des commentaires sur les lignes. Lors de la première exécution, vous aurez la liste des certificats désactivé à l'écran. Etudiez là attentivement pour éventuellement compléter votre fichier. Il n'est généralement pas nécessaire d'accorder des droits aux certificats intermédiaires, sauf lorsqu'ils constituent la chaîne d'un certificat personnel/utilisateur.
Notez bien que notre outil n'importe rien dans la base NSS. Rajouter le nom d'un certificat qui ne serait pas déjà dans la base n'a aucun effet.
Nous recommandons de fermer vos navigateurs pendant l'exécution de cet outil les premières fois (risque d'accès concurrents avec beaucoup de modifications). Une fois le programme lancé plusieurs fois à la main pour optimiser votre fichier de droits, nous vous invitons à utiliser cron pour lancer périodiquement et automatiquement la mise à jour. Cela vous permettra de désactiver tout ajout ultérieur de certificat CA (vous ne voulez pas que les utilisateurs ajoutent des CA) ou de rétablir des droits modifiés (dans un tel cas, un avertissement est affiché).
Pour se faire, utilisez les lignes ci-dessous, en modifiant éventuellement les minutes et les heures.
1 12 * * * ~/bin/nss_restrict_ca --builtin ~/.mozilla/firefox/(Nom du profil)/ 2 12 * * * ~/bin/nss_restrict_ca ~/.mozilla/firefox/(Nom du profil)/Nos tests ont montré un fonctionnement bizarre lorsqu'on se contente de travailler sur le magasin logiciel, c'est pour cela que vous recommandons d'appeler 2 fois le programme afin de travailler sur les 2 magasins (ceinture et bretelles).
Au final
Nous utilisons ces deux outils sur les postes de nos employés. Ils nous permettent de nous assurer que seules les autorités de certification auxquelles nous faisons confiance sont activés. Plus de risque de se faire avoir par un SSL établi avec un certificat à faible authentification.
En controlant les autorités autorisées, il nous est plus facile d'identifier et de charger les CRLs correspondantes. Ainsi nos utilisateurs seront correctement prévenus si le certificat présenté n'est plus valide.
Téléchargement V1.0
Après toute cette lecture, c'est ici que l'on télécharge :
Améliorations de 2009 (v2.0)
En 2009, nous avons amélioré les scripts afin de pouvoir lancer le script sous root, nss_root_util, et qu'il traite tous les utilisateurs de la machine. Il permet d'appliquer une politique globale, et de faire des exceptions au niveau d'un utilisateur. Nous avons aussi ajoutés aux outils d'origine la possibilité de tester le fichier cert8.db après avoir mis à jour les CRLs ou les CA, car régulièrement, certutil plante et rend un fichier cert8.db corrompu.
Téléchargement V2.0
Feedback
Un commentaire sur cet article ? Votre avis nous intéresse. Ecrivez à tag-nss-tools@TBS-internet.com
Nos tarifs sont en euro HT en paiement comptant à la commande, voir aussi nos conditions générales de ventes.