Google Chrome et Microsoft Edge ne vérifient pas l'état de révocation des certificats

Auteur Uwe GradeneggerPublié le Catégories Utilisation du certificatÉtiquettes , , , ,

De plus en plus d'entreprises utilisent comme navigateur par défaut sur la plateforme Windows le navigateur Google Chrome ou le nouveau Microsoft Edge basé sur Chromium (nom de code Anaheim).

Lors de la distribution de l'un de ces deux navigateurs, il convient de tenir compte du fait qu'ils se comportent en partie différemment des autres navigateurs en ce qui concerne les certificats.

Outre le fait que Chromium, contrairement à Internet Explorer et au précédent Edge (nom de code Spartan) qui impose le RFC 2818, il se comporte aussi en Vérification des informations de blocage différent.

Il est parfois nécessaire qu'un certificat délivré par une autorité de certification soit retiré avant sa date d'expiration. Pour ce faire, une autorité de certification tient à jour une liste de révocation. Il s'agit d'un fichier signé avec une date d'expiration relativement courte, qui est utilisé en combinaison avec le certificat pour vérifier sa validité.

Soft-fail pour la vérification des listes de blocage sur Internet n'offre guère de sécurité - alors Chrome le désactive complètement

Comme la disponibilité des informations de blocage sur Internet n'est souvent pas satisfaisante (selon les Données télémétriques de Mozilla ), les fabricants de navigateurs ont depuis longtemps commencé à mettre en œuvre un Soft-fail.

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Soft-fail signifie qu'une validation de la liste de révocation n'a lieu que si l'information de révocation est effectivement disponible. Si l'information de révocation n'est pas disponible, par exemple parce que l'adresse enregistrée dans le point de distribution CRL du certificat n'est plus correcte, on suppose tacitement - malgré l'impossibilité de déterminer le statut de révocation - que le certificat est encore valable et on l'accepte en conséquence.

Une curiosité à cet égard est que la CryptoAPI (CAPI) utilisée par les navigateurs sous Windows pour vérifier l'état de blocage renvoie le même code d'erreur („The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)“) dans le cas d'une liste de blocage expirée que dans le cas où elle n'est pas accessible - ce qui a pour conséquence que les listes de blocage expirées sont également acceptées tacitement par Internet Explorer et le précédent Edge.

Cette décision était motivée par le fait que les utilisateurs ne devaient pas être conditionnés à cliquer sur des messages d'erreur - et que de tels messages en cas de hard-fail (c'est-à-dire un refus d'acceptation du certificat en cas d'indisponibilité de l'information de blocage) - se produiraient certainement très souvent pour les sites sur Internet.

Google est maintenant d'avis, à juste titre, que l'implémentation d'un soft -fail réduit la sécurité à un point tel que l'ensemble du contrôle de verrouillage est en fait inutile, La Commission européenne a décidé d'interdire l'utilisation des cookies dans le navigateur Chrome à partir de la version 19 :

Compte tenu du fait que les contrôles de révocation en ligne ne présentent aucun avantage efficace en termes de sécurité, ils sont désactivés par défaut dans Google Chrome version 19 et ultérieure. En définissant cette politique comme vraie, le comportement précédent est rétabli et les contrôles OCSP/CRL en ligne seront effectués.
Si la politique n'est pas définie, ou si elle est définie comme fausse, Google Chrome n'effectuera pas de contrôles de révocation en ligne dans Google Chrome 19 et les versions ultérieures.

https://www.chromium.org/administrators/policy-list-3#EnableOnlineRevocationChecks

Pour les sites Internet, cela peut être un choix judicieux, d'autant plus qu'avec Chromes CRLSets ni d'une option d'urgence pour les incidents de sécurité majeurs, et que la validité des certificats SSL sur Internet est en général continuellement réduite (et même à 90 jours seulement dans le cas de Let's Encrypt).

Toutefois, étant donné que dans le cas d'une infrastructure interne à clé publique, on devrait généralement pouvoir partir du principe que les informations de blocage sont à jour et peuvent être consultées, il est dans ce cas le plus souvent tout à fait souhaitable que celles-ci soient également évaluées par les participants.

Heureusement, il est possible de réactiver le contrôle des listes de blocage. Les possibilités suivantes s'offrent à vous :

  • Désactivation générale du contrôle des listes de blocage (comportement par défaut).
  • Activation générale du contrôle de la liste de blocage avec Soft-fail en cas d'erreur.
  • Activation sélective de la vérification de la liste de révocation pour les certificats émis par les autorités de certification internes avec hard-fail en cas d'erreur.

Vérification du comportement décrit

Nous vérifions tout d'abord que les applications se comportent bien comme décrit. Pour comparer, nous appelons une page interne avec un certificat révoqué (pour la procédure, voir l'article „Révocation d'un certificat délivré„).

Veuillez noter que les informations de verrouillage sont stockées temporairement sur les systèmes Windows et ne sont pas actualisées en direct. Par conséquent, si une liste de révocation ou une réponse OCSP a été obtenue pour l'autorité de certification concernée avant la révocation du certificat et qu'elle est toujours valable, il n'est pas garanti qu'une information de révocation nouvellement publiée soit récupérée avant son expiration. Si l'on souhaite forcer le téléchargement d'une information de blocage actualisée, il faut pour cela effacer le cache d'adresses local (URL Cache). Pour la procédure, voir l'article „Consulter et supprimer le cache d'adresses des listes de blocage (CRL URL Cache)„ .

Internet Explorer identifiera correctement le certificat comme révoqué (code d'erreur ERROR_INTERNET_SEC_CERT_REVOKED) et refusera la connexion.

En revanche, Google Chrome et le nouveau Edge ne vérifient pas l'état de révocation du certificat et acceptent la connexion.

Activation générale du contrôle de la liste de blocage avec Soft-fail en cas d'erreur

Si vous souhaitez que Google Chrome vérifie le statut de révocation des certificats, mais qu'il continue silencieusement en cas d'indisponibilité des informations de révocation (soft-fail), vous pouvez activer le paramètre de registre (ou la stratégie de groupe) „EnableOnlineRevocationChecks“ (Google, Microsoft) :

NavigateurUtilisateur ou machineCléDonnées/valeur
ChromeHKEY_CURRENT_USERLogiciel\Policies\Google\Chrome„EnableOnlineRevocationChecks“=dword:00000001
ChromeHKEY_LOCAL_MACHINELogiciel\Policies\Google\Chrome„EnableOnlineRevocationChecks“=dword:00000001
Edge (Anaheim)HKEY_CURRENT_USERLogiciel\Policies\Microsoft\Edge„EnableOnlineRevocationChecks“=dword:00000001
Edge (Anaheim)HKEY_LOCAL_MACHINELogiciel\Policies\Microsoft\Edge„EnableOnlineRevocationChecks“=dword:00000001

Maintenant, le navigateur Chrome reconnaîtra correctement le certificat comme révoqué (code d'erreur NET::ERR_CERT_REVOKED).

Activation sélective de la vérification de la liste de révocation pour les certificats émis par les autorités de certification internes avec hard-fail en cas d'erreur

Il est également possible que seuls les certificats émis par des autorités de certification internes soient vérifiés quant à leur statut de révocation, mais alors avec un hard-fail si l'information ne peut pas être obtenue.

Lorsque ce paramètre est activé, Google Chrome effectue toujours un contrôle de révocation pour les certificats de serveur qui ont été validés avec succès et qui sont signés par des certificats CA installés localement.
Si Google Chrome n'est pas en mesure d'obtenir des informations sur le statut de révocation, ces certificats seront considérés comme révoqués (‚hard-fail‘).
Si cette politique n'est pas définie ou si elle est définie comme fausse, Google Chrome utilisera les paramètres de vérification de révocation en ligne existants.

https://www.chromium.org/administrators/policy-list-3#RequireOnlineRevocationChecksForLocalAnchors

Pour cela, le paramètre de registre (ou la stratégie de groupe) „RequireOnlineRevocationChecksForLocalAnchors“ (Google, Microsoft) :

NavigateurUtilisateur ou machineCléDonnées/valeur
ChromeHKEY_CURRENT_USERLogiciel\Policies\Google\Chrome„RequireOnlineRevocationChecksForLocalAnchors“=dword:00000001
ChromeHKEY_LOCAL_MACHINELogiciel\Policies\Google\Chrome„RequireOnlineRevocationChecksForLocalAnchors“=dword:00000001
Edge (Anaheim)HKEY_CURRENT_USERLogiciel\Policies\Microsoft\Edge„RequireOnlineRevocationChecksForLocalAnchors“=dword:00000001
Edge (Anaheim)HKEY_LOCAL_MACHINELogiciel\Policies\Microsoft\Edge„RequireOnlineRevocationChecksForLocalAnchors“=dword:00000001

Si l'information de verrouillage ne peut maintenant pas être récupérée, l'utilisateur recevra un message d'erreur correspondant (code d'erreur NET::ERR_CERT_UNABLE_TO_CHECK_REVOCATION).

En revanche, Internet Explorer - puisqu'un soft-fail y est finalement implémenté - acceptera tacitement le certificat dans un tel cas, comme décrit précédemment.

Dois-je activer la vérification du statut de blocage ?

En général, pour les certificats des autorités de certification internes, il est dans la plupart des cas judicieux que leur statut de révocation soit vérifié. L'Office fédéral de la sécurité dans la technologie de l'information (BSI) l'exige même pour l'administration fédérale.

La seule option vraiment valable pour les réseaux d'entreprise est, à mon avis, celle du hard-fail. Celle-ci exige toutefois que l'infrastructure pour les informations de blocage présente une disponibilité élevée correspondante et, dans le cas de grands environnements, qu'elle soit également en mesure de faire face à la charge attendue (surtout dans le cas où OCSP est utilisé).

Liens complémentaires :

Sources externes :

Les commentaires sont fermés.

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais