SSL/TLS 101 pour les débutants

Un regard approfondi sur le cryptage qui sécurise nos connexions internet

Si Netscape a inventé le protocole SSL au milieu des années 90, l’installation d’un certificat SSL/TLS n’est devenue obligatoire pour chaque site web qu’à l’été 2018, lorsque Google a commencé à apposer la mention “Non sécurisé” sur les sites non cryptés

Si Google – avec son moteur de recherche, son navigateur Chrome et son système d’exploitation Android – peut redéfinir l’internet de manière unilatérale, il n’était pas le seul à avoir ce mandat. Apple, Microsoft, Mozilla et les autres grands acteurs de l’industrie technologique ont tous pris la décision concertée de rendre obligatoires les certificats SSL/TLS et le protocole HTTPS.

La raison en est simple : sans SSL/TLS et la possibilité de se connecter en toute sécurité via HTTPS, toutes les communications entre les sites web et leurs visiteurs seraient échangées en clair et facilement lisibles par un tiers.

Le seul inconvénient de cette récente poussée en faveur du cryptage universel est qu’elle a entraîné un afflux de nouveaux clients sur un marché peu familier, qui ne fait pas grand-chose pour se rendre moins confus pour le propriétaire moyen d’un site web ou d’une entreprise.

Cet article servira de guide complet pour tout ce qui concerne SSL/TLS. Nous jetterons les bases en abordant des concepts fondamentaux tels que le cryptage, HTTPS et la nature des connexions Internet.

Nous espérons qu’à la fin de cet article, vous vous sentirez à l’aise pour choisir, acheter et mettre en œuvre un certificat TLS. Si vous avez des questions, n’hésitez pas à les laisser dans les commentaires ci-dessous.

Éléments fondamentaux

Commençons par discuter du concept qui se trouve au cœur de tout cela : le chiffrement.

Le cryptage, dans sa forme la plus simple, n’est rien d’autre que le brouillage des données – à l’aide d’un code ou d’une clé prédéterminée – de manière à les rendre illisibles pour quiconque, à l’exception d’une autre partie disposant de la même clé privée.

Tout au long de l’histoire, le chiffrement par clé privée a été le modèle le plus couramment utilisé. Dans ce cas, les deux parties doivent posséder ou au moins échanger une clé privée qui peut être utilisée pour crypter et décrypter les informations.

Au début, la plupart des algorithmes de chiffrement sur lesquels reposent ces cryptosystèmes étaient primitifs et reposaient sur de simples substitutions ou sur le remplacement de mots courants par des caractères. Mais au fil du temps, les chiffres ont été davantage influencés par les mathématiques et ont gagné en complexité.

Par exemple, au milieu du XVIe siècle, en France, le cryptographe du roi Louis XIV a créé un cryptogramme si bien conçu qu’il n’a été cassé que 250 ans plus tard, et encore, partiellement. Aujourd’hui encore, les archives françaises contiennent des documents vieux de plusieurs centaines d’années qui ne seront peut-être jamais déchiffrés.

Mais alors que le cryptage a toujours été un moyen de se dissimuler ou d’être clandestin, l’avènement de l’internet a rendu le concept plus courant. L’internet est omniprésent et remplit toute une série de fonctions essentielles. Chaque jour, des milliards de personnes l’utilisent pour accéder à des informations sensibles et les envoyer, pour gérer leurs finances, pour effectuer des transactions avec des entreprises, etc.

Le problème est que l’internet n’a pas été entièrement conçu pour s’adapter à ce qu’il est devenu. Au début, à l’époque où les universités et le gouvernement américain développaient des protocoles de réseau, l’internet n’était considéré que comme un mécanisme de libre échange d’informations entre le gouvernement et les institutions universitaires. À l’époque, l’activité commerciale était illégale en ligne. Le mot “eCommerce” n’avait même pas encore été inventé. Quant au site web, il s’agissait plutôt d’une notion géographique.

Ainsi, lorsque le protocole HTTP (Hypertext Transfer Protocol) a été introduit pour la première fois en 1991, le fait que les connexions qu’il formait échangeaient des données en clair n’était pas un problème rédhibitoire.

La situation est bien différente aujourd’hui. Les informations échangées en ligne ne sont pas des recherches universitaires ou des informations librement accessibles, mais des informations personnellement identifiables et des données sensibles qui peuvent coûter de l’argent ou même, dans certaines régions, la vie à des personnes. Une approche plus sûre s’imposait donc.

La réponse a été le cryptage.

Un problème d’échange de clés

L’un des problèmes qui a toujours affecté les meilleurs systèmes de cryptage persiste encore aujourd’hui.

Ce dont nous avons parlé précédemment, et qui a toujours été la norme en matière de cryptage, est le cryptage à clé privée. On parle également de cryptage symétrique ou de cryptage bidirectionnel, les clés privées assurant à la fois les fonctions de cryptage et de décryptage nécessaires à la communication.

Pour que le cryptage par clé privée fonctionne, la clé privée doit être transférée entre les parties, ou les deux parties doivent posséder leur propre copie. Quoi qu’il en soit, la sécurité des clés privées était essentielle à l’intégrité du système de cryptage et, comme vous pouvez sans doute le supposer, l’échange de clés est un problème aussi ancien que le cryptage lui-même.

Puis, dans les années 1970 – techniquement deux époques différentes, à un océan d’écart – une nouvelle forme de cryptage a été conceptualisée et mise au point : le cryptage à clé publique.

Alors que le chiffrement à clé privée est une fonction bidirectionnelle, symétrique, la clé privée pouvant à la fois chiffrer et déchiffrer les données, le chiffrement à clé publique est asymétrique, c’est-à-dire à sens unique. Au lieu d’une seule clé privée, il y a une paire de clés publique-privée. La clé publique gère le cryptage et est, comme son nom l’indique, accessible au public, tandis que la clé privée, qui gère le décryptage, est gardée secrète par son propriétaire. À l’aide de la clé publique, il est possible de crypter une donnée et de l’envoyer au propriétaire de la clé, qui sera le seul à pouvoir la décrypter.

Super, mais en quoi est-ce utile ?

Le cryptage à sens unique n’est pas idéal pour crypter les connexions internet, car il est difficile de communiquer lorsqu’une partie ne peut que crypter et que l’autre ne peut que décrypter. Non, pour crypter une connexion internet, vous devez utiliser un cryptage symétrique à clé privée.

Mais comment échanger des clés ? Surtout en ligne ?

Le chiffrement à clé publique.

C’est l’essence même du protocole SSL/TLS : l’échange sécurisé de clés.

C’est ici que nous allons relier tous ces concepts. Si vous voulez que votre communication avec un site web soit privée, vous devez vous y connecter en toute sécurité. Si vous voulez vous connecter en toute sécurité à ce site web, vous devez échanger des clés privées symétriques afin de pouvoir les utiliser pour communiquer. SSL/TLS (et l’ICP en général) n’est qu’un mécanisme sophistiqué permettant de créer et d’échanger cette clé de session.

Grâce à SSL/TLS, vous pouvez authentifier le serveur ou l’organisation avec lequel vous êtes sur le point de vous connecter et vous assurer que vous échangez en toute sécurité les clés privées que vous utiliserez pour crypter votre communication avec votre interlocuteur.

Malheureusement, SSL/TLS et l’ICP comportent beaucoup de terminologie et d’éléments mobiles qui peuvent facilement dérouter les gens, mais ces éléments n’ont rien à voir avec le fait que lorsque vous enlevez tous les calculs et le jargon technique, il s’agit simplement d’une solution technologique moderne et élégante à un problème vieux comme le monde : l’échange de clés.

Passons maintenant en revue quelques termes clés

Avant d’aller plus loin, passons en revue quelques autres termes clés. Nous avons déjà présenté HTTP, le protocole de transfert hypertexte, qui constitue l’épine dorsale de l’internet depuis des décennies. Mais comme nous l’avons vu, l’internet a évolué vers quelque chose de bien différent de ce qu’il était lorsque HTTP a été publié pour la première fois en 1991.

Un protocole plus sûr était nécessaire. C’est ainsi qu’est né le protocole HTTPS.

HTTPS, parfois appelé HTTP over TLS, utilise le cryptage pour rendre les données échangées au cours d’une connexion illisibles pour quiconque, à l’exception de la partie concernée. Cet aspect est particulièrement important si l’on considère la nature d’une connexion internet moderne.

Alors que dans les premiers temps de l’internet, une connexion était raisonnablement directe, aujourd’hui les connexions sont acheminées à travers des dizaines d’appareils jusqu’à leur destination finale. Si vous voulez une démonstration pratique de ce phénomène, ouvrez l’invite de commande de votre système d’exploitation et entrez la commande “tracert geekflare.com/fr”

Vous verrez alors le chemin parcouru par votre connexion jusqu’à sa destination. Jusqu’à 30 sauts. Cela signifie que vos données passent par chacun de ces dispositifs avant d’atteindre le site web ou l’application auquel vous vous connectez. Si quelqu’un dispose d’un renifleur de paquets ou d’un dispositif d’écoute installé sur l’un de ces appareils, il peut voler toutes les données transmises et même, dans certains cas, manipuler la connexion.

C’est ce qu’on appelle une attaque de type “man-in-the-middle” (MITM).

Si vous voulez en savoir plus sur l’attaque MITM, consultez ce cours en ligne.

La surface à couvrir avec les connexions internet modernes est beaucoup plus importante que la grande majorité des gens ne le pensent, c’est pourquoi il est essentiel que les données soient cryptées pendant la transmission. Vous n’avez aucune idée de qui pourrait écouter, ni de la facilité avec laquelle vous pouvez le faire.

Une connexion HTTP est établie via le port 80. En ce qui nous concerne, vous pouvez considérer les ports comme des constructions indiquant un service ou un protocole réseau. Un site web standard desservi par HTTP utilise le port 80. Le protocole HTTPS utilise généralement le port 443. Lorsqu’un site web installe un certificat, il peut rediriger ses pages HTTP vers des pages HTTPS, et les navigateurs des utilisateurs tenteront de se connecter de manière sécurisée via le port 443, en attendant l’authentification.

Malheureusement, les termes SSL/TLS, HTTPS, PKI et cryptage sont souvent utilisés à tort et à travers, parfois même de manière interchangeable :

• SSL – Secure Sockets Layer, le protocole de cryptage original utilisé avec HTTPS
• TLS – Transport Layer Security, le protocole de cryptage plus récent qui a remplacé SSL
• HTTPS – Version sécurisée de HTTP, utilisée pour établir des connexions avec des sites web
• PKI – Public Key Infrastructure, désigne l’ensemble du modèle de confiance qui facilite le cryptage à clé publique

SSL/TLS fonctionnent conjointement pour permettre les connexions HTTPS. Et l’ICP fait référence à l’ensemble du modèle lorsque vous effectuez un zoom arrière.

Vous avez compris ? Ne vous inquiétez pas, vous l’aurez.

Construire une infrastructure à clé publique

Maintenant que nous avons posé les bases, examinons de plus près l’architecture employée par le modèle de confiance au cœur de SSL/TLS.

Lorsque vous arrivez sur un site web, la première chose que fait votre navigateur est de vérifier l’authenticité du certificat SSL/TLS que le site lui présente. Nous verrons ce qui se passe après cette authentification dans quelques sections, mais nous allons commencer par discuter du modèle de confiance qui rend tout cela possible.

Nous commencerons donc par poser la question suivante : comment mon ordinateur sait-il s’il doit faire confiance à un certificat SSL/TLS donné ?

Pour répondre à cette question, nous devrons parler de l’ICP et des différents éléments qui la font fonctionner. Nous commencerons par les autorités de certification et les programmes racine.

Autorités de certification

Une autorité de certification est une organisation qui se conforme à un ensemble de normes prédéterminées en échange de la possibilité d’émettre des certificats numériques de confiance.

Il existe des dizaines d’autorités de certification, gratuites ou commerciales, qui peuvent délivrer des certificats fiables.

Elles doivent toutes respecter un ensemble de normes qui ont été débattues et légiférées par le CA/Browser Forum, qui agit en tant qu’organisme de réglementation pour l’industrie TLS. Ces normes définissent des éléments tels que

• Les garanties techniques qui doivent être mises en place
• Les meilleures pratiques en matière de validation
• Les meilleures pratiques en matière de délivrance
• Les procédures et les délais de révocation
• Les exigences en matière d’enregistrement des certificats

Ces lignes directrices ont été établies par les navigateurs, en collaboration avec les autorités de certification. Les navigateurs jouent un rôle unique dans l’écosystème TLS.

Personne ne peut naviguer sur l’internet sans son navigateur web. C’est donc le navigateur qui recevra et validera le certificat numérique TLS, puis échangera des clés avec le serveur. Compte tenu de leur rôle primordial, ils ont donc une influence considérable.

Et il est important de garder à l’esprit que les navigateurs ont été conçus pour être aussi sceptiques que possible. Pour ne faire confiance à rien. C’est le meilleur moyen d’assurer la sécurité de leurs utilisateurs. Par conséquent, si un navigateur doit faire confiance à un certificat numérique – qui peut potentiellement être utilisé à mauvais escient au détriment de l’utilisateur – il doit avoir l’assurance que la personne qui a émis ce certificat a fait preuve de la diligence requise.

C’est le rôle et la responsabilité des autorités de certification. Les navigateurs ne supportent pas non plus les erreurs. Il existe un véritable cimetière d’anciennes autorités de certification qui ont eu maille à partir avec les navigateurs et qui ont été mises au rancart.

Lorsqu’une autorité de certification a démontré qu’elle respecte les exigences de base du forum CAB et qu’elle a passé avec succès tous les audits et examens requis, elle peut demander aux différents programmes racine d’ajouter ses certificats racine.

Programmes racine

Un programme racine – les principaux sont gérés par Apple, Microsoft, Google et Mozilla – est l’appareil qui supervise et facilite les magasins racine (parfois appelés magasins de confiance), qui sont des collections de certificats d’autorité de certification racine résidant sur le système d’un utilisateur. Une fois de plus, ces racines sont extrêmement précieuses et dangereuses – elles peuvent émettre des certificats numériques de confiance, après tout – et la sécurité est donc de la plus haute importance.

C’est pourquoi les autorités de certification n’émettent presque jamais de certificats directement à partir de l’autorité de certification racine. Au lieu de cela, elles créent des certificats racine intermédiaires et les utilisent pour émettre des certificats d’utilisateur final ou de feuille. Elles peuvent également confier ces racines à des sous-AAC, qui sont des autorités de certification ne disposant pas de leurs propres racines, mais qui peuvent néanmoins émettre des certificats à signature croisée à partir de leurs certificats intermédiaires.

Mettons tout cela bout à bout. Lorsqu’un site web souhaite obtenir un certificat TLS, il génère ce que l’on appelle une demande de signature de certificat (CSR) sur le serveur sur lequel il est hébergé. Cette demande contient tous les détails que le site web souhaite voir figurer sur le certificat. Comme vous le verrez dans un instant, la quantité d’informations peut varier, allant de détails commerciaux complets à une simple identité de serveur, mais une fois la CSR remplie, elle est envoyée à l’autorité de certification pour délivrance.

Avant de délivrer le certificat, l’autorité de certification devra faire preuve de la diligence requise par le CA/Browser Forum et valider l’exactitude des informations contenues dans le CSR. Une fois cette vérification effectuée, elle signe le certificat à l’aide de sa clé privée et le renvoie au propriétaire du site web pour qu’il l’installe.

Chaînage de certificats

Une fois le certificat TLS installé, chaque fois que quelqu’un visite le site, le serveur qui l’héberge présente le certificat au navigateur de l’utilisateur. Le navigateur examinera la signature numérique du certificat, celle qui a été apposée par l’autorité de certification de confiance et qui atteste que toutes les informations contenues dans le certificat sont exactes.

C’est là que le terme “chaînage de certificats” entre en jeu.

Le navigateur va lire la signature numérique et remonter d’un maillon dans la chaîne – ensuite, il vérifiera la signature numérique du certificat intermédiaire dont la clé privée a été utilisée pour signer le certificat feuille. Il continuera à suivre les signatures jusqu’à ce que la chaîne de certificats se termine par l’une des racines de confiance de son magasin de racines, ou jusqu’à ce que la chaîne se termine sans atteindre une racine, auquel cas une erreur du navigateur s’affichera et la connexion échouera.

C’est la raison pour laquelle vous ne pouvez pas émettre et signer vous-même vos certificats.

Les navigateurs ne font confiance qu’aux certificats SSL/TLS qu’ils peuvent relier à leur magasin racine (ce qui signifie qu’ils ont été émis par une entité de confiance). Les autorités de certification sont tenues de respecter des normes spécifiques pour rester dignes de confiance, et même dans ce cas, les navigateurs sont peu enclins à leur faire confiance.

Les navigateurs n’ont pas de telles garanties concernant les certificats auto-signés, c’est pourquoi ils ne devraient être déployés que sur des réseaux internes, derrière des pare-feux et dans des environnements de test.

Types de certificats SSL/TLS et fonctionnalité

Avant d’examiner SSL/TLS en mouvement, parlons des certificats et des différentes itérations disponibles. Les certificats TLS facilitent le protocole TLS et aident à définir les conditions des connexions HTTPS cryptées qu’un site web établit.

Nous avons mentionné précédemment que l’installation d’un certificat TLS vous permet de configurer votre site web pour qu’il établisse des connexions HTTPS via le port 443. Il agit également comme une sorte de badge pour le site ou le serveur avec lequel vous interagissez. Pour en revenir à l’idée qu’au fond, SSL/TLS et PKI sont tous des formes exquises d’échange de clés sécurisé, le certificat SSL/TLS permet d’indiquer au navigateur à qui il envoie la clé de session, c’est-à-dire qui est l’autre partie à l’autre bout de la connexion.

Lorsque vous décomposez les différentes itérations des certificats SSL/TLS, il est important de garder cela à l’esprit. Les certificats varient en termes de fonctionnalité et de niveau de validation. En d’autres termes, ils varient en fonction de ce qui suit :

• Le nombre d’identités à affirmer
• Quels sont les points d’extrémité sur lesquels l’identité doit être affirmée ?

Les réponses à ces deux questions vous donneront une indication assez claire du type de certificat dont vous avez besoin.

Nombre d’identités à valider

Il existe trois niveaux de validation différents pour les certificats SSL/TLS, et ils varient en fonction de la quantité d’informations d’identité que votre site web souhaite affirmer.

• Certificats SSL de validation de domaine – Validation de l’identité du serveur
• Certificats SSL de validation de l’organisation – pour attester de l’identité partielle de l’organisation
• Certificats SSL Extended Validation (validation étendue) – Ils attestent de l’identité complète de l’organisation

Les certificats SSL Domain Validation sont de loin les plus populaires en raison de leur prix et de la rapidité avec laquelle ils peuvent être émis. Les certificats SSL/TLS DV nécessitent une simple vérification du contrôle du domaine, qui peut être effectuée de différentes manières, mais dès qu’elle est effectuée, le certificat peut être délivré. Vous pouvez également obtenir gratuitement des versions de 30 et 90 jours de ces certificats, ce qui a sans aucun doute augmenté leur part de marché.

L’inconvénient est que les certificats SSL DV n’affirment qu’une identité minimale. Étant donné que près de la moitié des sites web d’hameçonnage sont désormais dotés d’un certificat SSL DV, ils ne vous apportent pas nécessairement beaucoup de confiance.

Les certificats SSL à validation d’organisation sont le premier type de certificat SSL/TLS. C’est également le seul type de certificat SSL qui peut sécuriser une adresse IP suite à la décision prise en 2016 par le CAB Forum d’invalider tous les certificats SSL pour intranet. La validation d’organisation nécessite un contrôle commercial léger et peut généralement être émise dans un délai d’un jour ou deux, parfois plus rapidement. Les certificats SSL OV affirment certaines informations organisationnelles, mais un internaute doit cliquer sur l’icône du cadenas pour les trouver. De nos jours, on voit beaucoup de certificats SSL OV déployés sur les grands réseaux d’entreprises et de sociétés, pour les connexions effectuées derrière des pare-feu par exemple.

Étant donné que ni les certificats SSL DV ni les certificats SSL OV n’affirment une identité suffisante pour satisfaire la plupart des navigateurs, ils bénéficient d’un traitement neutre.

Les certificats SSL Extended Validation sont de loin les plus controversés, car certains membres de la communauté technologique estiment qu’il faut faire davantage pour renforcer la validation dont ils dépendent. Cependant, le SSL EV affirme une identité maximale. Pour compléter la validation étendue, l’autorité de certification soumet l’organisation à un processus de vérification rigoureux qui peut durer plus d’une semaine dans certains cas.

Mais l’avantage est indéniable : parce qu’il affirme une identité suffisante, un site web doté d’un certificat SSL EV bénéficie d’un traitement unique dans le navigateur, y compris l’affichage de son nom dans la barre d’adresse du navigateur.

Il n’y a pas d’autre moyen d’y parvenir, et vous ne pouvez pas faire semblant : la barre d’adresse EV est l’un des indicateurs visuels les plus puissants dont nous disposons aujourd’hui.

Quels sont les points d’extrémité sur lesquels affirmer l’identité ?

Les certificats SSL/TLS varient également en termes de fonctionnalité. Les sites web ont beaucoup évolué depuis les premiers jours de l’internet et les entreprises les déploient de différentes manières. Certaines ont plusieurs domaines pour différents secteurs d’activité ; d’autres utilisent des sous-domaines pour plusieurs fonctions et applications web. D’autres encore utilisent les deux.

Quel que soit le contexte, il existe un certificat SSL/TLS qui peut vous aider à le sécuriser.

Domaine unique

Le site web principal et le certificat SSL standard ne forment qu’un seul domaine. La plupart des certificats SSL/TLS modernes sécurisent les versions WWW et non WWW de ce domaine, mais ils sont limités à un seul domaine. Vous pouvez comparer les certificats SSL ici.

Multi-domaines

Les certificatsmulti-domaines ou les certificats de communication unifiée (dans le cas des serveurs Microsoft Exchange et Office Communications) existent également pour permettre aux organisations de crypter plusieurs domaines avec un seul certificat. Cette option peut être intéressante car elle permet d’économiser de l’argent et de simplifier la gestion des certificats (expirations/renouvellements).

Les certificats multi-domaines et UCC utilisent SAN, le champ Subject Alternative Name dans la CSR, pour ajouter des domaines supplémentaires au certificat. La plupart des autorités de certification autorisent jusqu’à 250 SAN différents sur un même certificat. La plupart des certificats multidomaines sont livrés avec 2 à 4 SAN gratuits, le reste étant disponible à l’achat en fonction des besoins.

Certificats SSL Wildcard

Lescertificats SSL Wildcard sont un type de certificat extrêmement utile car ils permettent de crypter un nombre illimité de sous-domaines au même niveau de l’URL. Par exemple, si vous avez un site web qui utilise des sous-domaines comme :

• app.website.com
• portal.website.com
• user.website.com

Vous pouvez les chiffrer tous avec le même certificat Wildcard en utilisant un astérisque dans le champ FQDN de votre CSR : *.website.com

Désormais, tout sous-domaine, même ceux que vous n’avez pas encore ajoutés, peut être sécurisé à l’aide de ce certificat.

Les certificats Wildcard présentent toutefois deux inconvénients. Le premier est qu’en utilisant la même clé publique sur certains points de terminaison, vous êtes plus vulnérable à certains exploits tels que les attaques Bleichenbacher.

L’autre inconvénient est qu’il n’existe pas d’option EV Wildcard. En raison de la nature ouverte de la fonctionnalité Wildcard, les navigateurs ne sont pas d’accord pour leur déléguer ce niveau de confiance. Si vous souhaitez utiliser la barre d’adresse EV pour vos sous-domaines, vous devrez les chiffrer individuellement ou utiliser un certificat multidomaine EV.

Caractère générique multi-domaines

Relativement nouveau dans l’écosystème SSL/TLS, le Multi-Domain Wildcard peut crypter jusqu’à 250 domaines différents, mais il peut également utiliser un astérisque dans les champs SAN, ce qui vous permet également de crypter 250 domaines différents ET tous les sous-domaines de premier niveau qui les accompagnent.

Un autre cas d’utilisation du Multi-Domain Wildcard est celui d’un Wildcard multi-niveaux, qui permet de crypter des sous-domaines à plusieurs niveaux de l’URL (un Wildcard standard ne peut les crypter qu’à un seul niveau).

En raison de la fonctionnalité Wildcard, les Wildcards multi-domaines ne sont pas non plus disponibles dans EV.

SSL/TLS en mouvement

Maintenant que nous avons abordé tous les concepts importants qui constituent SSL/TLS et l’ICP, mettons-les ensemble et voyons-les en mouvement.

Validation et émission

Commençons par le début : un site web achète un certificat SSL/TLS auprès d’une autorité de certification ou d’un revendeur. Après l’achat, le contact organisationnel qui s’occupe de l’acquisition du certificat crée une demande de signature de certificat (CSR) sur le serveur où le certificat sera installé (le serveur qui héberge le site web).

Avec la CSR, le serveur génère également une paire de clés publique/privée et enregistre la clé privée localement. Lorsque l’autorité de certification reçoit la RSC et la clé publique, elle effectue les étapes de validation requises pour s’assurer que les informations contenues dans le certificat sont exactes. En général, pour les certificats d’authentification d’entreprise (pas de DV), il s’agit de rechercher les informations d’enregistrement d’une organisation et les dossiers publics dans les bases de données gouvernementales.

Une fois la validation terminée, l’autorité de certification utilise l’une des clés privées de l’un de ses certificats d’émission, généralement une racine intermédiaire, et signe le certificat avant de le renvoyer au propriétaire du site.

Le propriétaire du site peut maintenant prendre le nouveau certificat SSL/TLS, l’installer sur son serveur et configurer le site web pour qu’il établisse des connexions HTTPS sur le port 443 (en utilisant des redirections 301 pour envoyer le trafic des pages HTTP préexistantes vers leurs nouveaux homologues HTTPS).

Authentification et dialogue SSL

Maintenant que le certificat SSL/TLS est installé et que le site web a été configuré pour le protocole HTTPS, voyons comment il facilitera les connexions chiffrées avec les visiteurs du site.

Lors de l’accès au site web, le serveur présente le certificat SSL/TLS au navigateur de l’utilisateur. Le navigateur de l’utilisateur effectue alors une série de vérifications.

Tout d’abord, il va authentifier le certificat en affichant sa signature numérique et en suivant la chaîne de certificats. Il s’assurera également que le certificat n’a pas expiré et vérifiera les journaux de transparence des certificats (CT) et les listes de révocation des certificats (CRL). Si la chaîne renvoie à l’une des racines du magasin de confiance du système et qu’elle est valide, le navigateur fera confiance au certificat.

C’est maintenant l’heure de la poignée de main.

La poignée de main SSL/TLS est la série d’étapes au cours desquelles le client (utilisateur) et le serveur (site web) négocient les paramètres de leur connexion sécurisée, génèrent puis échangent des clés de session symétriques.

Tout d’abord, ils vont décider d’une suite de chiffrement. Une suite de chiffrement est le groupe d’algorithmes et de chiffrements qui sera utilisé pour la connexion. Le certificat SSL/TLS fournit une liste des suites de chiffrement prises en charge par le serveur. En général, une suite de chiffrement comprend un algorithme de chiffrement à clé publique, un algorithme de génération de clé, un algorithme d’authentification de message et un algorithme de chiffrement symétrique ou en bloc – bien que cela ait été affiné dans TLS 1.3.

Lorsqu’il reçoit la liste des algorithmes de chiffrement pris en charge, le client en choisit un qui lui convient et le communique au serveur. À partir de là, le client génère une clé de session symétrique, la chiffre à l’aide de la clé publique, puis l’envoie au serveur, qui possède la clé privée nécessaire pour déchiffrer la clé de session.

Une fois que les deux parties ont une copie de la clé de session, la communication peut commencer.

C’est ce que l’on appelle le SSL/TLS.

Vous pouvez voir comment tous les concepts que nous avons abordés précédemment interagissent les uns avec les autres pour créer un système sophistiqué mais élégant de sécurisation des connexions internet. Nous utilisons la cryptographie à clé publique pour échanger les clés de session avec lesquelles nous communiquerons en toute sécurité. Les certificats qui attestent de l’identité du serveur ou de l’organisation sont fiables grâce à l’infrastructure que nous avons mise en place entre les différentes autorités de certification, les navigateurs et les programmes racines.

Enfin, la communication s’effectue grâce à un cryptage symétrique à clé privée, qui descend des cryptosystèmes classiques de l’Antiquité.

Il y a beaucoup de pièces en mouvement, mais lorsque vous ralentissez et que vous les comprenez toutes individuellement, il est beaucoup plus facile de voir comment tout cela fonctionne ensemble.

Avant de partir, terminons par quelques mesures relatives à SSL/TLS que vous pouvez prendre après l’installation/configuration afin de tirer le meilleur parti de votre investissement.

Après SSL/TLS – Tirer le meilleur parti de votre mise en œuvre

Il ne suffit pas d’installer un certificat et de configurer correctement votre site web pour qu’il soit sûr. TLS n’est qu’un élément d’une stratégie de cyberdéfense plus large et holistique. Mais il s’agit néanmoins d’un élément important. Examinons quelques mesures que vous pouvez prendre pour vous assurer que vous tirez le meilleur parti de la mise en œuvre.

Désactivez la prise en charge des anciens protocoles par le serveur

Pour revenir à la conversation que nous avons eue plus tôt sur les suites de chiffrement, une partie de la configuration de votre serveur consiste à décider des suites de chiffrement et des versions SSL/TLS à prendre en charge. Il est impératif que vous désactiviez la prise en charge des anciennes versions SSL/TLS ainsi que des algorithmes spécifiques afin d’éviter toute vulnérabilité à plusieurs exploits connus.

SSL 2.0 et SSL 3.0 ont tous deux plus de 20 ans. La meilleure pratique consistait à ne plus les prendre en charge depuis des années, mais à ce jour, environ 7 % des 100 000 premiers sites d’Alexa les autorisent encore. Cette situation est dangereuse car elle vous expose à des attaques de dépouillement et de déclassement de SSL telles que POODLE.

TLS 1.0 et TLS 1.1 sont également en sursis.

Les principales entreprises technologiques, Apple, Microsoft, Google et Mozilla, ont annoncé conjointement cet automne qu’elles ne prendraient plus en charge les protocoles TLS 1.0 et 1.1 au début de l’année 2020.

Ces versions du protocole sont vulnérables à des failles telles que POODLE, FREAK, BEAST et CRIME (ce sont tous des acronymes). TLS 1.2 est disponible depuis dix ans et devrait être la norme. TLS 1.3 a été finalisé l’été dernier et son adoption progresse à un rythme soutenu depuis lors.

En outre, il existe des algorithmes spécifiques qui ne doivent pas être utilisés. DES, par exemple, peut être cassé en quelques heures. RC4 est plus vulnérable qu’on ne le pensait et a déjà été proscrit par les normes de sécurité des données de l’industrie des cartes de paiement. Enfin, compte tenu des exploits récents, il n’est plus conseillé d’utiliser RSA pour l’échange de clés.

Algorithmes/chiffres suggérés :

• Échange de clés : Diffie-Helman à courbe elliptique (ECDH)
• Authentification : Algorithme de signature numérique à courbe elliptique (ECDSA)
• Chiffrement symétrique/en masse : AES 256 en mode compteur de Galois (AES256-GCM)
• Algorithme MAC : SHA-2 (SHA384)

SSL toujours actif

Dans le passé, les sites web ont parfois migré vers HTTPS uniquement les pages web qui collectent des informations, tout en servant le reste du site via HTTP. Il s’agit d’une mauvaise pratique.

Outre le fait que Google marquera ces pages comme “non sécurisées”, vous exposez potentiellement les visiteurs de votre site à des risques en faisant passer leur navigateur d’une page cryptée à une page HTTP.

Vous devriez configurer l’ensemble de votre site web en HTTPS. C’est ce qu’on appelle le SSL toujours actif. Après tout, ce n’est pas comme si vous payiez à la page, votre certificat SSL/TLS peut crypter l’ensemble de votre site. Faites donc en sorte qu’il en soit ainsi.

Mettez en place un enregistrement d’autorisation de l’autorité de certification (CAA)

L’un des risques les plus importants posés par les certificats numériques, en général, est l’émission erronée. Si une personne autre que vous obtient un certificat SSL/TLS pour VOTRE site web, elle peut effectivement se faire passer pour vous et causer toutes sortes de problèmes.

Les enregistrements CAA permettent d’atténuer ce risque en limitant les autorités de certification qui peuvent émettre des certificats numériques pour votre site web. Les autorités de certification sont tenues par le CA/Browser Forum de vérifier les enregistrements CAA avant de délivrer un certificat. Si l’autorité de certification n’a pas l’autorisation de délivrer un certificat pour ce site, elle ne peut pas le faire. Cela serait considéré comme une erreur d’émission et provoquerait la colère de la communauté des navigateurs.

L’ajout d’un enregistrement CAA est relativement facile, il s’agit d’un simple enregistrement DNS qui peut être ajouté via l’interface de la plupart des plateformes d’hébergement. Vous pouvez restreindre les autorités de certification qui peuvent émettre pour votre domaine, ainsi que la possibilité d’émettre des certificats Wildcard pour celui-ci.

Ajoutez votre site web à la liste de préchargement HSTS

HTTP Strict Transport Security, ou HSTS, est un en-tête HTTP qui oblige les navigateurs à n’établir que des connexions HTTPS avec un site donné. Ainsi, même si l’internaute tente d’accéder à la version HTTP de la page, il ne visitera que la version HTTPS. C’est important parce que cela ferme la fenêtre à plusieurs exploits connus, comme les attaques par rétrogradation et le détournement de cookies.

Malheureusement, un petit vecteur d’attaque subsiste avec HSTS, et c’est pourquoi vous devriez ajouter votre site web à la liste de préchargement. En règle générale, lorsqu’un visiteur arrive sur votre site web, son navigateur télécharge l’en-tête HTTP et l’héberge pendant la durée de la politique définie. Mais lors de cette toute première visite, avant que l’en-tête n’ait été reçu, il reste une minuscule ouverture pour un pirate.

La liste d’enregistrement de préchargement HSTS est gérée par Google et une variante de cette liste est utilisée par tous les principaux navigateurs. Ces navigateurs ne savent que se connecter via HTTPS à tout site web figurant sur la liste, même s’ils ne l’ont jamais visité auparavant. Il peut s’écouler une semaine ou deux avant que votre site n’apparaisse sur la liste, car les mises à jour de la liste sont diffusées en même temps que les calendriers de publication des navigateurs.

Vous pouvez vous référer au guide d’implémentation suivant.

Comment implémenter SSL dans Apache Tomcat ?

Comment implémenter un certificat ZeroSSL dans Apache et Nginx ?

Comment implémenter le SSL dans WordPress sur un hébergement partagé, Cloud ?

FAQ SSL/TLS

Qu’est-ce qu’un certificat X.509 ?

X.509 fait référence au type de certificat numérique utilisé avec SSL/TLS et d’autres types de PKI. X.509 est une norme de cryptage à clé publique. Vous verrez parfois des entreprises utiliser le certificat X.509 à la place de “certificat numérique” ou “certificat PKI”

Pourquoi les certificats SSL/TLS expirent-ils ?

Il y a deux raisons à cela.

La première est que l’internet est en perpétuelle évolution : des sites web apparaissent et d’autres disparaissent. Et comme les navigateurs sont très sensibles à la confiance qu’ils accordent à ces certificats, ils veulent être sûrs que les sites web qui les présentent font l’objet de validations régulières. Ce n’est pas si différent de la façon dont vous devez de temps en temps vous enregistrer pour mettre à jour les informations de votre permis de conduire.

L’autre raison est plus technique. Il est plus difficile de multiplier les mises à jour et les modifications techniques lorsque les certificats n’expirent pas avant 3 à 5 ans. En revanche, si les certificats expirent tous les 24 mois, la durée maximale d’obsolescence d’un certificat est de deux ans. En 2017, la validité maximale a été ramenée de trois à deux ans. Elle sera probablement ramenée à 12 mois d’ici peu.

Comment renouveler un certificat SSL/TLS ?

Le renouvellement peut être un peu mal nommé car vous remplacez l’ancien certificat par un nouveau. Le fait de renouveler régulièrement votre certificat vous permet de rester au fait des nouvelles avancées en matière de technologie de cryptage et de vous assurer que vos informations de validation restent à jour. Les autorités de certification ne peuvent réutiliser les informations de validation fournies initialement que pendant un certain temps avant que les exigences de base ne les obligent à les revalider.

Lorsque vous renouvelez votre certificat, vous pouvez soit conserver le même type de certificat que celui que vous aviez auparavant, soit opter pour quelque chose de nouveau, et même changer d’autorité de certification. L’important est de savoir combien de temps il vous reste sur le certificat qui expire : vous pouvez reporter jusqu’à trois mois. Tant que vous renouvelez le certificat avant son expiration, vous pouvez reporter le temps restant et réutiliser toutes les informations de validation qui n’ont pas expiré depuis votre dernière validation. Si vous laissez le certificat expirer, vous repartez de zéro.

Qu’est-ce que l’inspection HTTPS ?

Beaucoup de grandes entreprises disposant de réseaux plus importants souhaitent avoir une visibilité sur leur trafic. À cet égard, HTTPS est une arme à double tranchant. Il protège la vie privée des personnes, mais il peut aussi aider les cybercriminels à se cacher. De nombreuses organisations décryptent leur trafic HTTPS au niveau d’un dispositif périphérique ou d’une boîte intermédiaire, puis l’envoient en clair derrière leur pare-feu ou le recryptent et le renvoient sur son chemin. Lorsque vous ne recryptez pas le trafic, on parle de terminaison SSL. Lorsque vous recryptez le trafic, on parle de pontage SSL.

Qu’est-ce que le délestage SSL ?

Le délestage SSL est une autre pratique d’entreprise. À grande échelle, l’exécution de milliers de handshakes, puis le cryptage et le décryptage de toutes ces données peuvent taxer les ressources d’un réseau. C’est pourquoi beaucoup de grands réseaux déchargent les fonctions SSL sur un autre appareil afin que le serveur d’application puisse se concentrer sur ses tâches principales. C’est ce que l’on appelle parfois l’équilibrage de la charge.

Pourquoi mon autorité de certification m’a-t-elle envoyé un certificat intermédiaire ?

Vous souvenez-vous de la discussion sur les programmes racines ?

Chaque système d’exploitation dispose d’un magasin de racines qu’il utilise pour évaluer la confiance qu’il accorde à l’ICP. Mais les autorités de certification ne délivrent pas de certificats aux utilisateurs finaux à partir de ces racines, par crainte de ce qui se passerait si l’un d’entre eux devait être révoqué. Au lieu de cela, elles créent des racines intermédiaires et émettent des certificats à partir de celles-ci. Le problème est que ces racines intermédiaires ne résident pas dans le magasin de confiance d’un système.

Par conséquent, si le site web ne présente pas le certificat intermédiaire avec le certificat SSL/TLS de la feuille, de nombreux navigateurs ne seront pas en mesure de compléter la chaîne de certificats et émettront un avertissement. Certains navigateurs mettent en cache les certificats intermédiaires, mais la meilleure pratique consiste à installer tous les certificats intermédiaires en même temps que votre certificat feuille.

De quelle documentation ai-je besoin pour un certificat SSL Extended Validation ?

Dans la plupart des cas, l’autorité de certification qui effectue la validation étendue tentera d’abord d’accéder aux informations par le biais de ressources publiques disponibles auprès des “autorités gouvernementales”.

Toutefois, dans certains endroits, cela peut s’avérer impossible. Il existe cependant quelques moyens d’accélérer la validation. Bien que le nombre de contrôles de validation auxquels une lettre d’opinion professionnelle peut satisfaire ait été réduit récemment, le fait de faire signer une lettre d’opinion professionnelle par un avocat ou un comptable en règle peut encore être très utile.

En outre, vous pouvez fournir une attestation d’activité délivrée par l’État ou un document de “preuve de droit” qui donne à votre organisation le droit de faire des affaires sous le nom indiqué. Voici quelques exemples de ces documents

• Statuts de société
• Certificats de formation
• Licences d’exploitation, de fournisseur ou de commerçant
• Documents de charte
• Accords de partenariat
• Enregistrement d’un nom commercial ou d’une dénomination sociale
• Registro Mercantil

Remarques finales

J’espère que cela vous a donné une idée de ce qu’est le SSL/TLS. Si vous souhaitez en savoir plus, je vous recommande de suivre ce cours en ligne.

Cet article a été rédigé par Patrick Nohe, rédacteur en chef de Hashed Out by The SSL Store, un blog couvrant les actualités et les tendances en matière de cybersécurité.