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.
Les certificats sont un maillon essentiel de la chaine de sécurité. Ils servent à prouver, en théorie, que l’on est bien qui l’on prétend être. Ils sont là pour assurer l’identification d’une entité et sont à la base de la chaine de confiance sur Internet, encore aujourd’hui. Mais leurs problèmes sont multiples. Notamment, si un acteur malveillant arrive à s’emparer d’un certificat, il peut exploiter des failles potentielles pendant une durée prolongée.
Apple veut réduire la validité à 45 jours
C’est à cette durée que veut s’attaquer Apple. Notons d’emblée que ce n’est pas la première entreprise à proposer une telle réduction. Avant 2011, la validité d'un certificat pouvait ainsi porter sur un maximum de 8 ans. Au cours de la décennie suivante, la durée a été progressivement rabotée pour atteindre le maximal de 398 jours que l’on connait aujourd’hui. Cependant, Google avait déjà suggéré de la faire descendre à 90 jours.
Il reste 81% de l'article à découvrir. Abonnez-vous pour ne rien manquer.
Déjà abonné ? Se connecter
Commentaires (23)
#1
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 !
#1.1
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)
#1.2
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.
#1.3
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.
#1.4
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.)
#1.5
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.
#1.7
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é.
#1.6
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).
#2
Pour rappel la compression Brotli n'est possible qu'en https. Largement compensée par le chiffrement minimal ECC.
#3
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.
#4
Donc, je comprends tout à fait ceux qui doivent en gérer pleins…
Historique des modifications :
Posté le 21/10/2024 à 11h19
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…
#4.1
Tu ne peux pas utiliser le challenge DNS ?
#4.2
#4.6
C'est pas vraiment fait pour de l'automatisation "simple".
#4.3
Je regarderais, mais je ne crois pas que le gestionnaire de certificat du DSM synology me laisse le choix sur la méthode…
#4.4
Les outils intégrés du syno sont trop limités, je trouve ça dommage.
#4.5
Edit: Je viens de voir sur la doc, effectivement pas mal.
Historique des modifications :
Posté le 21/10/2024 à 13h38
Tu peux automatiser le challenge DNS ?
Edit: Je viens de voir sur la doc, effectivement pas mal.
#4.7
Cela va dépendre du registrar. Si tu as une API dispo oui.
#5
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
Historique des modifications :
Posté le 21/10/2024 à 11h53
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 sont 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
#5.1
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.
#6
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 ?
#6.1
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.
#7
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