SSL / TLS 101 pour les débutants

Un regard en profondeur sur le cryptage qui sécurise nos connexions Internet


Alors que Netscape a initialement inventé le SSL au milieu des années 90, il n’a pas été obligatoire pour chaque site Web d’installer un certificat SSL / TLS avant l’été 2018, lorsque Google a commencé à marquer les sites non chiffrés “Pas sécurisé.”

Bien que Google – avec son moteur de recherche, son navigateur Chrome et son système d’exploitation Android – puisse redéfinir Internet de manière unilatérale, il n’était pas le seul à remplir ce mandat. Apple, Microsoft, Mozilla et les autres principaux acteurs de l’industrie de la technologie ont tous pris une décision concertée d’exiger des certificats SSL / TLS et 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 texte clair et facilement lisibles par un tiers.

Le seul inconvénient de cette récente poussée pour le chiffrement universel est qu’elle a forcé un afflux de nouveaux clients dans un marché inconnu, qui ne fait pas grand-chose pour se rendre moins déroutant pour le site Web moyen ou le propriétaire d’entreprise.

Cet article servira de guide complet pour tout ce qui concerne SSL / TLS, nous allons jeter les bases en passant en revue les concepts de base comme le chiffrement, HTTPS et la nature des connexions Internet.

J’espère qu’à la fin, vous vous sentirez confiant dans la sélection, l’achat et la mise en œuvre d’un certificat TLS, et rappelez-vous si vous avez des questions que vous pouvez les laisser dans les commentaires ci-dessous.

Éléments fondamentaux

Commençons par discuter du concept qui réside au cœur de tout cela: le chiffrement.

Le chiffrement, dans son itération la plus simple, n’est guère plus que le brouillage des données – en utilisant un chiffre ou une clé prédéterminé – de sorte qu’il est rendu illisible par quiconque, sauf une autre partie avec 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 utilisé. Dans le cryptage à clé privée, les deux parties doivent posséder ou au moins échanger une clé privée qui peut être utilisée pour crypter et décrypter des informations.

Au début, la plupart des chiffres qui sous-tendent ces cryptosystèmes étaient primitifs, s’appuyant sur des substitutions simples ou remplaçant des mots courants par des caractères. Mais au fil du temps, les chiffres sont devenus plus influencés par les mathématiques et ont gagné en complexité.

Par exemple, au milieu des années 1600 en France, le cryptographe du roi Louis XIV a créé un chiffrement si bien conçu qu’il n’a été brisé que 250 ans plus tard et seulement partiellement. À ce jour, il existe des archives de centaines d’années dans les archives françaises qui ne seront peut-être jamais déchiffrées.

Mais alors que le chiffrement a toujours été un moyen d’être secret ou clandestin, l’avènement d’Internet a rendu le concept plus courant. Internet est omniprésent et il gère une gamme de fonctions essentielles. Chaque jour, des milliards de personnes l’utilisent pour accéder à des informations sensibles et les envoyer, gérer leurs finances, faire des transactions avec des entreprises – vous l’appelez.

Le problème est qu’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 pour la première fois des protocoles de mise en réseau, Internet n’était considéré que comme un mécanisme d’échange gratuit d’informations entre le gouvernement et les établissements universitaires. À ce moment-là, l’activité commerciale était illégale en ligne. Le commerce électronique n’était pas encore un mot qui avait même été inventé. Et le site Web était plus une notion géographique.

Ainsi, lorsque HTTP ou le protocole de transfert hypertexte ont été introduits pour la première fois en 1991, le fait que les connexions qu’il formait échangeait des données en texte clair n’était pas un problème disqualifiant.

Les choses sont bien différentes aujourd’hui. Les informations échangées en ligne ne sont pas des recherches académiques ou des informations librement disponibles, ce sont des informations personnellement identifiables et des données sensibles qui peuvent coûter de l’argent aux gens ou même, dans certaines régions, leur vie. Cela a nécessité une approche plus sûre.

La réponse était le cryptage.

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

Un problème qui a historiquement affligé même les meilleurs cryptosystèmes continue de persister à ce jour.

Ce dont nous avons discuté plus tôt, et ce qui a toujours été la norme pour le cryptage, c’est le cryptage à clé privée. Ceci est également appelé cryptage symétrique ou cryptage bidirectionnel, les clés privées gérant à la fois les fonctions de cryptage et de décryptage nécessaires pour communiquer..

Pour que le chiffrement de la 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 cryptosystème 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 entier à part – une nouvelle forme de cryptage a été conceptualisée et mise en œuvre: le cryptage à clé publique.

Alors que le cryptage à clé privée est une fonction bidirectionnelle, symétrique, la clé privée pouvant à la fois crypter et décrypter des données, le cryptage à clé publique est asymétrique; une manière. Plutôt qu’une seule clé privée, il existe une paire de clés publique-privée. La clé publique gère le chiffrement et est, comme son nom l’indique, accessible au public tandis que la clé privée, qui gère le déchiffrement, est gardée secrète par son propriétaire. En utilisant la clé publique, on peut crypter un morceau de données et l’envoyer au propriétaire de la clé, où seuls ils pourront le décrypter.

Génial, mais en quoi est-ce utile?

Eh bien, le cryptage unidirectionnel n’est pas idéal pour crypter des connexions Internet, il est plutôt difficile de communiquer lorsqu’une partie ne peut que crypter et 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 échangez-vous les clés? Surtout en ligne?

Cryptage à clé publique.

Et c’est là l’essence même de SSL / TLS: l’échange sécurisé de clés.

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

À l’aide de SSL / TLS, vous pouvez authentifier le serveur ou l’organisation avec lequel vous vous connectez et vous assurer que vous échangez en toute sécurité les clés privées que vous utiliserez pour crypter vos communications avec la partie visée..

Malheureusement, SSL / TLS et PKI ont beaucoup de terminologie et de pièces mobiles qui peuvent facilement confondre les gens, mais ceux qui croient que lorsque vous supprimez tous les mathématiques et le jargon technique, ce n’est qu’une élégante solution technologique moderne à un âge problème ancien: échange de clés.

Passons maintenant en revue quelques termes clés

Avant d’aller plus loin, examinons quelques autres termes clés. Nous avons déjà introduit HTTP, le protocole de transfert hypertexte, qui est l’épine dorsale d’Internet depuis des décennies. Mais comme nous en avons discuté, Internet est devenu quelque chose de très différent de ce qu’il était lorsque HTTP a été publié pour la première fois en 1991.

Un protocole plus sécurisé était nécessaire. Ainsi, HTTPS.

HTTPS, parfois appelé HTTP sur TLS, utilise le chiffrement pour rendre les données échangées pendant une connexion illisibles à quiconque, sauf à la partie visée. Ceci est particulièrement important lorsque vous considérez la nature d’une connexion Internet moderne.

Alors qu’au début d’Internet, la connexion était raisonnablement directe, les connexions sont désormais acheminées via des dizaines d’appareils en route vers leur destination finale. Si vous avez déjà voulu une démonstration pratique de cela, ouvrez l’invite de commande sur votre système d’exploitation et entrez la commande “tracert geekflare.com”.

Ce que vous verrez est le chemin parcouru par votre connexion en route vers sa destination. Jusqu’à 30 sauts. Cela signifie que vos données transitent par chacun de ces appareils avant d’atteindre le site Web ou l’application auquel vous vous connectez. Et si quelqu’un a un renifleur de paquets ou un écouteur installé sur l’un de ces appareils, il peut voler toutes les données transmises et même manipuler la connexion dans certains cas.

C’est ce qu’on appelle une attaque d’homme au milieu (MITM).

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

Il y a beaucoup plus de surface à couvrir avec des connexions Internet modernes que la grande majorité des gens ne le pensent, c’est pourquoi il est essentiel d’avoir les données cryptées pendant la transmission. Vous n’avez aucune idée de qui pourrait écouter, ou à quel point il est facile de le faire.

Une connexion HTTP est établie via le port 80. Pour nos besoins, vous pouvez considérer les ports comme des constructions qui indiquent un service ou un protocole réseau. Un site Web standard servi via HTTP utilise le port 80. HTTPS utilise généralement le port 443. Lorsqu’un site Web installe un certificat, il peut rediriger ses pages HTTP vers celles HTTPS, et les navigateurs des utilisateurs tenteront de se connecter en toute sécurité via le port 443, en attendant l’authentification.

Malheureusement, les termes SSL / TLS, HTTPS, PKI et cryptage sont très souvent utilisés, parfois même interchangeables, donc pour dissiper toute confusion persistante, voici un petit guide:

  • SSL – Secure Sockets Layer, le protocole de cryptage original utilisé avec HTTPS
  • TLS – Transport Layer Security, le protocole de cryptage le plus récent qui a remplacé SSL
  • HTTPS – La version sécurisée de HTTP, utilisée pour créer des connexions avec des sites Web
  • PKI – Infrastructure à clé publique, se réfère à l’ensemble du modèle de confiance qui facilite le chiffrement à clé publique

SSL / TLS fonctionne conjointement pour activer les connexions HTTPS. Et l’ICP fait référence à tout lorsque vous effectuez un zoom arrière.

Je l’ai? Ne vous inquiétez pas, vous.

Construire une infrastructure à clé publique

Maintenant que nous avons jeté les bases, regardons en arrière et examinons l’architecture utilisé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 avec lequel le site le présente. Nous allons voir ce qui se passe après que l’authentification a eu lieu dans quelques sections, mais nous allons commencer par discuter du modèle de confiance qui rend tout cela possible.

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

Pour y répondre, nous devrons discuter de l’ICP et des différents éléments qui la font fonctionner. Nous allons commencer 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, à la fois gratuites et commerciales, qui peuvent émettre des certificats de confiance.

Ils doivent tous respecter un ensemble de normes qui a été débattu et légiféré par le biais du CA / Browser Forum, qui agit en tant qu’organisme de réglementation pour l’industrie TLS. Ces normes décrivent des choses comme:

  • Garanties techniques qui doivent être en place
  • Meilleures pratiques pour effectuer la validation
  • Meilleures pratiques d’émission
  • Procédures de révocation et délais
  • Exigences de journalisation des certificats

Ces directives ont été définies 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 accéder à Internet sans son navigateur Web. En tant que tel, c’est le navigateur qui recevra et validera le certificat TLS numérique, puis échangera des clés avec le serveur. Donc, étant donné leur rôle primordial, ils ont 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 de protéger leurs utilisateurs. Donc, si un navigateur fait confiance à un certificat numérique – qui peut potentiellement être utilisé à mauvais escient au détriment de l’utilisateur – il a besoin de certaines assurances que la personne qui a émis ce certificat a fait preuve de diligence raisonnable.

C’est le rôle et la responsabilité des autorités de certification. Et les navigateurs ne supportent pas non plus les erreurs. Il y a un cimetière littéral d’anciennes autorités de certification qui se sont heurtées aux navigateurs et ont été mises au pâturage.

Lorsqu’une autorité de certification a démontré sa conformité aux exigences de base du Forum CAB et a passé tous les audits et revues nécessaires, elle peut demander aux différents programmes racine de faire 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 qui résident sur le système d’un utilisateur. Encore une fois, ces racines sont incroyablement précieuses et incroyablement dangereuses – elles peuvent, après tout, émettre des certificats numériques de confiance – la sécurité est donc de la plus haute importance.

C’est pourquoi les autorités de certification ne délivrent presque jamais directement à partir des certificats d’autorité de certification racine eux-mêmes. Au lieu de cela, ils créent des certificats racine intermédiaires et les utilisent pour émettre des certificats d’utilisateur final ou de feuille. Ils peuvent également transmettre ces racines aux sous-autorités de certification, qui sont des autorités de certification qui n’ont pas leurs racines dédiées mais peuvent toujours émettre des certificats de signature croisée de leurs intermédiaires.

Alors, mettons tout cela ensemble. Lorsqu’un site Web souhaite qu’un certificat TLS soit émis, 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 inclure sur le certificat. Comme vous le verrez un peu, la quantité d’informations peut varier des détails commerciaux complets à une simple identité de serveur, mais une fois la CSR terminée, elle est envoyée à l’autorité de certification pour émission..

Avant de délivrer le certificat, l’autorité de certification devra effectuer la vérification diligente mandatée par l’AC / le forum du navigateur et valider l’exactitude des informations contenues dans le CSR. Une fois cela vérifié, il signe le certificat avec sa clé privée et le renvoie au propriétaire du site Web pour l’installation.

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 navigateur de l’utilisateur avec le certificat. Le navigateur va regarder la signature numérique sur le certificat, celle qui a été faite par l’autorité de certification de confiance, 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 monter d’un lien sur la chaîne. Ensuite, il vérifiera la signature numérique sur le 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 à l’une des racines approuvées dans son magasin racine, ou jusqu’à ce que la chaîne se termine sans atteindre une racine, auquel cas une erreur de navigateur apparaîtra et la connexion échouera.

C’est pourquoi vous ne pouvez pas émettre et auto-signer vos certificats.

Les navigateurs ne font confiance qu’aux certificats SSL / TLS qu’ils peuvent chaîner vers 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 maintenir leur fiabilité, et même dans ce cas, les navigateurs répugnent à leur faire confiance.

Les navigateurs n’ont aucune assurance sur les certificats auto-signés, c’est pourquoi ils ne doivent être déployés que sur des réseaux internes, derrière des pare-feu et dans des environnements de test.

Types de certificats et fonctionnalités SSL / TLS

Avant de regarder SSL / TLS en mouvement, parlons des certificats et des différentes itérations disponibles. Les certificats TLS facilitent le protocole TLS et aident à dicter les conditions des connexions HTTPS chiffrées établies par un site Web..

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

Et lorsque vous décomposez les différentes itérations des certificats SSL / TLS, c’est une chose pertinente à garder à l’esprit. Les certificats varient en fonction de la fonctionnalité et du niveau de validation. Ou pour le dire autrement, ils varient en fonction de:

  • Combien d’identités affirmer
  • Sur quels points de terminaison pour affirmer l’identité

Répondre à ces deux questions vous donnera une indication assez claire du type de certificat dont vous avez besoin.

Combien d’identités à affirmer

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

  • Certificats SSL de validation de domaine – Affirmer l’identité du serveur
  • Certificats SSL de validation d’organisation – Affirmer une identité d’organisation partielle
  • Certificats SSL à validation étendue – Assurer l’identité complète de l’organisation

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

L’inconvénient est que les certificats SSL DV affirment une identité minimale. Et étant donné que près de la moitié de tous les sites Web d’hameçonnage ont maintenant un certificat SSL DV installé sur eux, ils ne vous achètent pas nécessairement beaucoup en termes de confiance.

Les certificats SSL de validation d’organisation sont le type d’origine de certificat SSL / TLS. Ils sont également le seul type de certificat SSL qui peut sécuriser une adresse IP suite à une décision prise en 2016 par le CAB Forum d’invalider tous les certificats SSL intranet. La validation de l’organisation nécessite un contrôle technique léger et peut généralement être délivrée en un jour ou deux, parfois plus rapidement. Les certificats SSL OV revendiquent certaines informations organisationnelles, mais un internaute devra cliquer sur l’icône du cadenas et le rechercher. De nos jours, vous voyez beaucoup de certificats SSL OV déployés sur les grands réseaux d’entreprise et d’entreprise, pour les connexions établies derrière les pare-feu par exemple.

Parce que ni les certificats SSL DV ni OV n’affirment une identité suffisante pour satisfaire la plupart des navigateurs, ils reçoivent un traitement neutre.

Les certificats SSL à validation étendue sont de loin les plus controversés, car certains membres de la communauté technique estiment qu’il faut en faire plus pour renforcer la validation dont ils dépendent. Mais, EV SSL affirme une identité maximale. Pour terminer la validation étendue, l’autorité de certification soumet l’organisation à un processus de vérification rigoureux qui peut prendre jusqu’à une semaine dans certains cas.

Mais l’avantage est indéniable: car il affirme une identité suffisante, un site Web avec un certificat SSL EV reçoit un traitement de navigateur unique, y compris le fait que son nom soit affiché dans la barre d’adresse du navigateur.

Il n’y a pas d’autre moyen d’accomplir cela, et vous ne pouvez pas en simuler un – la barre d’adresse EV est l’un des indicateurs visuels les plus puissants que nous ayons aujourd’hui.

Sur quels points de terminaison pour affirmer l’identité

L’autre façon dont les certificats SSL / TLS varient concerne la fonctionnalité. Les sites Web ont beaucoup évolué depuis les débuts d’Internet, diverses entreprises déployant des sites de différentes manières. Certains ont plusieurs domaines pour différents secteurs verticaux de l’entreprise; d’autres utilisent des sous-domaines pour de multiples fonctions et applications Web. Certains utilisent les deux.

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

Domaine unique

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

Multi-domaine

Certificats multi-domaines ou des certificats de communication unifiée (dans le cas des serveurs Microsoft Exchange et Office Communications) existent également pour donner aux organisations la possibilité de chiffrer plusieurs domaines avec un seul certificat. Cela peut être une option intéressante car elle permet d’économiser de l’argent et rend la gestion des certificats (expirations / renouvellements) beaucoup plus simple..

Les certificats multi-domaines et UCC utilisent SAN, le champ Subject Alternative Name dans le 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. Et la plupart des certificats multi-domaines sont livrés avec 2 à 4 SAN gratuits, le reste étant disponible à l’achat selon les besoins.

Certificats SSL génériques

Certificats SSL génériques sont un type de certificat extrêmement utile car ils peuvent chiffrer 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 tous les crypter avec le même certificat Wildcard en utilisant un astérisque dans le champ FQDN de votre CSR: * .website.com

Désormais, tous les sous-domaines, même ceux que vous n’avez pas encore ajoutés, peuvent être sécurisés avec ce certificat.

Il existe cependant deux inconvénients aux certificats génériques. La première est qu’en utilisant la même clé publique sur certains points de terminaison, vous êtes plus vulnérable à certains exploits comme les attaques Bleichenbacher.

L’autre est qu’il n’y a 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 que la barre d’adresse EV sur vos sous-domaines, vous devrez les chiffrer individuellement ou utiliser un certificat EV multi-domaine.

Caractère générique multi-domaine

Un ajout relativement nouveau à l’écosystème SSL / TLS, le joker multi-domaine peut chiffrer jusqu’à 250 domaines différents, mais il peut également utiliser un astérisque dans les champs SAN, ce qui vous permet également de chiffrer 250 domaines différents ET tous leurs accompagnants en premier sous-domaines de niveau.

Un autre cas d’utilisation pour le caractère générique multi-domaine est un caractère générique à plusieurs niveaux, où il peut chiffrer des sous-domaines à plusieurs niveaux de l’URL (un caractère générique standard ne peut les chiffrer qu’à un seul niveau).

En raison de la fonctionnalité des caractères génériques, les caractères génériques multi-domaines ne sont pas disponibles dans EV,.

SSL / TLS en mouvement

Maintenant que nous avons couvert tous les concepts importants qui composent SSL / TLS et PKI, mettons tout cela ensemble et voyons-le en mouvement.

Validation et délivrance

Commençons au début par un site Web achetant un certificat SSL / TLS auprès d’une autorité de certification ou d’un revendeur. Après l’achat, le contact organisationnel qui gère l’acquisition du certificat crée une demande de signature de certificat sur le serveur sur lequel le certificat sera installé (le serveur qui héberge le site Web).

Avec le CSR, le serveur générera également une paire de clés publique / privée et enregistrera la clé privée localement. Lorsque l’autorité de certification reçoit la CSR et la clé publique, elle effectue les étapes de validation requises pour garantir l’exactitude des informations contenues dans le certificat. Généralement, pour les certificats d’authentification d’entreprise (pas DV), cela implique 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 Web peut désormais prendre le certificat SSL / TLS nouvellement émis, l’installer sur son serveur et configurer le site Web pour établir des connexions HTTPS sur le port 443 (en utilisant des redirections 301 pour envoyer du trafic depuis les pages HTTP préexistantes vers leurs nouveaux homologues HTTPS).

Authentification et prise de contact SSL

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

À son arrivée sur le site Web, le serveur présentera le certificat SSL / TLS au navigateur de l’utilisateur. Le navigateur de l’utilisateur effectue ensuite 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 de certificats (CRL). À condition que la chaîne renvoie à l’une des racines du magasin de clés de confiance du système et qu’elle soit valide, le navigateur fera confiance au certificat.

Maintenant c’est le moment de la poignée de main.

La négociation SSL / TLS est la série d’étapes où 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 chiffres qui seront utilisés pour la connexion. Le certificat SSL / TLS fournit une liste de suites de chiffrement prises en charge par le serveur. Généralement, 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 masse, bien que cela ait été affiné dans TLS 1.3.

Après avoir reçu la liste des chiffres pris en charge, le client en choisira un agréable et le communiquera au serveur. À partir de là, le client générera une clé de session symétrique, la chiffrera à l’aide de la clé publique, puis l’enverra 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.

Et c’est SSL / TLS.

Vous pouvez voir comment tous les concepts que nous avons rencontrés précédemment interagissent les uns avec les autres pour créer un système sophistiqué mais élégant pour sécuriser les 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 affirment l’identité du serveur ou de l’organisation peuvent être approuvés en raison de l’infrastructure que nous avons en place entre les différentes autorités de certification, les navigateurs et les programmes racine.

Et la communication se produit à la suite d’un cryptage symétrique à clé privée qui découle des cryptosystèmes classiques de l’Antiquité.

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

Avant de partir, terminons avec quelques mouvements liés à SSL / TLS que vous pouvez effectuer après l’installation / la configuration pour tirer le meilleur parti de votre investissement..

Après SSL / TLS – Tirer le meilleur parti de votre implémentation

Le simple fait d’installer un certificat et de configurer correctement votre site Web ne signifie pas que votre site Web est sûr. TLS n’est qu’un élément d’une stratégie de cyberdéfense plus globale et globale. Mais un élément important, néanmoins. Voyons quelques-unes des choses que vous pouvez faire pour vous assurer de tirer le meilleur parti de la mise en œuvre.

Désactiver la prise en charge du serveur pour les anciens protocoles

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

SSL 2.0 et SSL 3.0 ont tous deux plus de 20 ans. La meilleure pratique était de déprécier leur support il y a des années, mais à ce jour, environ 7% des 100 000 premiers Alexa le permettent. Ceci est dangereux car il vous expose à des attaques de suppression de SSL et de rétrogradation comme POODLE.

TLS 1.0 et TLS 1.1 sont également en temps emprunté.

Les principales sociétés technologiques, Apple, Microsoft, Google et Mozilla, ont annoncé conjointement cet automne qu’elles abandonneraient la prise en charge de TLS 1.0 et 1.1 début 2020.

Les versions de protocole sont sensibles à des vulnérabilités comme POODLE, FREAK, BEAST et CRIME (ce sont tous des acronymes). TLS 1.2 est sorti 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.

De plus, il existe des algorithmes spécifiques qui ne doivent pas non plus être utilisés. Le DES, par exemple, peut être rompu en quelques heures. RC4 est plus vulnérable qu’on ne le croyait et a déjà été interdit par les normes de sécurité des données de l’industrie des cartes de paiement. Et enfin, étant donné les nouvelles d’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: courbe elliptique Diffie-Helman (ECDH)
  • Authentification: algorithme de signature numérique à courbe elliptique (ECDSA)
  • Cryptage symétrique / en masse: AES 256 en mode compteur Galois (AES256-GCM)
  • Algorithme MAC: SHA-2 (SHA384)

SSL permanent

Dans le passé, les sites Web ont parfois migré uniquement les pages Web qui collectent des informations vers HTTPS, tout en desservant le reste du site via HTTP. C’est une mauvaise pratique.

Outre le fait que Google marquera ces pages comme “non sécurisées”, vous exposez également les visiteurs de votre site à des risques en faisant basculer leur navigateur entre les pages cryptées et les pages HTTP..

Vous devez configurer l’ensemble de votre site Web pour HTTPS. Ceci est appelé SSL Always-on. Après tout, ce n’est pas comme si vous payiez à la page, votre certificat SSL / TLS peut crypter l’intégralité de votre site. Alors fais en sorte.

Configurer 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 partie autre que vous obtient un certificat SSL / TLS pour VOTRE site Web, elle peut effectivement vous usurper l’identité et provoquer toutes sortes de problèmes.

Les enregistrements CAA aident à 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 d’émettre pour ce site, elle ne peut pas. Cela serait considéré comme une mauvaise émission et susciterait 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 plates-formes d’hébergement. Vous pouvez restreindre les autorités de certification qui peuvent émettre pour votre domaine, ainsi que si des certificats génériques peuvent également être émis 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 uniquement à établir des connexions HTTPS avec un site donné. De cette façon, même si l’internaute essaie d’accéder à la version HTTP de la page, il finira par visiter la version HTTPS. C’est important car cela ferme la fenêtre sur plusieurs exploits connus, comme les attaques de déclassement et le piratage de cookies.

Malheureusement, un minuscule vecteur d’attaque reste avec HSTS, c’est pourquoi vous devez 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, puis le respecte pendant aussi longtemps que la politique a été définie pour durer. Mais lors de cette toute première visite, avant la réception de l’en-tête, il y a encore une petite ouverture pour un attaquant.

La liste d’enregistrement de préchargement HSTS est gérée par Google et certaines variantes de celle-ci sont utilisées par tous les principaux navigateurs. Ces navigateurs savent uniquement se connecter via HTTPS à tout site Web figurant sur la liste, même s’il n’y a jamais été 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 repoussées en même temps que les calendriers de publication des navigateurs..

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 chiffrement à clé publique. Parfois, vous verrez des entreprises utiliser un certificat X.509 à la place d’un «certificat numérique» ou d’un «certificat PKI».

Pourquoi les certificats SSL / TLS expirent?

Il y a deux raisons à cela.

La première est qu’Internet change continuellement, les sites Web arrivent et les sites Web disparaissent. Et étant donné à quel point les navigateurs sont sensibles à la confiance accordée à ces certificats en premier lieu, ils veulent savoir que les sites Web présentant les certificats sont régulièrement validés. Ce n’est pas si différent de la façon dont vous devez parfois vous enregistrer pour mettre à jour les informations sur 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. Alors que si les certificats expirent tous les 24 mois, la durée la plus longue de tout certificat pourrait être périmée est de deux ans. En 2017, la validité maximale est passée de trois ans à deux. Il sera probablement raccourci à 12 mois sous peu.

Comment renouveler un certificat SSL / TLS?

Le renouvellement peut être un peu inapproprié car vous remplacez l’ancien certificat par un nouveau. Faire cela régulièrement vous permet de rester à jour avec les nouvelles avancées de la technologie de cryptage et garantit que vos informations de validation restent à jour. Les autorités de certification peuvent uniquement réutiliser les informations de validation qui ont été initialement fournies pendant si longtemps avant que les exigences de base ne les obligent à les revalider..

Lorsque vous renouvelez, vous pouvez soit conserver le même type de certificat que vous aviez auparavant, soit choisir quelque chose de nouveau, vous pouvez même changer d’autorité de certification. L’important est de savoir combien de temps il vous reste sur le certificat expirant – vous pouvez reporter jusqu’à trois mois. Tant que vous renouvelez avant l’expiration du certificat, 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 le laissez expirer, vous partez de zéro.

Qu’est-ce que l’inspection HTTPS?

Beaucoup de grandes entreprises avec des réseaux plus importants aiment avoir une visibilité sur leur trafic. À cet égard, HTTPS est une épée à double tranchant. Il protège la vie privée des gens, mais il peut également aider les cybercriminels à se cacher également. De nombreuses organisations décrypteront leur trafic HTTPS sur un périphérique de périphérie ou un boîtier de médiation, puis l’enverront en texte clair derrière leur pare-feu ou le rechiffreront et l’enverront sur son chemin. Lorsque vous ne rechiffrez pas le trafic, il s’agit de la terminaison SSL. Lorsque vous rechiffrez, cela s’appelle un pont SSL.

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

Le déchargement SSL est une autre pratique d’entreprise. À grande échelle, effectuer des milliers de poignées de main, puis chiffrer et déchiffrer toutes ces données peuvent taxer les ressources d’un réseau. Ainsi, de nombreux réseaux plus importants déchargeront les fonctions SSL sur un autre appareil afin que le serveur d’applications puisse se concentrer sur ses tâches principales. Ceci est parfois appelé équilibrage de charge.

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

Rappelez-vous plus tôt lorsque nous avons discuté des programmes racine?

Very OS a un magasin racine qu’il utilise pour faire des jugements de confiance PKI. Mais les autorités de certification n’émettent pas de certificats d’utilisateur final à partir de ces racines par crainte de ce qui se passerait si un jour devait être révoqué. Au lieu de cela, ils font tourner des racines intermédiaires et en sortent. Le problème est que ces racines intermédiaires ne résident pas dans le magasin de confiance d’un système.

Ainsi, si le site Web ne présente pas le certificat intermédiaire avec le certificat SSL / TLS feuille, de nombreux navigateurs ne pourront pas compléter la chaîne de certificats et émet un avertissement. Certains navigateurs mettent en cache des certificats intermédiaires, mais il est toujours considéré comme la meilleure pratique d’installer des intermédiaires avec votre certificat feuille.

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

Dans la plupart des cas, l’autorité de certification effectuant la validation étendue tentera d’abord d’accéder aux informations par le biais de ressources «d’autorité gouvernementale» accessibles au public.

Cependant, dans certains endroits, cela pourrait ne pas être possible. Il y a quelques choses qui peuvent aider à accélérer la validation. Alors que le nombre de vérifications de validation qu’une lettre d’opinion professionnelle peut satisfaire a été réduit récemment, le fait d’avoir un avocat ou un comptable en règle peut vous aider considérablement.

De plus, vous pouvez fournir un justificatif d’identité délivré par le gouvernement ou un document «Preuve de droit» qui donne à votre organisation le droit de faire des affaires sous le nom indiqué. Voici quelques exemples de ces documents:

  • Statuts constitutifs
  • Certificats de formation
  • Licences commerciales / fournisseurs / commerçants
  • Documents de charte
  • Accords de partenariat
  • Enregistrement du nom commercial ou du nom présumé
  • Registro Mercantil

En clôture

J’espère que cela vous donne une idée de SSL / TLS. Si vous souhaitez en savoir plus, je recommanderais suivre ce cours en ligne.

Cet article a été rédigé par Patrick Nohe, rédacteur en chef de Hashed Out par la boutique SSL, un blog couvrant les actualités et les tendances de la cybersécurité.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map