Il incombe en dernier ressort à l'utilisateur du client de vérifier la validité du certificat.En tant que fournisseur de services, à part éduquer l'utilisateur si vous le pouvez, vous ne pouvez pas faire grand-chose de votre côté: vous ne contrôlez pas quels certificats sont approuvés par le navigateur de l'utilisateur et vous ne pouvez pas savoir si les utilisateurs ont vérifié qu'ils utilisent correctement SSL / TLS et n'ont pas ignoré les avertissements potentiels.
Ce que vous devez essayer d'évaluer, c'est comment votre utilisateur est Je suppose que le public cible de votre site Web n'est pas nécessairement un expert technique ou PKI.La façon dont vos utilisateurs vont réagir dépendra de ce qu'ils ont appris sur les certificats.Malheureusement, il y a un beaucoup d'informations contradictoires ou vagues sur ce sujet, provenant même des autorités de certification elles-mêmes (rappelez-vous que les autorités de certification ont tout intérêt à inciter leurs clients à acheter des certificats plus chers).
Modes de validation
L'objectif général d'un certificat (à clé publique) est de lier une identité à une clé publique (donc lier l'identité au serveur en utilisant la clé privée correspondante dans le handhsake SSL / TLS).
Lucas Kauffman a déjà écrit une réponse détaillant la différence entre les certificats validés par le domaine , certificats validés par l'organisation et certificats de validation étendue. La vraie question que vous devez vous poser est ce que vous essayez de prouver à l'utilisateur.
La différence entre ces types de certificats est la façon dont cette identité elle-même est définie.
Les certificats validés par le domaine vous garantissent que le certificat a été émis au propriétaire de ce domaine. Pas plus, mais pas moins (je suppose que la procédure de validation était correcte ici). Dans de nombreux cas, cela suffit. Tout dépend de la question de savoir si le site Web dont vous faites la promotion doit être lié à une institution déjà bien connue hors ligne. Les certificats validés par rapport à une organisation (certificats OV et EV) sont principalement utiles lorsque vous devez également lier le domaine à une organisation physique.
Par exemple, c'est utile pour une institution initialement connue via son building (par exemple Bank of America) pour pouvoir dire qu'un certificat pour bankofamerica.com est bien pour l'endroit où vous avez donné votre argent physique. Dans ce cas, il est judicieux d'utiliser un certificat OV ou EV. Cela peut également être utile en cas d'ambiguïté concernant l'institution derrière le nom de domaine (par exemple apple.com et apple.co.uk ), ce qui est encore plus important. le nom de domaine similaire appartient à un rival / attaquant utilisant la similarité de nom à de mauvaises fins.
En revanche, www.google.com est ce qui définit Google auprès du public; Google n'a pas besoin de prouver que google.com appartient au vrai Google. En conséquence, il utilise un certificat validé par le domaine (même chose pour amazon.com).
Encore une fois, c'est vraiment utile si l'utilisateur sait comment vérifier cela. Les navigateurs n'aident pas vraiment ici. Firefox dit simplement "qui est exécuté par (inconnu)" si vous voulez plus de détails sur le certificat sur www.google.com , sans vraiment dire ce que cela signifie.
Les certificats de validation étendue sont une tentative pour améliorer cela, en rendant la procédure de validation d'organisation plus stricte, et en rendant le résultat plus visible: barre verte et organisation plus visible.
Malheureusement, cela est parfois utilisé d'une manière qui augmente la confusion, je pense. Voici un exemple que vous pouvez vérifier par vous-même: l'une des grandes banques britanniques (NatWest) utilise le https://www.nwolb.com/ pour son sur- services bancaires en ligne. Il est loin d'être évident que le nom de domaine appartient à NatWest (qui possède également le nom plus logique natwest.co.uk , d'ailleurs). Pire encore, la validation étendue (si vous cochez le nom à côté de la barre verte) se fait par rapport à "Royal Bank of Scotland Group plc":
Pour ceux qui suivent l'actualité financière, cela a du sens car RBS et NatWest appartiennent au même groupe, mais techniquement, RBS et NatWest sont des concurrents (et tous deux ont des succursales dans la rue principale au Royaume-Uni - même si cela va Si votre utilisateur n'a pas cette connaissance supplémentaire sur les groupes qui négocient sous quel nom, le fait qu'un certificat soit délivré au nom d'un concurrent potentiel devrait sonner l'alarme. Si, en tant qu'utilisateur, vous avez vu un certificat sur gooooogle.com délivré à Microsoft ou Yahoo, quelle que soit la couleur de la barre, vous ne devez pas le traiter comme le site de Google.
le point à garder à l'esprit avec les certificats EV est que leur configuration est codée en dur dans les navigateurs. Il s'agit d'un paramètre de type compilation, qui ne peut pas être configuré ultérieurement (contrairement aux magasins de certificats de confiance normaux, où vous pouvez ajouter votre propre certificat CA institutionnel, par exemple). D'un point de vue plus cynique, certains pourraient considérer cela comme un moyen pratique pour les principaux acteurs de conserver une position forte sur le marché.
Sceaux
Certains CA proposent également divers " sceaux »que vous pouvez mettre sur votre site Web, généralement avec des couleurs différentes selon le type de certificat que vous avez acheté. Ils semblent être conçus comme une étape supplémentaire pour empêcher les autorités de certification moins réputées d'émettre un certificat valide à la mauvaise partie.
Autant que je sache, ils sont totalement inutiles du point de vue de la sécurité. En effet, lorsque vous cliquez dessus pour faire vérifier votre certificat (par exemple, si vous cliquez sur le logo «vérifié et sécurisé» de GoDaddy, vous vous retrouvez sur cette page ), rien ne vous dit que le certificat que vous voyez est le même que celui qui est envoyé au service derrière seal.godaddy.com . En effet, s'il y avait un attaquant MITM entre vous et example.com , avec un autre certificat valide pour example.com émis par une CA bâclée, cet attaquant MITM ne serait pas entre example.com et seal.godaddy.com . À moins que l'utilisateur ne regarde vraiment le certificat en détail, le sceau n'aiderait pas beaucoup (en gardant à l'esprit que l'attaquant pourrait simplement supprimer le lien de sceau ou le pointer vers celui de l'autre CA).
Assurances
Certains certificats sont également accompagnés d'une sorte d'assurance. Vous obtiendrez une sorte de compensation en cas de problème lors d'une transaction jusqu'à un montant limité. Je ne vois pas clairement quelles seraient les conditions pour demander une telle assurance.
Laquelle choisir?
En fin de compte, la plupart des utilisateurs conservent la liste par défaut des autorités de certification de confiance certificats fournis avec leur système d'exploitation ou leur navigateur. Étant donné que l'interface utilisateur ne distingue pas très clairement les autorités de certification, la sécurité globale vue par l'utilisateur (dont la responsabilité est de vérifier le certificat) sera réduite par le plus petit dénominateur commun de chaque catégorie (barres bleues et vertes).
S'il est important de lier le nom de domaine à une organisation «brique et mortier», cela vaut la peine d'envisager un certificat EV. Personnellement, je ne pense pas que la façon dont les interfaces utilisateur distinguent les certificats DV et OV soit suffisamment bonne pour rendre utile l'affichage du nom de l'organisation avec une barre bleue.
Si vous êtes principalement connu par votre domaine (ou s'il n'y a aucune ambiguïté que le domaine est le vôtre, du point de vue de l'utilisateur), optez pour n'importe quel certificat de barre bleue. (Vérifiez les détails de l'assurance si cela est pertinent pour votre site Web.)