Journal Paranoïa, certificat SSL et tracasseries.

Posté par octane le 19 décembre 2015 à 23:29. Licence CC By‑SA.

Étiquettes :

déc.

2015

Bonjour Nal,

Depuis quelque jours je constate des bizarreries très étranges lorsque je veux te lire.
Un jour, Chrome me dit que ton certificat SSL est révoqué, un autre jour tout va bien, et aujourd'hui, alors que je vérifier les chaines de parentés des certificats SSL, je tombe là dessus :

C'est fait depuis la même machine, même connexion, même adresse IP, et deux navigateurs différents.

Dans Chrome, la CA, c'est AddTrust External Root. Pourquoi pas, ce certificat à un numéro de série valant 01 (c'est une root CA, rien d'illogique)
Dans Firefox, mis à côté, surprise! La CA root n'est plus AddTrust, mais UTN - Data corp??
qui signe Addtrust External CA root?? (notez le nom subtilement différent), avec un serial qui ne vaut pas 1, et en dessous, tout pareil (même serial, même clés pubs, etc..):
-User Trust RSA Certification Atuthority
-puis Gandi Standard SSL CA 2
-et enfin, toi, mon Nal, *.linuxfr.org

Ceci explique peut-être pourquoi des fois ça passe, des fois ça passe pas.
Donc, toi mon Nal, explique moi? Est-ce que linuxfr s'est fait signer des serveurs? Est-ce que tu as tout plein d'adresses IP avec tout plein des serveurs et des certificats différents (et auquel cas le load balancing expliquerait pourquoi ces certificats changent)? Est-ce que l'esprit de Snowden souffle par ici avec de l'interception SSL à la volée?

Ô toi, lecteur rassure moi, et dit moi dans les commentaires que tu as AddTrust ou UTN - data corp comme top CA lors de ta visite sur linuxfr.org en ajoutant si ça ne t'ennuie pas trop ton navigateur et ton FAI (je suis chez free pour ma part). Ou si tu as vu ça avec d'autres sits SSL (c'est le cas pour moi).

Merci, Nal

# Changement de racine chez Comodo

Posté par gouttegd le 20 décembre 2015 à 00:47. Évalué à 10.
Donc, toi mon Nal, explique moi?

Ce qui se passe apparemment est qu’il y a eu un changement de racine.

Comodo (signataire de Gandi, lui-même signataire de LinuxFR.org) utilisait comme racine le certificat UTN - DATACorp SGC, qui signait un certificat intermédiaire AddTrust External CA Root (lui-même signant un autre certificat intermédiaire de Comodo, USERTrust RSA Certification Authority, qui est le dernier certificat envoyé par le serveur de LinuxFR.org).

Maintenant, la clef du premier certificat intermédiaire AddTrust External CA Root a été ré-utilisée pour (auto)signer une nouvelle racine, AddTrust External Root.

Comme AddTrust External CA Root (ancien certificat intermédiaire) et AddTrust External Root utilisent la même clef, il y a deux chaînes de certification possibles pour LinuxFR.org:
- celle remontant jusqu’à l’ancienne racine:
  - LinuxFR.org (CN=*.linuxfr.org)
  - Gandi (CN=Gandi Standard SSL CA 2)
  - Comodo (intermédiaire 1) (CN=USERTrust RSA Certification Authority)
  - Comodo (intermédiaire 2) (CN=AddTrust External CA Root)
  - Comodo (ancienne racine) (CN=UTN - DATACorp SGC)
- celle remontant jusqu’à la nouvelle:
  - LinuxFR.org (CN=*.linuxfr.org)
  - Gandi (CN=Gandi Standard SSL CA 2)
  - Comodo (intermédiaire 1) (CN=USERTrust RSA Certification Authority)
  - Comodo (nouvelle racine, même clef que intermédiaire 2 ci-dessus) (CN=AddTrust External Root)
Le choix d’une chaîne ou de l’autre dépend des racines présentes dans le magasin du navigateur. Dans ton cas, apparemment Chrome a intégré la nouvelle racine de Comodo et n’a donc plus besoin de remonter jusqu’à l’ancienne racine, contrairement à Firefox.

(Pour info, chez moi, Firefox 38.5 considère déjà le premier certificat intermédiaire de Comodo, USERTrust RSA Certification Authority, comme une racine, donc la chaîne s’arrête à ce certificat.)
- [^] # Re: Changement de racine chez Comodo
  
  Posté par gouttegd le 20 décembre 2015 à 01:09. Évalué à 2.
  
  Chrome me dit que ton certificat SSL est révoqué, un autre jour tout va bien
  
  Ça par contre ce n’est pas normal — et je ne vois pas ce que le changement de racine pourrait avoir à faire avec ça…
  - [^] # Re: Changement de racine chez Comodo
    
    Posté par claudex le 20 décembre 2015 à 10:20. Évalué à 4.
    Il faudrait vérifier que le client est bien à l'heure¹ et télécharger le certificat et vérifier que l'empreinte est bien la même que quand il est retourné comme valide. Tu peux aussi voir ce que raconte openssl:
```
openssl s_client -CApath /etc/ssl -connect linuxfr.org:443
```
    C'est un cas qu'on retrouve de plus en plus avec les smartphone et tablette qui peuvent être complètements décalés suite à une panne de batterie. Même les PC portables n'ont plus tous une pile pour garder l'heure en cas de batterie à plat. ↩
    « 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: Changement de racine chez Comodo
      
      Posté par octane le 21 décembre 2015 à 10:52. Évalué à 7.
      
      Alors, avec Chrome, depuis l'IP chez free:
      http://i.imgur.com/ROlGTwV
      
      Je compte 6 certificats pour arriver au top CA:
      Builtin Object Token: AddTrust External Root
      UTN - DATACorp SGC
      AddTrust External CA Root
      USERTrust RSA Certification Authority
      Gandi Standard SSL CA 2
      *.linuxfr.org
      
      C'est fort étrange.
      
      Je prends un proxy, même navigateur, une IP SFR:
      http://i.imgur.com/Pn0QWLn.png
      
      Et j'ai 4 niveau d'autorités
      Builtin Object Token: AddTrust External Root
      USERTrust RSA Certification Authority
      Gandi Standard SSL CA 2
      *.linuxfr.org
      
      Si je résume:
      -avec mon IP free : certificat révoqué, 6 niveaux de certification
      -avec une IP SFR: certificat OK, 4 niveaux
      
      Mon cher Nal, je vais bouffer les murs si ça continue, et je n'y comprends vraiment toujours rien
      - [^] # Re: Changement de racine chez Comodo
        
        Posté par gouttegd le 21 décembre 2015 à 11:24. Évalué à 4.
        
        Apparemment, le certificat UTN - DATACorp SGC (numéro de série 53:7b:76:56:4f:29:7f:14:dc:69:43:e9:22:ad:2c:79) a bel et bien été révoqué par Comodo le 14 décembre (probablement parce qu’il était signé avec un hash SHA-1, que la plupart des navigateurs ont prévu de ne plus accepter) :
        
        $ wget http://crl.comodo.net/AddTrustExternalCARoot.crl $ openssl crl -noout -text -inform DER -in AddTrustExternalCARoot.crl […] Revoked Certificates: Serial Number: 537B76564F297F14DC6943E922AD2C79 Revocation Date: Dec 14 15:58:30 2015 GMT […]
        
        Du coup, ça expliquerait le code d’erreur NET::ERR_CERT_REVOKED, qui concernerait alors non pas le certificat de linuxfr.org mais un des certificats parents.
        
        Mais ce que je ne comprends toujours pas, c’est pourquoi le chemin de certification passe par ce certificat dans un cas et pas dans l’autre…
        
        Au cas où, tu peux vérifier que la chaîne envoyée par le serveur de linuxfr.org est bien la même avec les deux adresses ?
        
        Même commande que celle suggérée par Xavier Claude ci-dessus, avec en plus l’option -showcerts :
        
        $ openssl s_client -CApath /etc/ssl -showcerts -connect linuxfr.org:443
        
        [^] # Re: Changement de racine chez Comodo
        
        Posté par gouttegd le 21 décembre 2015 à 11:33. Évalué à 2. Dernière modification le 21 décembre 2015 à 11:33.
        
        Tu pourrais aussi exporter au format PEM les certificats de la chaîne incorrecte et les poster quelque part (ici ou sur un pastebin)  ?
      - [^] # Re: Changement de racine chez Comodo
        
        Posté par gouttegd le 22 décembre 2015 à 02:41. Évalué à 10.
        
        Je pense qu’au moins une partie du problème pourrait être lié à ce qui est apparemment un bug connu de Chrome (section ”Issue 2: Out-of-date NSS and cross-signed roots”) :
        
        A bug in NSS caused Chrome on Linux to use cached cross-signed roots even when a shorter and newer chain existed.
        
        Je pense que c’est ce qui explique la chaîne à six niveaux observé avec Chrome.
        
        Le dernier certificat intermédiaire envoyé par LinuxFR.org (CN=USERTrust RSA Certification Authority, serial 13:EA:28:70:5B:F4:EC:ED:0C:36:63:09:80:61:43:36) est signé par la clef AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A.
        
        Il existe (au moins) deux certificats utilisant cette clef :
        
        CN=AddTrust External CA Root, serial 0x1, auto-signé;
        
        CN=AddTrust External CA Root, serial 51:26:0A:93:1C:E2:7F:9C:C3:A5:5F:79:E0:72:AE:82, signé par la clef 53:32:D1:B3:CF:7F:FA:E0:F1:A0:5D:85:4E:92:D2:9E:45:1D:B4:4F.
        
        Cette clef 53:32:D1.etc. est utilisée par (au moins) trois certificats :
        
        CN=UTN - DATACorp SGC, serial 44:BE:0C:8B:50:00:21:B4:11:D3:2A:68:06:A9:AD:69, auto-signé
        
        CN=UTN - DATACorp SGC, serial 46:EA:F0:96:05:4C:C5:E3:FA:65:EA:6E:9F:42:C6:64, signé par la clef AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A (celle des certificats AddTrust External CA Root ci-dessus, vous suivez ?), révoqué le 14 décembre
        
        CN=UTN - DATACorp SGC, serial 53:7B:76:56:4F:29:7F:14:DC:69:43:E9:22:AD:2C:79, lui aussi signé par la clef AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A et lui aussi révoqué le 14 décembre.
        
        On est donc bien dans le cas « racines cross-signées » entre AddTrust External CA Root et UTN - DATACorp SGC.
        
        Dans les versions récentes de NSS, seul le certificat AddTrust External CA Root auto-signé est présent dans le magasin des Builtin Object Tokens (les certificats codés « en dur » dans le navigateur). Cela ne laisse donc qu’une racine possible pour rattacher le dernier certificat intermédiaire envoyé par LinuxFR.org, et il n’y a pas de problème.
        
        Mais si le magasin des certificats cachés (les certificats que le navigateur accumule au gré de la navigation) vient à contenir à la fois la version cross-signée du certificat AddTrust External CA Root et l’une des deux versions cross-signées du certificat UTN - DATACorp SGC, le navigateur peut construire la chaîne de certification suivante :
        
        USERTrust RSA Certification Authority → AddTrust External CA Root (version cross-signée, en cache) → UTN - DATACorp SGC (version cross-signée, en cache) → AddTrust External CA Root (version auto-signée, dans le magasin en dur)
        
        On est donc bien, me semble-t-il, dans le cas du bug évoqué plus haut (ou un bug similaire), où le navigateur construit une chaine de certification à rallonge en utilisant des certificats cachés alors qu’une chaîne plus courte est possible.
        
        Il reste que je ne comprends toujours pas comment/pourquoi la construction de la chaine de certification varierait en fonction du FAI utilisé pour se connecter…
        
        [^] # Re: Changement de racine chez Comodo
        
        Posté par octane le 22 décembre 2015 à 10:40. Évalué à 2.
        
        Ok, un très grand merci pour l'explication, tout commence à devenir plus clair.
        Bon, il faut que je track un peu les connexions, mais l'essentiel est là, et je suis bien sous debian.
        
        Dommage qu'on ne puisse pas mettre +10 sur ton commentaire :)
        
        Il me reste à vider le cache des certificats présents sous mon Chrome.
        
        Je dirais bien merci Nal, mais là, il faut dire merci gouttegd
        
        [^] # Re: Changement de racine chez Comodo
        
        Posté par flan (site web personnel) le 22 décembre 2015 à 12:55. Évalué à 4.
        
        au passage, pourquoi Chrome (comme Firefox) utilise-t-il la libnss au lieu d'utiliser le magasin de certificat du système, alors que toutes les autres applis y arrivent très bien ?
        C'est quand même pénible de :
        
        devoir recompiler la libnss pour supprimer les certificats racine dont on ne veut pas (oui, ils sont en dur dans le code !),
        
        ne pas pouvoir facilement installer des certificats maison au niveau du système (vu qu'ils sont stockés dans le home de l'utilisateur),
        
        devoir modifier des emplacements supplémentaires pour des applis précises alors qu'il y a un système plus ou moins centralisé sur chaque OS pour éviter exactement ce souci.
        
        [^] # Re: Changement de racine chez Comodo
        
        Posté par gouttegd le 22 décembre 2015 à 15:01. Évalué à 3.
        
        il y a un système plus ou moins centralisé sur chaque OS pour éviter exactement ce souci
        
        Je pense que le problème réside dans le « plus ou moins ».
        
        Il y a bien un magasin centralisé, system-wide et disponible pour toutes les applications sur Windows et Mac OS X, et sur ces systèmes Chrome en fait usage.
        
        Mais sur les distributions GNU/Linux, comme tu dis c’est « plus ou moins centralisé ».
        
        Debian a son paquet ca-certificates (qui reprend essentiellement les certificats de NSS d’ailleurs, en en rajoutant éventuellement quelques autres comme celui de CAcert à une époque) et ses certificats dans /etc/ssl/certs, mais d’autres distributions ont leur propre système. Il n’existe pas d’emplacement standardisé qui serait valable sur n’importe quelle distribution.
        
        À noter en revanche le projet p11-kit qui va dans ce sens.
- [^] # Re: Changement de racine chez Comodo
  
  Posté par briaeros007 le 20 décembre 2015 à 10:43. Évalué à 3.
  
  Le choix d’une chaîne ou de l’autre dépend des racines présentes dans le magasin du navigateur.
  
  Euh normalement non.
  Déjà normalement le serveur doit fournir la chaîne de certification, c'est plus propre, surtout si au milieu il y a des AC intermédiaires que le client ne connait pas.
  
  Ensuite, dans chaque certificat, il y a le DN du certificat, en particulier son CN.
  Même avec la même clé, vu que le CN n'est pas le même, ça ne devrait pas passer.
  -> soit le browser à en interne le certif de GANDI, et donc peut vérifier sur ce certif directement , ou constater une différence et envoyer chier (je ne sais pas qui a la priorité. J'ai cherché sur la rfc de ssl pas trouvé : elle indique que la vérification est laissé à l'implémentation :'( )
  
  Enfin c'est comme ça que je vois les choses
  - [^] # Re: Changement de racine chez Comodo
    
    Posté par claudex le 20 décembre 2015 à 11:40. Évalué à 4.
    
    Ce n'est pas le certif gandi qu'il doit avoir en interne, c'est CN=USERTrust RSA Certification Authority et c'est lui qui doit changer le DN de l'issuer (et il est dans Debian par exemple).
    
    « 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: Changement de racine chez Comodo
    
    Posté par gouttegd le 20 décembre 2015 à 12:15. Évalué à 7.
    Déjà normalement le serveur doit fournir la chaîne de certification, c'est plus propre
    
    Pas jusqu’à la racine. Le serveur est supposé fournir une chaîne incluant jusqu’au dernier certificat intermédiaire.
    
    C’est ce que fait le serveur de LinuxFR.org, qui fournit les certificats suivants :
    - *.linuxfr.org (le certificat terminal, celui du serveur proprement dit)
    - Gandi Standard SSL CA 2 (le certificat de Gandi)
    - USERTrust RSA Certification (certificat intermédiaire de Comodo).
    À partir de là, rattacher le dernier certificat de la chaîne fournie par le serveur à une racine présente dans le magasin est de la responsabilité du navigateur, qui va s’acquitter de cette tâche en fonction des racines qu’il a à sa disposition.
    
    Même avec la même clé, vu que le CN n'est pas le même, ça ne devrait pas passer.
    
    En réalité les Subject de l’ancien certificat intermédiaire de Comodo et celui de la nouvelle racine sont identiques (c’est C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root dans les deux cas). Le nom AddTrust External Root (sans le « CA ») qui apparaît dans la liste des certificats de Chrome n’est qu’un nom d’affichage. (J’ai utilisé ce nom-là dans mon post ci-dessus pour pouvoir distinguer entre le certificat intermédiaire et la nouvelle racine.)
    
    soit le browser à en interne le certif de GANDI
    
    À ma connaissance aucun navigateur n’intègre le certificat de Gandi directement.
    - [^] # Re: Changement de racine chez Comodo
      
      Posté par briaeros007 le 20 décembre 2015 à 18:20. Évalué à 3.
      
      ok, merci pour les précisions.
      
      J'avais dit gandi car c'était celui qui semblait avoir le même DN. Mauvaise supposition de ma part :)
- [^] # Re: Changement de racine chez Comodo
  
  Posté par Laurent J (site web personnel, Mastodon) le 20 décembre 2015 à 11:44. Évalué à 4.
  
  Pour info, chez moi, Firefox 38.5 considère déjà le premier certificat intermédiaire de Comodo, USERTrust RSA Certification Authority, comme une racine, donc la chaîne s’arrête à ce certificat.
  
  Pareil chez moi sur la version 43. Il n'affiche pas de "parent" pour USERTrust RSA. Idem sur Chromium 47.

Suivre le flux des commentaires

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