Les navigateurs Web mettent-ils en cache les certificats SSL?


26

Des navigateurs Web mettent-ils en cache les certificats de serveur SSL? Par exemple, si je modifie le certificat SSL sur un serveur Web, tous les navigateurs Web récupéreront-ils le nouveau certificat lorsqu'ils se connecteront via SSL, ou est-il possible qu'ils aient un certificat périmé?

Je pense au scénario où un certificat SSL expire et est remplacé par un nouveau sur le serveur Web.


Je suppose que le navigateur vérifie la date sur le certificat pour voir s'il doit en obtenir un plus récent, comme il le fait pour tout le reste, mais je ne suis pas sûr.
soandos

Jetez un œil ici imperialviolet.org/2011/05/04/pinning.html à propos du "certificat pinning" et de l'initiative HSTS qui est lié à l'ancien dev.chromium.org/sts
Shadok

1
À partir de 2019, mon Chrome 75 met en cache les certificats SSL
Fabian Thommen

Réponses:


10

Eh bien, la réponse de RedGrittyBrick est correcte, mais ne répond pas vraiment à la question. La question était de savoir si les navigateurs le faisaient et non s'ils devaient ou devaient le faire.

D'après ce que j'ai entendu, MSIE et Chrome font tous les deux des certificats de cache, et ne les remplacent pas lorsqu'ils obtiennent une nouvelle version tant que l'ancienne est valide. Je ne comprends pas pourquoi ils font cela, car cela diminue la sécurité.


La réponse actuellement acceptée est assez claire. Cela indique spécifiquement que non , les navigateurs ne mettent pas en cache les certificats. Comme vous le signalez, le paysage a changé, les raisons pour lesquelles Chrome est bien documenté seraient bien pour vous de créer un lien vers ces raisons. Étant donné que le certificat est toujours valide, il ne "diminue" pas la sécurité qui n'aurait aucun sens.
Ramhound

3
Il la réduit, car vous ne pouvez pas remplacer une ancienne clé SHA-1 par une nouvelle, car l'ancienne est toujours valide et Chrome ignore la nouvelle, si j'ai bien compris. Il n'y a donc aucun moyen de forcer un passage à une norme de sécurité plus élevée - il "baisse" donc dans un sens relatif en ne permettant pas de le pousser plus haut. Tout comme l'inflation ne fait pas baisser la valeur désignée de votre argent, mais sa valeur marchande réelle.
tuexss

5
+1 Après le fiasco de la chaîne SHSS SHA1 / SHA2 mixte StartSSL , il est clair que Chrome sur Windows met en effet en cache les certificats intermédiaires, peut-être indéfiniment. Chrome ignorera tout nouveau certificat intermédiaire envoyé par le serveur. Il n'est pas clair cependant si la mise en cache est basée sur l'identité du certificat de serveur ou l'identité du certificat intermédiaire et ce qui constitue exactement cette identité.
Robert Važan

3
a frappé le problème aujourd'hui, chrome et firefox affichent différents certificats en fenêtre normale (ancien certificat) et en mode navigation privée (correct). Les utilitaires de ligne de commande comme curl ou openssl rapportent bien sûr un certificat correct. Corrigé en effaçant le cache du navigateur (ctrl + shift + del) - "cookies et autres données de site" pour Chrome et "données de site Web hors ligne" pour Firefox.
anilech

1
Au moins la version actuelle de Firefox (66.0) sur OSX semble conserver son cache assez fortement. Hier, j'ai mis à jour un certificat TLS pour mon site Web et CLI opensslet Chromium me montrent le nouveau certificat. Firefox me montre l'ancien malgré le rechargement avec le cache désactivé, effaçant toutes les données du cache et hors ligne et un redémarrage du navigateur.
Tad Lispy

20

Voir la présentation IBM SSL

  1. Le client SSL envoie un message "bonjour au client" qui répertorie les informations cryptographiques telles que la version SSL et, dans l'ordre de préférence du client, les CipherSuites prises en charge par le client. Le message contient également une chaîne d'octets aléatoires qui est utilisée dans les calculs ultérieurs. Le protocole SSL permet au client bonjour d'inclure les méthodes de compression de données prises en charge par le client, mais les implémentations SSL actuelles n'incluent généralement pas cette disposition.

  2. Le serveur SSL répond avec un message "bonjour au serveur" qui contient le CipherSuite choisi par le serveur dans la liste fournie par le client SSL, l'ID de session et une autre chaîne d'octets aléatoires. Le serveur SSL envoie également son certificat numérique . Si le serveur requiert un certificat numérique pour l'authentification client, le serveur envoie une "demande de certificat client" qui inclut une liste des types de certificats pris en charge et les noms distinctifs des autorités de certification (CA) acceptables.

  3. Le client SSL vérifie la signature numérique sur le certificat numérique du serveur SSL et vérifie que la CipherSuite choisie par le serveur est acceptable.

Le résumé de Microsoft est similaire. La prise de contact TLS est également similaire à cet égard.

À l'étape 2, il ne semble pas que le client puisse dire "ne vous embêtez pas à envoyer un certificat de serveur, je vais utiliser mon cache".

Notez qu'il existe plusieurs types de certificats, client, serveur et autorité de certification. Certains d'entre eux sont mis en cache.


Question originale modifiée pour préciser qu'il s'agit d'un certificat de serveur.
Lorin Hochstein

Ce n'est pas vrai et supposer qu'il n'y a pas de cache en raison d'une vue d'ensemble du fonctionnement de SSL exclut la mise en cache est une assez mauvaise justification. youtube.com/watch?v=wMFPe-DwULM
Evan Carroll

Le seul cache qui pourrait être utilisé est pour les vérifications de validité, bien qu'il s'agisse d'un compromis de sécurité.
Daniel B

0

Je ne sais pas si mon entrée aidera de quelque façon que ce soit, mais voici ce que je viens de vivre: j'ai un site Web en azur avec un domaine personnalisé. J'ai essayé d'y accéder avec https dans chromes avant de configurer la liaison SSL pour mon nom de domaine. Chrome me disait que le site n'est pas sécurisé, ce qui est parfaitement logique (ERR_CERT_COMMON_NAME_INVALID) Mais après avoir téléchargé mon certificat et configuré la liaison SSL en azur, j'obtenais toujours la même erreur. À ce stade, lors de l'ouverture d'une nouvelle fenêtre de navigateur privé (ou en utilisant un autre navigateur), https fonctionnait bien.

Mais je n'ai jamais pu le faire fonctionner dans ma session Chrome ouverte. J'ai essayé un état SSL clair, même résultat. Cela a fonctionné après avoir redémarré complètement Chrome.

J'ai probablement été trompé par quelque chose, mais il semblait presque que le certificat était mis en cache ...


Cette erreur impliquerait que vous avez accédé au site avec un URI différent de celui qui était dans le CN. Avez-vous réellement modifié l'URI pour accéder au site dans Chrome après avoir configuré la liaison?
Seth

non, la seule chose que j'ai changé à l'époque était la reliure. Lorsque j'ai interrogé https pour la première fois, il a été servi à l'aide du certificat ssl azure par défaut, mais il me servait toujours celui-ci après avoir modifié la liaison avec le certificat correct dans Azure.
Etienne

Comme vous l'avez dit, vous avez configuré la liaison SSL de votre domaine, cela signifie-t-il que vous avez accédé au serveur en utilisant votre domaine dès le départ ou non? L'erreur indiquerait qu'il y avait une différence entre l'URL que vous avez utilisée et l'URL à laquelle le certificat était destiné. C'est ce que je voulais dire. De plus, la configuration réelle de votre serveur peut être très importante si vous pensez à HSTS et autres.
Seth

1
Étape 1: site Web publié à azurer. À ce stade, il possède à la fois une URL azur par défaut et un certificat par défaut. Étape 2: configurer un domaine personnalisé pour l'application Web, maintenant mysite.com pointe correctement vers le site. Le certificat SSL pour mysite.com n'est pas configuré à ce stade. Étape 3: À ce stade, lorsque j'essaie de https le site, je reçois une erreur de sécurité disant que le certificat ne correspond pas (et c'est parfaitement logique) Étape 4: J'installe le certificat SSL pour Mysite.com en azur et STILL l'avertissement de sécurité s'affiche depuis Chrome. Cela ne se produit PAS dans un autre navigateur ou si j'ouvre une navigation privée.
Etienne

1
Étape 5: Je redémarre Chrome et maintenant (et seulement maintenant) mon site Web est-il servi en utilisant le bon certificat SSL. D'où ma conclusion est qu'il y avait en effet un problème de mise en cache du certificat
Etienne

-1

Il est prévu que certains développeurs de navigateurs mettent en œuvre un tel système de chachages pour détecter des attaques comme l' attaque de Diginotar en 2011.

Mais pour le moment AFAIK, aucun système de ce type n'est actif dans les navigateurs actuels. Par conséquent, vous n'avez pas à penser à cette situation lors de la mise à jour de votre certificat de serveur.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.