Comment garantir la sécurité des communications avec ses visiteurs sur son site Internet ?

Internet, IT Infrastructure, Security

Apprenez tout sur le protocole de sécurité SSL en quelques minutes, et protégez votre réputation en offrant aux visiteurs de votre site Internet une image de qualité adéquate en choisissant en connaissance de cause le juste certificat SSL.

Comment peut-on garantir la sécurité des informations qui sont échangées entre un site Internet et un navigateur web ?

Les informations qu’on échange avec un site web peuvent être particulièrement sensibles. Il peut s’agir de données qui concernent notre vie privée, des informations concernant des transactions bancaires ou des numéros de cartes de crédit, ou encore des identifiants de connexion à des parties administratives du site.

De notre côté, qu’on soit des amateurs de Firefox, Chrome ou d’une autre marque de navigateur Internet, c’est à partir de cet outil qui nous interface directement avec le réseau, qu’il faut agir.

Du côté du serveur Internet, c’est en forçant un protocole de communication sécurisé, SSL (Secure Sockets Layer) et en utilisant des certificats de sécurité SSL conformes qu’on va faire le nécessaire.

Dans une communication Internet normale, une personne qui se place au milieu de la conversation, en se branchant sur le réseau entre notre navigateur et le serveur, peut intercepter les paquets de données qui s’échangent. Elle peut ensuite interpréter et recomposer l’information morcelée qu’elle a capturée. C’est une attaque de type “man in the middle”, possible grâce aux techniques d’ “eavesdropping” ou écoute clandestine.

On utilise donc un protocole de communication sécurisée comme SSL, autant pour établir la communication entre le navigateur et le site Internet que pour chiffrer les données que les deux s’échangent. Ainsi, même si elles sont interceptées par un attaquant, elles resteront indéchiffrables pour lui.

Comment savoir si ma communication est sécurisée ?

On a tous pris l’habitude avec nos navigateurs Internet de voir les indices visuels qui indiquent une communication sécurisée entre le navigateur et le site qu’on consulte. Ca va du petit cadenas à côté de l’adresse du site, jusqu’ à la fameuse “barre verte” qui est une indication qui apparaît en vert pétant, avant l’adresse du site, et qu’on ne peut pas rater. Ce retour visuel du navigateur a un impact important sur l’image de confiance que reflète un site Internet, notamment en termes de qualité de service et de prise en considération de la sécurité des informations données par le visiteur.

Le certificat SSL

C’est le certificat SSL, un élément essentiel du protocole de communications sécurisées SSL, qui permet au navigateur d’afficher les éléments visuels de sécurité qui correspondent au mieux au type de certificat SSL que le site lui envoie, lors de l’établissement de la communication chiffrée.

Parmi les types de certificats SSL, le plus sophistiqué et contrôlé est le certificat SSL de type “EV”, “E” pour “Extended” et “V” pour “Validation.

Voici le retour visuel du navigateur de Google sur un site muni d’un certificat SSL standard:

francescofoti.com

Voici le retour visuel du même navigateur sur un site muni d’un certificat SSL de type “EV”:

devinfo.net green bar

La différence se perçoit nettement et on peut remarquer que l’identité du propriétaire du certificat SSL est clairement et sans équivoques mise en avant, dans le cas du certificat EV, c’est la “barre verte”.

Qu’y-a-t-il dans un certificat SSL ?

Un certificat SSL est une sorte d’enveloppe. C’est un document digital qui contient des informations d’identification de son propriétaire comme le nom de son organisation, ou celui d’une personne dans cette organisation, le département concerné, etc…

On y trouve également le ou les nom(s) de domaine(s) du(des) site(s) pour lequel(s) le certificat est sensé être valide, etc…

L’ensemble de ces informations du propriétaire est ce qu’on appelle le sujet du certificat.

Le chiffrement symétrique et asymétrique

Le certificat contient une clé de décryptage, qu’on appelle la clé publique.

Elle va permettre au navigateur de déchiffrer l’information que lui envoie le serveur. Le serveur chiffre les données avant de les envoyer avec une autre clé de cryptage, la clé privée.

Les algorithmes de chiffrement qui utilisent une paire de clé différentes (clé publique / clé privée), sont des algorithmes de cryptage dit asymétrique. La particularité des clés dans le chiffrement asymétrique, c’est que la clé publique, qui permet de déchiffrer un message chiffré (avec la clé privée), n’est pas secrète et est distribuable sans mesures de confidentialité particulières, aux navigateurs Internet. Il n’y a pas de danger au cas où la clé publique est interceptée par un tiers malveillant.

Le cryptage symétrique, beaucoup plus performant que le cryptage asymétrique, permet de chiffrer et déchiffrer un message avec une même clé, la clé secrète. Par contre, les deux parties communicantes doivent connaître et donc s’échanger cette clé. Or, à l’instant où le site distribue son certificat SSL, la communication n’est toujours pas chiffrée. Il serait insensé d’échanger la clé secrète en clair, à ce moment-là.

Voilà pourquoi on a recours au cryptage asymétrique à l’établissement de la communication sécurisée dans le protocole SSL.

Comment un obtient-on un certificat SSL à utiliser pour son site ?

C’est le propriétaire du nom de domaine d’un site Internet qui peut en faire la demande et obtenir son certificat SSL auprès d’un organisme spécialisé, qualifié d’autorité de certification – “certificate authority” ou CA en anglais. Vous en connaissez certainement quelques uns comme Digicert, Verisign, Google, ou encore le nouveau “Let’s encrypt” (ie, Mozilla).

A partir du serveur qui va héberger le site Internet, le webmestre génère une paire de clés de cryptage asymétrique (publique/privée). La clé privée doit être sauvegardée et gardée secrète avec le plus grand soin.

On constitue ensuite un document électronique qui contient les informations de “sujet” du certificat, qu’on aimerait y retrouver (nom de l’organisation, département, etc…), c’est la CSR : “Certificate Signing Request”, ou, la demande de signature électronique.

On envoie cette demande et la clé publique qu’on vient de générer, à la CA (l’autorité de certification) de son choix.

La CA a maintenant tout ce qui lui faut pour générer le certificat SSL dans lequel elle va inclure:

  • La clé publique qui lui a été communiquée;
  • Un autre certificat qui permet d’authentifier la CA elle-même, c’est le certificat intermédiaire;
  • La période de validité du certificat.

La CA signe numériquement le certificat qu’elle crée (d’où le nom CSR pour la demande) et le délivre finalement au propriétaire du site, qui peut l’installer sur le serveur. Le certificat intermédiaire (identifiant la CA) doit aussi être installé sur le serveur. Les deux certificats sont en fait envoyés au navigateur lors de l’établissement de la connexion sécurisée.

A propos de la signature numérique

Une signature numérique c’est une empreinte digitale qui est calculée par rapport à un contenu et à un algorithme de chiffrement asymétrique, de sorte que si la moindre information de ce contenu est modifiée, par exemple par un attaquant capable d’intercepter et de retransmettre le contenu altéré, l’empreinte n’est plus valide. Lorsque le receveur d’un document numériquement signé, dans notre cas le navigateur Internet, vérifie l’empreinte numérique que devrait avoir le contenu signé, dans notre cas de figure un certificat SSL, avec la clé publique de déchiffrage transmise, il s’aperçoit d’une éventuelle supercherie et peut alors considérer le contenu comme n’étant plus digne de confiance.

https://fr.wikipedia.org/wiki/Signature_num%C3%A9rique

Les certificats racine

Comme un système de poupées russes, un certificat émis contient le certificat de son émetteur qui permet de l’authentifier. Le certificat contenu est un certificat intermédiaire, lui-même contenant un certificat qui l’authentifie, et ainsi de suite. C’est ce qu’on appelle la “certificate chain”, pour désigner cette imbrication qui prend fin lorsque le certificat contenu est le certificat racine de la CA.

Le certificat racine d’une CA n’a pas besoin d’être authentifié par un certificat contenu car ces certificats sont intégrés dans des bases de données propres aux navigateurs Internet ou aux systèmes d’exploitation (Mac, Windows, Linux, …) auquel le navigateur peut accéder. Les certificats racine des CAs ne sont donc pas envoyés par le serveur Internet du site consulté, mais sont déjà présent dans le système du visiteur.

On utilise des certificats intermédiaires pour minimiser l’impact sécuritaire, au cas la clé privée de l’un de ceux-ci est compromise (généralement par vol, typiquement lorsqu’une CA se fait pirater ses bases de données). La clé privée du certificat racine n’est pas compromise si celle d’un certificat intermédiaire s’échappe. Dans ce cas, la CA peut simplement révoquer le certificat intermédiaire, en produire un autre à partir de son certificat racine, et continuer à fournir des certificats SSL.

Une CA qui s’est fait pirater ses clés privées, celles de ses certificats racine, c’est possible et c’est déjà arrivé. Disposer de la clé privée d’un certificat racine signifie être en mesure de se faire passer pour la CA compromise et distribuer des certificats SSL frauduleux.

La validité des certificats

C’est au navigateur de s’assurer de la validité des certificats qu’il reçoit. Déjà par rapport à sa période de validité. Mais aussi, chaque navigateur a d’une manière ou d’une autre accès à un catalogue de certificats racine et à des listes de certificats révoqués (racine, intermédiaires ou autres), soit dans sa propre base de données, soit dans un répertoire maintenu par le système d’exploitation (Mac, Windows) auquel il a accès. C’est ce qu’on appelle parfois le certificate store, le magasin de certificats.

Firefox par exemple utilise son propre magasin de certificats (reconnus et révoqués), alors que chrome et internet explorer sur Windows utilisent le magasin de certificats fourni par le système d’exploitation.

Si vous êtes sous Windows vous avez peut-être vu passer parfois des mises-à-jour du système dans “Windows Update” qui sont libellées avec quelque chose comme “mise-à-jour des certificats racine”; c’est justement des mises-à-jour de ces listes de certificats racine des CA, car ces derniers ne sont pas envoyés par les serveurs.

Le processus d’établissement de la communication

On peut maintenant s’intéresser au processus d’établissement de la communication sécurisée.

C’est ce qu’on appelle le “SSL handshake”, ou la poignée de main SSL, qui est une phase initiale du protocole qui se passe très rapidement. En 5 points, on a:

  1. Le navigateur demande l’accès sécurisé au site en spécifiant “https” comme protocole avant le nom de domaine, demandant ainsi au site de s’identifier;
  2. Le serveur renvoie une copie de son certificat SSL, la clé publique avec;
  3. Le navigateur vérifie la validité du certificat, en utilisant notamment le magasin de certificats racines auquel il a accès, pour valider le certificat intermédiaire inclus dans le certificat SSL. Il vérifie les certificats par rapport aux listes de révocations. Il vérifie que le nom de domaine et bien celui du site auquel on se connecte et qu’il fait partie de ceux couverts par le certificat. Il crée et chiffre avec la clé publique du serveur, une clé de cryptage symétrique qui sera utilisée pour le chiffrage symétrique de la suite de la communication; c’est la clé de session;
  4. Le serveur déchiffre la clé de session et renvoie une confirmation chiffrée avec la clé de session pour commencer la session de communication cryptée;
  5. Le server et le navigateur communiquent maintenant en cryptant les données transmises avec la clé de session que les deux connaissent.

L’importance suprême des certificats EV

On utilise SSL pour chiffrer les communications dans le but créer un environnement de confiance perceptible, entre le visiteur et potentiel client d’un site Internet et l’organisme propriétaire qui l’opère, et qui engage ainsi sa réputation.

Il s’agit de convaincre et rassurer les personnes qui accèdent aux services proposés par le site que les mesures et précautions de sécurité nécessaires à protéger la communication d’informations sensibles (transactions commerciales ou bancaires, échanges de données médicales, etc…) sont en vigueur.

Le propriétaire du site Internet est quelque part à la merci des navigateurs, qui sont ceux qui s’occupent de rendre perceptible cette sécurité. La seule chose qu’il peut faire pour communiquer une image sécuritaire respectueuse, c’est de montrer qu’il s’est porté acquéreur d’un certificat EV; une étiquette qui se paie cher dû au travail additionnel qu’effectue la CA pour authentifier le propriétaire du site. La CA, entre autres:

  • Vérifie l’existence légale, physique et opérationnelle de l’organisation,
  • Effectue les contrôles de validité des identités des personnes concernées,
  • Vérifie le droit exclusif du propriétaire d’utiliser le nom de domaine,
  • Vérifie que l’organisation a explicitement autorisé la délivrance du certificat,

Ce qui revient par exemple à vérifier l’inscription à un registre du commerce local officiel ou à valider les documents officiels d’identité des personnes concernées, etc… C’est là également que les CA se démarquent de leur concurrent, par la rapidité et la profondeur des validations qu’ils déroulent pour l’authentification du propriétaire.

Mozilla’s Let’s encrypt!

La fondation Mozilla (qui nous a apporté Firefox) est devenue une CA d’un type particulier.

Mozilla propose un système automatique de génération et renouvellement de certificats SSL de bonne qualité et ils sont gratuits. Il suffit pour cela que l’hébergeur implémente les programmes nécessaire sur ses serveurs.

Cette étonnante et innovante initiative contribue à la propager rapidement et à moindre coût, l’implémentation des communications sécurisées sur Internet; pourquoi rester sur un protocole http non sécurisé, lorsque le HTTPS – disponible partout – est immédiatement abordable ?

Seul inconvénient, mais il est de taille, il n’y a pas de certificats Let’s encrypt de type EV.

SSL c’est fini ! Maintenant, c’est TLS…

Surprise! En particulier si vous êtes arrivés jusqu’à la fin de ce billet avec les idées claires…

Dans son histoire, le protocole SSL a été révisé à cause de vulnérabilités multiples, jusqu’à ce qu’il atteigne sa version 3. Il a ensuite changé de nom, et de spécifications internes, pour s’appeler désormais (depuis 2001) TLS (Transport Layer Security), qui lui a atteint sa version 1.2. Ceci dit, toute l’information exposée ici reste valable, seul le nom du protocole change. Ouf !

https://fr.wikipedia.org/wiki/Transport_Layer_Security

S’équiper et sécuriser ses communications avec les certificats digitaux, DigiCert® et devinfo.net

Dans ma société, devinfo.net, j’ai sélectionné DigiCert® comme CA partenaire pour fournir des certificats SSL adaptés et de qualité à mes clients et partenaires.
Ils ont une équipe compétente et réactive et entre eux et moi, vous serez efficacement assistés dans les démarches administratives et techniques nécessaires.
Votre certificat SSL DigiCert® saura valoriser sérieusement la démarche sécuritaire dans laquelle vous vous engagez, en particulier dans l’image qui sera reflétée auprès de vos visiteurs et clients.

Au delà du certificat lui-même, je dispose également de solutions pour intégrer le cryptage et les communications sécurisées SSL ou PGP dans vos développements web, votre CMS comme WordPress(r) ou Joomla(r), et les applications bureautiques ou mobiles en PHP, C#, VB/VBA, C et C++ entre autres.

Toutes les informations nécessaires à me contacter professionnellement se trouvent sur devinfo.net.

Comments on this entry are closed.