Google a récemment publié les résultats d’une étude réalisée sur les avertissements de sécurité des navigateurs Web. Vous savez, ces messages effrayants qui vous informent que « votre connexion n’est pas privée », vous en avez sûrement déjà vu un ?
Message d’alerte pour les racines auto-signées ou non reconnues dans Chrome
(source : BadSSL.com)
Evidemment, ces avertissements servent à quelque chose : ils empêchent les utilisateurs de se rendre sur des sites non sécurisés. Cependant, ces messages peuvent être déclenchés par différents facteurs plus ou moins graves. Le problème, c’est qu’il n’y a aucune distinction visible entre tous ces avertissements de sécurité pour que les utilisateurs moyens puissent évaluer la gravité du danger auquel ils font face. Cela affecte non seulement l’expérience des utilisateurs mais présente également le risque de les amener à simplement ignorer TOUS les avertissements. L’objectif de l’enquête de Google consistait à apporter un début de solution pour résoudre les erreurs bénignes sans que cela n’affecte les erreurs les plus graves.
Je vous recommande de lire le rapport complet lorsque vous en aurez le temps : Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors (Avertissements sauvages : les causes profondes des erreurs de certificats HTTPS dans Chrome). En attendant, j’ai résumé les points essentiels dans cet article et je vous donne également quelques conseils à mettre en pratique pour résoudre les problèmes les plus courants.
Quelles sont les causes les plus courantes des avertissements des navigateurs ?
Que se cache-t-il derrière ces avertissements ? A partir d’un échantillon de plus de 300 millions d’erreurs accumulées pendant près d’un an (lire le rapport pour connaître la méthodologie complète), Google a été en mesure d’identifier les causes de 2/3 des erreurs qui ont ensuite été catégorisées en trois types principaux : serveurs, clients et réseaux.
Source : Google
Le rapport offre une explication détaillée sur la façon dont ces catégories sont définies et sur les résultats faussement positifs ou négatifs. Voici les grandes lignes que l’on peut en tirer :
Une erreur de serveur se produit « lorsqu’un serveur présente une chaîne de certificats invalide ou incomplète ». Voici plusieurs exemples :
- Erreurs de date du serveur (ex : un site utilise un certificat expiré)
- Erreurs de correspondance avec le nom du serveur (ex : le certificat n’inclut pas le nom d’hôte du site web)
- Erreurs d’invalidité de l’autorité du serveur (ex : le certificat n’est pas relié à une racine de confiance)
- Erreurs de certificats intermédiaires manquants (ex : le serveur n’envoie que le certificat SSL sans les certificats intermédiaires)
- Erreurs d’algorithme SHA-1 (le certificat utilise l’algorithme obsolète SHA-1 auquel Chrome ne fait plus confiance)
Une erreur de client se produit « lorsqu’un client ne peut pas valider la chaîne du certificat d’un serveur correctement configuré ». Voici plusieurs exemples :
- Horloge du client incorrecte (ex : l’horloge du client est réglée à une date dans le futur et pourrait indiquer, à tort, que le certificat a expiré)
- Erreurs d’anti-virus (ex : un programme anti-virus utilisé pour déchiffrer, analyser et rechiffrer le trafic HTTPS a recours à une racine expirée pour le rechiffrement des certificats)
Une erreur de réseau se produit « lorsqu’un appareil de réseau intercepte une connexion HTTPS et remplace la chaîne du certificat avec une autre qui ne peut pas être validée par le client ». Voici plusieurs exemples :
- Erreur de portail captif (ex : un portail captif, comme ceux utilisés pour la connexion au wifi de certains hôtels et qui vous invite à vous connecter, crée une erreur de correspondance avec le nom car le navigateur cherche à atteindre un nom d’hôte spécifique (le site auquel vous souhaitez accéder) mais se retrouve bloqué par une page de connexion dont le certificat contient un nom d’hôte différent)
- Racine de proxy TLS manquante (ex : il manque un certificat racine de proxy TLS dans le magasin du navigateur et à chaque fois qu’un utilisateur tente d’accéder à un site web qui a été intercepté et rechiffré par le proxy, un message d’erreur s’affiche car la racine n’est pas reconnue)
Surprise ! Les serveurs ne sont pas les seuls coupables…
Ce qui est particulièrement intéressant, c’est qu’il y a autant d’erreurs de serveur que d’erreurs de client ou de réseau. La plupart des publications sur ce sujet se concentrent davantage sur les configurations de serveur et donnent aux administrateurs de serveurs et de sites la responsabilité d’empêcher ce genre d’avertissements. Les résultats de l’enquête prouvent que ce n’est pas aussi simple.
Remarque : des recherches ont également été menées sur un échantillon d’erreurs non classées et la part des erreurs de client ou réseau était supérieure à celles des serveurs, ce qui renforce davantage le rôle des clients et réseaux dans ce contexte.
Comment corriger et empêcher les erreurs de navigateur les plus courantes
Le rapport explique très bien ces erreurs et leurs causes mais il ne donne pas d’informations détaillées sur la façon dont elles peuvent être corrigées ou évitées. Ce n’est pas étonnant compte tenu de l’objectif premier de ce rapport. Parfois même, des solutions sont mentionnées ou semblent évidentes selon l’erreur. Cependant, j’ai pensé que plus d’informations et d’instructions pourraient être utiles.
Vous constaterez que je vais surtout me concentrer sur les erreurs de serveur car c’est un peu plus ma spécialité et elles peuvent être facilement corrigées par les administrateurs de site. Après tout, vous ne pouvez pas vraiment contrôler si l’horloge du système de vos visiteurs n’est pas réglée à la bonne date ou si leur entreprise utilise un service d’analyse SSL. Par ailleurs, l’importance de la configuration des serveurs fait partie de ces sujets que nous essayons toujours de mettre en lumière. Obtenir un certificat SSL n’est qu’une étape parmi d’autres pour activer le HTTPS, configurer votre serveur correctement est tout aussi essentiel.
Remarque : bien que le rapport ne donne pas beaucoup de conseils pour parer aux erreurs de serveur, vous y trouverez une section consacrée aux changements que Chrome mettra en place pour aider à réduire les autres erreurs. Par exemple, des avertissements différents sont désormais affichés pour les utilisateurs dont l’horloge du système n’est pas réglée à la bonne date. Il leur est expliqué pourquoi ils reçoivent ces avertissements de sécurité, plutôt que de recevoir un message d’alerte générique sans action à entreprendre. Le nombre d’erreurs de ce genre a depuis déjà bien diminué. Chrome travaille également à la création de solutions pour les détections de portail captif, les certificats intermédiaires manquants et les problèmes de correspondance avec le nom. Je vous recommande sérieusement de lire le rapport en entier ! Jetez au moins un œil à la section sur les mitigations à la fin du rapport pour avoir une idée de ce qui se prépare.
Erreurs de date du serveur
Sans surprise, selon le rapport, presque toutes les erreurs de date de serveur ont été causées par des certificats expirés. La solution est plutôt évidente : ne laissez pas votre certificat expirer ! Qu’est-ce que vous dites ? Vous gérez toujours vos certificats avec un tableau Excel et parfois certains échappent à votre surveillance ?
Allez, tout le monde, passez à une plate-forme de gestion qui vous aidera à garder le contrôle ! Vous avez des certificats de différentes AC et vous avez du mal à les gérer correctement ? Utilisez un outil d’inventaire qui va retrouver tous vos certificats quel que soit le fournisseur. Vous souhaitez automatiser le processus entier pour ne plus avoir à vous inquiéter ? Vous pouvez le faire à l’aide d’une API et du protocole ACME (ce n’est pas que pour les certificats DV). Vous n’avez plus aucune excuse pour laisser un certificat expirer !
Erreurs de correspondance du nom
Google appelle ces erreurs « www/sans www » et « hors wildcard » des erreurs de sous-domaines mais c’est la même logique qui s’applique pour tout nom d’hôte ou de domaine. Le nom d’hôte doit être indiqué dans le certificat, soit de manière individuelle ou avec un wildcard (ex : un certificat pour *.exemple.fr sera valide pour demo.exemple.fr).
Il est possible que de nombreuses erreurs « www » proviennent d’une croyance populaire qu’un certificat sécurise automatiquement les versions avec et sans « www » d’un domaine. Ce n’est pas le cas ! Vous devez avoir les deux versions mentionnées sur le certificat (ou utiliser un certificat wildcard). Pour information, GlobalSign inclut les deux versions sans frais supplémentaires dans ses certificats (vous n’avez pas à payer deux fois pour sécuriser les versions avec et sans « www » de votre domaine).
Les erreurs de wildcard pourraient être dues à de simples oublis ou éventuellement des erreurs de domaines à plusieurs niveaux (ex : un certificat pour *.exemple.fr ne pourra pas être utilisé pour sécuriser test.demo.exemple.fr ou exemple.fr). La morale de cette histoire, c’est qu’il faut toujours vérifier que votre nom d’hôte est inclus dans votre certificat ou couvert par le wildcard.
Erreurs d’autorité de serveur invalide
Pour que le certificat de votre site web soit reconnu, il doit être relié à une racine (ou autorité) déjà présente dans les magasins de confiance des navigateurs. Google a découvert que la plupart de ces erreurs, dans lesquelles les certificats étaient reliés à une racine qui ne se trouvait pas dans le magasin de certificat des navigateurs, provenait principalement de certificats auto-signés ou de racines gouvernementales.
En gros, vous ne devriez pas utiliser de certificats auto-signés sur des sites Web publiques. Vous vous demandez peut-être « et les sites internes ou les intranets ? ». Le risque existe bien là aussi car vos employés y accèdent depuis un navigateur et recevraient alors des avertissements. Leur apprendre à ignorer ces messages pour les sites internes pourraient les amener à toujours les ignorer, même pour les sites où le risque est réel, ce qui mettrait votre organisation dans une position de vulnérabilité face au malware et à d’autres choses malveillantes.
Remarque : si vous utilisez des certificats auto-signés sur vos réseaux internes car les configurations dont vous avez besoin ne sont pas conformes aux recommandations du CA/B Forum (ex : noms de serveur interne, nom d’hôte local, période de validité plus longue), certaines AC (comme GlobalSign) vous permet d’obtenir des certificats émis depuis des racines privées conçues spécialement pour ces cas d’utilisation.
Les racines gouvernementales peuvent créer des erreurs car elles ne sont pas toujours présentes dans les magasins de confiance standard. Souvent, les utilisateurs doivent les installer séparément sur leurs machines et sur leurs appareils. Dans son rapport, Google évoque une potentielle solution à ce problème. En résumé, lorsqu’un utilisateur fait face à ce type d’erreur, il recevrait un message spécifique avec des instructions sur la façon d’installer la racine gouvernementale appropriée. Google a conscience des défis évidents d’une telle solution mais c’est toujours intéressant de savoir ce que le géant a en tête.
Certificats intermédiaires manquants
Les certificats intermédiaires permettent de connecter un certificat SSL (émis pour un domaine ou site web) au certificat racine de confiance (l’autorité du serveur évoquée ci-dessus) présent dans le magasin de confiance du navigateur, créant ainsi une chaîne de confiance. Cela signifie qu’en plus du certificat SSL, un serveur doit en général également fournir les certificats intermédiaires.
Par conséquent, la solution pour éviter ce genre d’erreur, c’est de vous assurer que les certificats intermédiaires appropriés soient aussi installés sur votre serveur. L’autorité de certification (AC) qui a émis votre certificat devrait vous fournir les certificats intermédiaires correspondants. A GlobalSign, nous fournissons les certificats appropriés lorsque nous émettons un certificat. Nous offrons également des instructions détaillées pour installer le certificat SSL et les certificats intermédiaires selon les serveurs.
Erreurs de SHA-1
Je crois que nous avons tout dit sur SHA-1. Ne l’utilisez pas !
Bonus : erreurs d’horloge du client
Cette erreur n’a rien à voir avec les serveurs mais voici ce que les administrateurs de sites et de serveurs peuvent faire pour l’éviter (lorsque l’horloge du système n’est pas réglée correctement et fait croire au navigateur que la période de validité du certificat n’est pas valide et qu’il ne faut donc pas lui faire confiance). Si vous laissez passer un certain temps entre le moment où vous recevez votre certificat et celui où vous commencez à l’utiliser, vous pouvez réduire le risque que ce genre d’erreur se produise. Si vous recevez un certificat aujourd’hui, par exemple, et que vous l’installez aujourd’hui, tous les clients avec une horloge réglée dans le passé, même avec un seul jour de retard, déclencheraient une erreur. Google a critiqué ce phénomène pour son rôle dans la multiplication des cas d’erreur de client sur les machines Windows en septembre 2016.
Bonus – erreurs de proxy TLS
Celles-ci non plus n’ont rien à voir avec les serveurs mais les entreprises peuvent les contrôler donc je pense que cela vaut la peine d’en parler. De nombreuses organisations utilisent des appareils de contrôle SSL qui interceptent et déchiffrent le trafic HTTPS, afin d’identifier les contenus malveillants. Ces appareils ont besoin de leur propre AC émettrice privée pour créer de nouvelles sessions SSL avec les clients finaux, une fois l’analyse effectuée. Ces AC émettrices ne peuvent pas être publiquement reconnues, c’est pourquoi leurs racines ne sont pas automatiquement présentes dans les magasins de confiance des navigateurs. Vous voyez où je veux en venir ? Si le navigateur de l’utilisateur final ne possède pas la racine appropriée dans son magasin de confiance, une erreur de certificat s’affichera à chaque fois qu’il visitera le site en question.
La solution à ce problème, c’est de toujours s’assurer que la racine de l’appareil est distribuée sur les machines et appareils de l’ensemble des utilisateurs. Il faut avouer que c’est parfois plus facile à dire qu’à faire, notamment si vous avez des environnements avec différents points finaux, avec des clients utilisant un autre système que Windows ou avec des appareils mobiles et de nombreuses racines à gérer et entretenir. Si vous êtes dans cette situation, considérez l’utilisation d’une racine privée et dédiée gérée par une AC externe. De cette façon, vous n’aurez qu’une seule racine à distribuer qui sera reliée à plusieurs AC émettrices secondaires qui pourront être utilisées de diverses façons (ex : analyse SSL, certificats d’authentification des utilisateurs, etc.). Nous en avons parlé dans un de nos articles, mais, en gros, cette solution vous permet d’oublier tous vos soucis de déploiement et d’entretien de ces racines et de sous-traiter la gestion du chiffrement et des AC à une autorité de certification de confiance.
En résumé : ne négligez pas la configuration de votre serveur !
Il n’est évidemment pas question d’ignorer le rôle de la configuration des clients et réseaux dans les avertissements des navigateurs. C’est d’ailleurs très bien de la part de Google d’avoir expliqué les démarches entreprises pour aider à réduire le nombre de ces avertissements de sécurité en créant des messages plus personnalisés avec des actions à entreprendre. Cependant, selon moi, les résultats de cette étude mettent davantage en lumière l’importance d’une bonne configuration de serveur.
Nous vous en parlons depuis un moment déjà… ai-je évoqué notre outil gratuit de test de configuration de serveur ? Les conseils ci-dessus vous aideront à éviter la plupart des erreurs les plus courantes, mais je vous recommande également d’essayer cet outil. Vous pourrez ainsi vous assurer qu’il n’y a aucun problème avec les composants de vos configurations (ex : le protocole SSL/TLS et le service de chiffrement que vous utilisez, contre ce qui est recommandé ou si vous êtes dans une position de vulnérabilité face aux menaces SSL les plus courantes). N’oubliez pas, vous avez besoin de bien plus qu’un simple certificat SSL pour passer à HTTPS !
Vous avez d’autres questions sur le SSL ou les configurations de serveur ? Contactez-nous et nous serons ravis d’y répondre.
