Apple veut réduire la durée de validité des certificats, colère chez les administrateurs

Pour votre bien

Apple veut réduire la durée de validité des certificats, colère chez les administrateurs

Crédits : JJ Ying (Unsplash)

Apple propose de réduire la durée de validité des certificats de sécurité à 45 jours, contre 398 actuellement. Bien que la proposition ait été faite pour augmenter la sécurité générale, elle provoque la colère de très nombreux administrateurs système.

Le 21 octobre 2024 à 09h30

Commentaires (26)

votre avatar
J'ai du mal à voir comment Apple pourrait forcer la réduction de la durée de validité des certificats. La durée d'un certificat est à la discrétion de l'autorité de certification. En fait, le seul moyen possible serait qu'Apple retire de la liste des autorités de certification une autorité qui ne respecterait pas cette durée. Mais il faudrait alors que Google fasse de même avec Chrome.

Sinon, c'est oublié aussi qu'un certificat de sécurité peut avoir plusieurs objectifs. Le plus répandu aujourd'hui, la sécurisation du canal de communication. Mais il existe aussi des extensions, notamment le Extended Validation (EV) qui vise aussi à certifier le titulaire.

Par exemple, pour Next, cela signifierait que l'autorité de certificat à vérifier que le domaine next.ink est bien contrôlé par l'entité qui demande un certificat, mais que cette entité est bien celle qu'elle prétend être (Moji ou Next). Ce type de certificat est souvent plus cher (car nécessite de transmettre des documents).

Si un temps ces certificats "étendus" étaient clairement affichés par les navigateurs, ce n'est plus vraiment le cas aujourd'hui par les navigateurs les plus courants. C'était quand même bien pratique pour des sites sensibles comme celui des impôts de savoir qu'on était bien sur le site des impôts et pas sur un site de phishing.

Et des certificats EV de 45j, ça n'a pas vraiment de sens... surtout que la procédure de vérification peut prendre plusieurs semaines !
votre avatar
Apple, Google et tous les autres: Mozilla avec Firefox, Oracle avec Java... Sur ces 2 derniers, ils embarquent par défaut leur propre liste d'autorités de certification validées, en ignorant celle du système.

Pour le certificats EV, la vérification de l'entité peut décorrélé de l'émission du certificat. (3 ans par exemple pour la validation EV, et 45 jours pour le certificats)
votre avatar
Pour info, Firefox n'ignore plus les certificats systèmes aujourd'hui.
Pour le certificats EV, la vérification de l'entité peut décorrélé de l'émission du certificat. (3 ans par exemple pour la validation EV, et 45 jours pour le certificats)
Certes. Mais cela signifie aussi plus de manipulation du certificat, donc plus de risque qu'il fuite. Je ne suis pas certains que cela soit souhaitable. Il faudrait avoir un retour sur la balance bénéfice/risque.
votre avatar
Pour info, Firefox n'ignore plus les certificats systèmes aujourd'hui.

Bien vu, merci ! J'étais resté avec mes vieux acquis.. :)

C'est même un peu plus subtile que ca :
https://mzl.la/3vVLmzx


Certes. Mais cela signifie aussi plus de manipulation du certificat, donc plus de risque qu'il fuite. Je ne suis pas certains que cela soit souhaitable. Il faudrait avoir un retour sur la balance bénéfice/risque.

Le certificat est une info publique, la clé privée ne sort jamais du système qui est à l'origine de la demande. :)
Mais oui, 45 jours parais court malgré tout.
votre avatar
Le certificat est une info publique, la clé privée ne sort jamais du système qui est à l'origine de la demande. :)
Pardon de mon imprécision : quand je parlais certificat, je voulais bien sûr dire certificat + clé privé ;) Les deux sont nécessaires au niveau du serveur applicatif (Apache, Nginx, etc.)
votre avatar
Mais Apple la déjà fait.
Depuis quelque années il ne valide plus les certificats passé leur premier années.
Donc si tu gère un site ba tu prend plus que des certificat valide 1 an, sinon ton site ne fonctionnera plus correctement sur les produit Apple.

Voila comment il force.
votre avatar
Alors, j'ai creusé, et effectivement, c'est bien le cas pour les autorités de certifications "publiques". On retrouve le même comportement pour Chrome et Safari.

Par contre, pour les autorités de certification internes, ce délai d'un an n'existe pas. Il y en a un autre qui est de 825 jours.

Et ce délai ne s'applique que pour les certificats "finaux", c'est-à-dire présentés par les sites pour la sécurisation. Les certificats intermédiaire ne semblent pas impactés.

Donc merci pour l'info, car j'étais passé complètement à côté.
votre avatar
J'ai du mal à voir comment Apple pourrait forcer
Si ils arrivent à faire adopter leur proposition par le "CA/Browser Forum", alors tous les émetteurs de certificats seront obligé de s'y contraindre, sous peine d'être éjectés des listes d'autorités de certification validées des différents systèmes (navigateurs, OS).
votre avatar
La cata pour les projets type Arduino!
Pour rappel la compression Brotli n'est possible qu'en https. Largement compensée par le chiffrement minimal ECC.
votre avatar
C'est complètement ignorer la réalité des usages. J'ai vu passer des projets de plateformes de services où la quantité de certificats manipulés dépassait allègrement la centaine malgré l'usage de SAN pour rationaliser le plus possible. Le tout sur des infrastructures différentes dont certaines gérant très mal l'automatisation. Et on est déjà sur des expirations d'un an que ce soit pour les publics ou privés.

Sans oublier les certificats machines, les protocoles à double certification (un pour la couche communication, un pour l'authent mutuelle entre les partenaires et le chiffrement de la donnée) type AS2 très utilisé dans le retail pour l'EDI, etc.

Déjà qu'on se bat pour que les produits désactivent l'option "ne pas vérifier les certificats" à cause des expirés pas renouvelés, de l'auto signé installé par Jean Michel il y a 8 ans mais que personne sait à quoi ça sert touche-surtout-pas-ça-marche, ou de ceux délivrés par une autorité interne mais qu'on est toujours infoutus d'avoir la CA déployée (ou ignorée parce que fucking key store Java et j'en passe).

Bref, à part vouloir donner du taff à des admins système et faire recruter dans le domaine, je vois pas la finalité. Le renouvellement de certifs en entreprise n'est pas aussi simple qu'un let's encrypt sur un nginx en auto.
votre avatar
Perso, j'utilise un certificat Let’s Encrypt et je ne peux pas automatiser son renouvèlement (à cause du HSTS) et c'est très casse-pieds.

Donc, je comprends tout à fait ceux qui doivent en gérer pleins…
votre avatar
En quoi HSTS te gêne pour l'automatisation ? Pour le challenge "well-know" en http ?
Tu ne peux pas utiliser le challenge DNS ?
votre avatar
Ou le challenge TLS-ALPN-01 qui est similaire à http, sans nécessiter d'ouvrir le port 80
votre avatar
Ouais, mais en même temps :
It’s not supported by Apache, Nginx, or Certbot, and probably won’t be soon. Like HTTP-01, if you have multiple servers they need to all answer with the same content. This method cannot be used to validate wildcard domains.
C'est pas vraiment fait pour de l'automatisation "simple".
votre avatar
Oui.
Je regarderais, mais je ne crois pas que le gestionnaire de certificat du DSM synology me laisse le choix sur la méthode…
votre avatar
De mon expérience avec l'outil certificats de DSM, t'as pas trop le choix de la procédure. Tu choisis Let's encrypt, tu mets le domaine + le mail et basta. C'est pour ça que j'ai arrêté cette partie et préféré remettre un frontal Nginx (avec WAF, au passage).

Les outils intégrés du syno sont trop limités, je trouve ça dommage.
votre avatar
Tu peux automatiser le challenge DNS ?

Edit: Je viens de voir sur la doc, effectivement pas mal.
votre avatar
Tu peux automatiser le challenge DNS ?
Cela va dépendre du registrar. Si tu as une API dispo oui.
votre avatar
Le problème de fond, c'est comment éviter qu'un certificat compromis soit utilisé trop longtemps, une fois la compromission constatée.

Je connais 3 stratégies:
- réduction de la durée de validité du certificat
- listes de révocations: Certificate Revocation Lists (CRLs)
- Online Certificate Status Protocol (OCSP)

L'avantage de la réduction de la durée de validité du certificat, c'est qu'elle ne nécessite pas de mise à jour chez les clients. Seul le serveur doit renouveler plus souvent son certificat.

Les deux autres stratégies (OCSP & CRL) nécessitent des ajustements côté client (et serveur), gros soucis pour tous les IOTs et vieux appareils EOL.

J'avais eu quelques échanges à ce sujet à propos de https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/ sur lobste.rs: https://lobste.rs/s/k4uuth/intent_end_ocsp_service#c_cv0s36
votre avatar
Ça n'est pas vraiment un ajustement, dans la mesure où ces mécanismes de révocation existent depuis très longtemps, et que la révocation doit toujours être implémentée pour que le système soit sécurisé.

Réduire la durée de validité n'est pas une manière correcte pour se protéger contre des clés compromises.
C'est plutôt une protection additionnelle si l'attaquant réussi à déjouer les mécanismes de révocation ou à ne pas se faire repérer.
votre avatar
Je serais curieux de voir la démarche qui a mené au chiffre 45. Pourquoi pas 15 ou 60, mais 45.
C'est du à l'âge moyen des certificats compromis ? A la taille maximale de l'historique pour que les listes de révocation soient fera les, ou tout simplement le jet d'1D100 ?
votre avatar
Encourager à renouveler tous les mois, peut-être.
Pour Let’s Encrypt, il me semble que certaines des implémentations renouvellent tous les 60 jours au lieu de 90.
Ça laisse le temps de se retourner si l’automatisation foire (d’abord on attend quelques jours pour que ça réessaie tout seul puis on se penche sur le problème sans être dans l’urgence absolue).

Bien sûr, il faut vérifier les logs pour détecter les échecs mais c’est une des idées qui pourrait expliquer le choix.
votre avatar
Je reviens sur la question, ou je la reformule : quelle analyse a dit que tous les mois était le meilleur compromis (et sur quel critères ?)
votre avatar
Jet 1D20 mais sur le nombre de mois (on n’a juste pas eu de bol). :fume:
votre avatar
Il faudrait déjà que google vérifie la révocation des certificats avant de vouloir réduire sa durée de vie.

Firefox le fait très bien.

Quand la sécurité devient absurde et génère une charge de travail supérieur sur les admins systèmes
votre avatar
C'est plus la méthode qui ne passe pas par un consortium que je trouve pas terrible. Si tout le monde accepte de s'aligner, ben cela veut dire que Apple prend ses décisions de façon unilatérale. La réplique serait de dire "tant pi", ce n'est que 10 à 20% de part de marché :/ Bon a priori, ça ne se passera pas comme ça, mais si c'est pour se prendre la tête comme ça, à un moment, je ne serais pas étonné que certains fassent ce choix.

Apple veut réduire la durée de validité des certificats, colère chez les administrateurs

  • Apple veut réduire la validité à 45 jours

  • L’importance des certificats

  • Sur Reddit, les cris des administrateurs

  • Sans automatisation, point de salut ?

Fermer