Journal Le retrait des certificats racines de WoSign et StartCom est planifié par Mozilla

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
27
31
août
2017

L'année dernière, suite à quelques déboires de gestion des certificats générés, Mozilla avait annoncé ne plus faire confiance aux nouveaux certificats signés par les autorités de certifications WoSign et StartCom.

Lors de cette annonce, Mozilla avait annoncé qu'ils envisageraient de retirer complètement ces autorités de leurs autorités de confiance. Ils viennent d'annoncer que cette action sera entreprise pour Firefox 58 qui sera livré en janvier 2018.

Vérifiez donc que les certificats de vos sites préférés ne sont pas chaînés avec un de ces certificats racines:

  • CA 沃通根证书
  • Certification Authority of WoSign
  • Certification Authority of WoSign G2
  • CA WoSign ECC Root
  • StartCom Certification Authority
  • StartCom Certification Authority G2

  • # distrib

    Posté par  . Évalué à 6. Dernière modification le 31 août 2017 à 11:55.

    Le rapport est faible avec la news, mais je viens de me poser la question: dans les paquets firefox proposés par les distribs (enfin, celles qui ne se contentent pas de «repackager une tarball après compilation» si vous voyez ce que je veux dire), les certificats acceptés par la MoFo sont installés via le paquet firefox, non?

    Si oui, ne serait-il pas plus pertinent d'avoir un ou plusieurs paquets séparés (de firefox ou n'importe quel autre browser) pour les certificats, un peu comme pour les fontes? Au fond, ce ne sont pas des données nécessaires techniquement au fonctionnement d'un navigateur, et ça permettrait à l'administrateur d'avoir un contrôle plus aisé de à qui faire confiance (plutôt que de devoir intervenir manuellement comme je suppose que c'est le cas autrement).

    Dans la même veine, quid des distrib type Debian qui ne sont pas orientées MàJ fréquentes? Me semble que FF à un passe-droit, mais justement, est-ce vraiment pertinent pour toutes les données?

    • [^] # Re: distrib

      Posté par  . Évalué à 10.

      Si oui, ne serait-il pas plus pertinent d'avoir un ou plusieurs paquets séparés pour les certificats

      C’est déjà le cas, au moins sur certaines distributions. Debian a un paquet ca-certificates contenant les certificats racines, de même que Slackware¹. Je ne serais pas étonné que d’autres distributions fassent la même chose.

      En pratique ce paquet ne contient pour l’instant que les certificats des racines reconnues par Mozilla, mais en théorie il pourrait contenir des certificats provenant d’autres sources (à une époque il contenait par exemple le certificat racine de CAcert).

      ça permettrait à l'administrateur d'avoir un contrôle plus aisé de à qui faire confiance

      C’est le but du paquet ca-certificates. Il installes les certificats non pas directement dans /etc/ssl/certs, mais dans /usr/share/ca-certificates, et il fournit l’outil update-ca-certificates(8) pour créer des liens symboliques dans /etc/ssl/certs (l’administrateur ayant la possibilité de « désactiver » les racines dont il ne veut pas dans /etc/ca-certificates.conf, et d’ajouter des racines supplémentaires dans /usr/local/share/ca-certificates).

      À noter tout de même que ce paquet n’est absolument pas utilisé par Firefox, qui utilise toujours ses propres certificats (directement inclus dans la bibliothèque libnssckbi.so), indépendamment du contenu de /etc/ssl/certs. C’est à ma connaissance une spécificité de la version GNU/Linux de Firefox, les versions Windows et OS X utilisent il me semble le magasin de certificats du système.

      On peut forcer Firefox à utiliser les certificats de /etc/ssl/certs en remplaçant sa bibliothèque libnssckbi.so par la bibliothèque libp11-kit.so du projet p11-glue.

      ¹ En fait Slackware ré-utilise directement le paquet de Debian, parce que ouais bon, Debian rules! (mais il ne faut pas le dire trop fort :D ).

      • [^] # Re: distrib

        Posté par  . Évalué à 2.

        À noter tout de même que ce paquet n’est absolument pas utilisé par Firefox, qui utilise toujours ses propres certificats (directement inclus dans la bibliothèque libnssckbi.so), indépendamment du contenu de /etc/ssl/certs.

        Tu es sûr ? Il me semble (de mémoire) que quand je rajoute une CA dans /usr/local/share/ca-certificates et que je fais update-ca-certificates firefox/iceweasel reconnaît la nouvelle CA (mais si je rajoute la CA directement dans firefox elle n'est reconnue que par firefox).

        *splash!*

        • [^] # Re: distrib

          Posté par  . Évalué à 3.

          D'autant que sous debian, les certificats du paquet ca-certificates proviennent de… mozilla !

          $ apt show ca-certificates
[...]
Description: certificats CA courants
 Ce paquet inclut les autorités de certifications livrées avec les
 navigateurs Mozilla afin de permettre aux applications basées sur SSL de
 vérifier l'authenticité des connexions SSL.
[...]

$ ls /usr/share/ca-certificates
mozilla

        • [^] # Re: distrib

          Posté par  . Évalué à 3.

          Il me semble (de mémoire) que quand je rajoute une CA dans /usr/local/share/ca-certificates et que je fais update-ca-certificates firefox/iceweasel reconnaît la nouvelle CA

          Ce n’est définitivement pas le cas par défaut chez moi. Ça n’est le cas en pratique que parce que j’ai forcé Firefox à utiliser libp11-kit.so (qui va chercher les certificats dans /etc/ssl/certs) au lieu de sa propre bibliothèque libnssckbi.so (qui contient les certificats directement, ils sont inclus « en dur » à la compilation). Il suffit pour ça de supprimer libnssckbi.so et de la remplacer par un lien symbolique vers libp11-kit.so.

          Après peut-être que certaines distributions font ce remplacement d’office, je ne sais pas.

      • [^] # Re: distrib

        Posté par  . Évalué à 4.

        C’est à ma connaissance une spécificité de la version GNU/Linux de Firefox, les versions Windows et OS X utilisent il me semble le magasin de certificats du système.c

        Je croyais que c'était aussi le cas sous Windows et que c'était même l'origine de ce comportement pour ne pas dépendre des certificats acceptés par Microsoft.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: distrib

          Posté par  . Évalué à 3.

          Je confirme c'est le cas sous Windows, pour Thunderbird également ce qui en fait une plaie sur ce point en entreprise…

          • [^] # Re: distrib

            Posté par  . Évalué à 2.

            Je croyais que c'était aussi le cas sous Windows

            J’étais persuadé que non, mais apparemment je me trompais. Autant pour moi.

            Effectivement il semble que Firefox utilise ses propres certificats quel que soit le système, pas seulement sous GNU/Linux.

            • [^] # Re: distrib

              Posté par  . Évalué à 4.

              Par défaut Firefox et Thunderbird utilisent leurs propres certificats.
              Dans About:config il y a la clé security.enterprise_roots.enabled à mettre à True pour utiliser les certificats de l'OS.

              • [^] # Re: distrib

                Posté par  . Évalué à 2.

                Génial ça !
                Et hop un startup script crado pour l'appliquer à tout le parc :-)
                Merci

    • [^] # Re: distrib

      Posté par  . Évalué à 4.

      Debian maintient un dépôt "update" pour ses versions stables, qui répond à la problématique des paquets qui ont absolument besoin d'être à jour.

      Mais il faut une justification solide pour y entrer:

      This suite will contain updates that satisfy one of the following criteria:

      • The update is urgent and not of a security nature. Security updates will continue to be pushed through the security archive. Examples include packages broken by the flow of time (c.f. spamassassin and the year 2010 problem) and fixes for bugs introduced by point releases.
      • The package in question is a data package and the data must be updated in a timely manner (e.g. tzdata).
      • Fixes to leaf packages that were broken by external changes (e.g. video downloading tools and tor).
      • Packages that need to be current to be useful (e.g. clamav).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.