Pourquoi ne faisons-nous pas confiance à un certificat SSL qui a expiré récemment?
Chaque certificat SSL a une date d'expiration. Supposons maintenant que le certificat d'un site a expiré il y a une heure ou un jour. Par défaut, tous les logiciels refusent simplement de se connecter au site ou émettent des avertissements de sécurité.
Cela ce qui est arrivé récemment à Windows Azure Storage et puisque la plupart des logiciels des services dépendants ont refusé de se connecter à de nombreux services, ils ont subi une dégradation majeure.
Maintenant, quelle est la logique ici? Il y a un jour, le certificat était valide et tout le monde était content de l'utiliser. Maintenant, un jour plus tard, il est officiellement expiré et personne ne l'aime plus.
J'ai lu cette réponse et je ne le trouve pas convaincant pour ce cas Edge spécifique. À chaque modèle de sécurité, il existe un modèle de menace.
Quel est le modèle de menace ici? Que pourrait-il se passer entre aujourd'hui et il y a un jour qu'un certificat est traité comme étant inutilisable à tel point que nous refusons même de nous connecter au site?
Lorsqu'un certificat arrive à expiration, son statut de révocation n'est plus publié. Autrement dit, le certificat a peut-être été révoqué depuis longtemps, mais il ne sera plus inclus dans la liste de révocation de certificats. La date d'expiration du certificat est la date limite pour l'inclusion de la liste de révocation de certificats. C'est la raison officielle pour laquelle les certificats expirent: pour limiter la taille des CRL.
(La raison officieuse est de faire payer une redevance annuelle aux propriétaires de certificats.)
Vous ne pouvez donc pas faire confiance à un certificat expiré car vous ne pouvez pas vérifier son état de révocation. Il a peut-être été révoqué il y a des mois et vous ne le sauriez pas.
Une bonne question. La réponse la plus simple est que le fait d'avoir une date d'expiration garantit que vous avez un "audit" de temps en temps. S'il n'y avait pas de date d'expiration et que quelqu'un arrêtait d'utiliser un certificat (et de protéger la clé privée), personne ne le saurait. Cependant, en ayant une date d'expiration, vous vous assurez que l'utilisateur retourne à l'entreprise qui lui a vendu le certificat SSL et lui verse beaucoup plus d'argent, je veux dire, a un audit et est revalidé en tant que personne ou service auquel il prétend être (j'essaierai de laisser les diatribes sur le modèle de sécurité Internet actuel hors de cette question).
Le problème devient alors: Si vous allez avoir une période de grâce dans laquelle vous ignorez les certificats expirés, combien de temps dure-t-il? Un jour? Une semaine? Un mois? À un moment donné, vous devez simplement cesser de faire confiance au certificat; si vous faites valoir ce point un jour après l'expiration, vous pouvez toujours vous demander: "Qu'est-ce qui aurait pu se passer entre aujourd'hui et hier?" Et vous tombez dans une boucle.
Essentiellement, vous avez raison: les gens n'arrêtent pas comme par magie de protéger leurs clés privées dès que la date d'expiration arrive (ou ils ont peut-être cessé de les protéger il y a longtemps et personne ne le sait car ils ne les ont pas révoqués et ils n'ont pas pas encore expiré). La date d'expiration ne dit rien sur la sécurité du certificat, mais si vous n'avez pas de coupure, vous jamais sachez qu'un certificat peut être oublié alors qu'avec un vous en savez au moins beaucoup .
S'il y avait une période de grâce universelle de cinq jours, personne ne remarquerait l'expiration des certificats jusqu'à cinq jours plus tard, vous laissant avec un effet net identique à refuser immédiatement un certificat expiré. C'est le fait que les connexions SSL cessent de fonctionner qui crée la pression.
Je soupçonne qu'il serait plus productif pour les applications client SSL d'avertir fortement d'une expiration imminente du certificat, afin que les utilisateurs de ces applications puissent faire pression à l'avance sur leurs fournisseurs de services.
Je suis d'accord que le système actuel n'est pas optimal.
Un meilleur système de certificats pourrait avoir une période d'état "jaune" pour les certificats qui sont sur le point d'expirer ("vert" étant un certificat valide et "rouge" étant un certificat expiré), expirant dans un délai d'un mois. Chaque certificat de N ans expirerait après N années + 1 mois, bien qu'ils soient idéalement mis à jour au cours de la période de N ans. Cependant, au cours du dernier mois, chaque application qui utilise un certificat doit présenter une légère indication d'avertissement à l'utilisateur. Pour la navigation sur le Web, vous pouvez faire quelque chose comme colorer l'URL jaune au lieu de vert - avec un message de survol/clic à l'effet:
Le certificat de ce site Web expirera le 25 mars 2013 et devrait être mis à jour par le propriétaire du domaine avant son expiration. Le certificat est toujours parfaitement valide et devrait être entièrement fiable à cette date, mais les applications qui s'appuient sur ce certificat cesseront de fonctionner le 25 mars 2013 si le certificat n'est pas mis à jour d'ici là.
Serait-ce parfait? Probablement pas, car certaines applications peuvent ne pas transmettre ces messages à l'utilisateur et la date d'expiration sera toujours atteinte. En outre, il doit y avoir un accord codifié dans une norme pour combien de temps avant l'expiration des certificats qu'ils doivent être mis à jour (un jour? Une semaine? Deux semaines? Un mois?). Mais cela semble définitivement être une amélioration.
(Certes, je suis d'accord que Microsoft a vraiment laissé tomber la balle quand il a laissé son certificat Azure expirer - c'est un signe d'incompétence pour une plate-forme essayant de prendre en charge les applications d'entreprise).
La réponse est aussi simple que l'entreprise: "La facture n'est pas payée"
L'autorité de certification affirme pendant une période de temps distincte que ce certificat est valide. Mais cela ne dit pas grand-chose sur la fiabilité de l'autorité de certification et les processus du propriétaire du certificat.
Cela a à voir avec la perception et les bonnes pratiques de sécurité.
Lorsque vous créez un certificat avec, par exemple, une expiration d'un an, vous dites essentiellement "Nous ne pouvons pas garantir l'intégrité du certificat pendant plus d'un an, nous allons donc déployer un nouveau certificat avant cette date =. "
Ainsi, un site avec un certificat expiré est un signe que les administrateurs ne l'ont pas tiennent leur promesse de renouvellement dans le délai qu'ils se sont fixé, ce qui suggère de mauvaises pratiques de sécurité.
C'est la même raison pour laquelle vous attrapez l'enfer pour avoir raté une inspection de voiture même si votre voiture semble bien fonctionner, ou pourquoi les produits ont une date de péremption.
Durée de conservation peut être une chose intéressante pour certains produits: le fabricant déclare qu'il garantit que le produit sera valide pendant un certain temps, mais il ne peut garantir que les propriétés d'origine seront présentes si vous consommez le produit après cette période.
Un certificat a la même chose: il a une période où l'émetteur déclare qu'il est valide. Pendant ce temps, le certificat doit être correct. Et si ce n'est pas le cas, il y aura un rappel à ce sujet: une liste de révocation par l'émetteur dira au monde entier "ne faites plus confiance à ce certificat, car il pourrait être compromis d'une manière ou d'une autre".
Après la date d'expiration, l'émetteur ne suivra plus ce certificat: il a dépassé la date à laquelle il était bon, donc toute personne qui lui fait toujours confiance ne devrait le faire que sur sa foi, et non sur l'émetteur (ou quelqu'un d'autre).
Après la date d'expiration, le certificat n'est pas mauvais, cassé, malodorant ... il n'est tout simplement plus garanti d'avoir été révoqué. Et pourquoi ne faisons-nous pas confiance à un certificat SSL qui a expiré récemment parce que nous voulons la sécurité, et nous utilisons des certificats pour garantir quelque chose. Si nous ne pouvons pas être sûrs si elle a été (ou serait) révoquée , vous ne pouvez pas être sûr qu'elle a été compromise, et vous ne le faites pas avoir une sécurité en l'utilisant ...
La définition de la date d'expiration des certificats se fait pour la même raison que vous devez changer votre mot de passe de temps en temps et avoir une politique pour que les utilisateurs le changent de temps en temps. Pas toujours nécessaire mais peut parfois être utile.
Par exemple, votre ancien employé ayant votre emploi (interne) CA pourrait signer son site Web de phishing et vous ne verriez aucune différence entre son site et votre site bancaire (y compris votre navigateur disant que la connexion est sécurisée). Avoir une date d'expiration au moins sur l'autorité de certification interne vous permet de la modifier de temps à autre et d'éviter cela.
Vous pouvez toujours dire "Je m'en fiche" et définir la date du certificat, par exemple. 2300 (si vous êtes le propriétaire de CA). Bien entendu, les autorités commerciales peuvent vouloir vous faire régler la date d'expiration de votre licence ;-).
Outre les éléments déjà mentionnés (il est recommandé de changer régulièrement ces clés, les autorités de certification veulent être payées, réexaminer l'identité, etc.), il existe également une raison technique. Les navigateurs vous informent qu'ils ne peuvent pas vérifier la validité du certificat.
Les certificats peuvent être révoqués, c'est-à-dire marqués comme non valides, au cas où leurs clés seraient compromises, l'AC notifierait qu'elles ont été mal émises, etc. Ces informations de révocation sont garanties d'être fournies pendant la période de validité, mais pas après. Cela permet de conserver des tailles CRL (liste de révocation de certificats) petites. Bien que les CRL soient rarement utilisées aujourd'hui dans le SSL basé sur un navigateur, cela pourrait également affecter d'autres moyens de vérifier la validité.
Pour cette raison, l'application de la date de validité est logique sur le plan technique et ne se fait pas uniquement parce que "les certificats doivent être renouvelés pour garantir les ré-audits" et "les AC veulent être payés".
Cela dépend de ce que vous sécurisez. C'est relativement sûr. Cela revient à un zéro-jour, l'homme au milieu de l'attaque. Un attaquant devrait savoir que le certificat a expiré, savoir que vous utilisez ce certificat et s’insérer entre vous et le serveur en l'espace de quelques jours. Si vous gardez des secrets nucléaires, il est trop risqué de faire confiance. Si vous envoyez votre numéro de carte de crédit, ce serait ok pour quelques jours ou semaines (pas que vous soyez responsable de toute façon). Si vous bloguez sur des dictateurs en Iran, alors que vous êtes en Iran, vous risquez votre vie, et cela ne vaut peut-être pas le risque.