Un examen approfondi du cryptage qui sécurise nos connexions Internet
Alors que Netscape a inventé SSL au milieu des années 90, il n'est devenu obligatoire pour tous les sites Web d'installer un certificat SSL / TLS qu'à l'été 2018, lorsque Google a commencé à marquer les sites non chiffrés.Pas sécurisé. »
Si Google - avec son moteur de recherche, son navigateur Chrome et son système d'exploitation Android - peut redéfinir unilatéralement Internet, il n'a pas été seul sur ce mandat. Apple, Microsoft, Mozilla et les autres acteurs majeurs de l'industrie technologique ont tous pris la décision concertée de rendre obligatoire les 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 en faveur du cryptage universel est qu'elle a forcé un afflux de nouveaux clients sur un marché inconnu, un marché qui fait très peu pour se rendre moins déroutant pour le site Web ou le propriétaire d'entreprise moyen.
Cet article servira de guide complet à tout ce qui concerne SSL / TLS, nous jetterons les bases en passant en revue les concepts de base tels que le cryptage, HTTPS et la nature des connexions Internet.
J'espère qu'à la fin, vous vous sentirez en confiance pour sélectionner, achat, et implémenter un certificat TLS, et rappelez-vous si vous avez des questions que vous pouvez les laisser dans les commentaires ci-dessous.
Foundational Elements
Commençons par discuter du concept qui est au cœur de tout cela: le cryptage.
Le chiffrement, dans son itération la plus simple, n'est guère plus que le brouillage des données - en utilisant un chiffrement ou une clé prédéterminée - afin qu'elles soient rendues illisibles 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 couramment utilisé. Dans le cryptage par clé privée, les deux parties doivent posséder ou au moins échanger une clé privée qui peut être utilisée à la fois pour crypter et décrypter les informations.
Au début, la plupart des chiffrements sous-tendant ces cryptosystèmes étaient primitifs, reposant sur de simples substitutions ou remplaçant des mots communs 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é cassé que 250 ans plus tard et seulement alors partiellement. À ce jour, il y a des centaines d'années de documents dans les archives françaises qui pourraient ne jamais être déchiffrés.
Mais alors qu'historiquement, le cryptage a é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 critiques. Chaque jour, des milliards de personnes l'utilisent pour accéder et envoyer des informations sensibles, gérer leurs finances, effectuer 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 de libre échange d'informations entre le gouvernement et les institutions universitaires. À ce moment-là, l'activité commerciale était illégale en ligne. Le commerce électronique n'était pas encore un mot encore inventé. Et le site Web était plus géographique notion.
Ainsi, lorsque HTTP ou le protocole de transfert hypertexte a été introduit 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 universitaires ou des informations disponibles gratuitement, 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 exigeait 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 affecté même les meilleurs systèmes de cryptographie continue de persister à ce jour.
Ce dont nous avons discuté précédemment, et ce qui a traditionnellement été la norme pour le cryptage, est le cryptage à clé privée. Ceci est également appelé cryptage symétrique ou cryptage bidirectionnel, avec des clés privées gérant à la fois les fonctions de cryptage et de décryptage nécessaires pour communiquer.
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. Dans tous les cas, 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 place: le cryptage à clé publique.
Alors que le chiffrement à clé privée est une fonction bidirectionnelle, symétrique, avec la clé privée capable à la fois de chiffrer et de déchiffrer les données, le chiffrement à 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 une donnée et l'envoyer au propriétaire de la clé, où lui seul pourra la décrypter.
Génial, mais en quoi est-ce utile?
Eh bien, le cryptage unidirectionnel n'est pas idéal pour crypter les connexions Internet, il est assez 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 à clé privée symétrique.
Mais comment échangez-vous les clés? Surtout en ligne?
Chiffrement à clé publique.
Et cela, distillé dans son essence même, c'est ce qu'est SSL / TLS: un échange de clés sécurisé.
C'est là que nous lierons 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é à 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 ê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 la partie prévue.
Malheureusement, SSL / TLS et PKI ont beaucoup de terminologie et de pièces mobiles qui peuvent facilement dérouter les gens, mais ceux-ci démentent le fait que lorsque vous supprimez tous les mathématiques et le jargon technique, il ne s'agit que d'une solution technologique moderne et élégante à une époque. - ancien problème: é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à 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 a évolué pour devenir 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 cryptage pour rendre les données échangées pendant une connexion illisibles à quiconque sauf à la partie prévue. Ceci est particulièrement important lorsque vous considérez la nature d'une connexion Internet moderne.
Alors qu'au début de l'Internet, une 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 toujours 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 de type «man-in-the-middle» (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 les connexions Internet modernes que la grande majorité des gens ne le pensent, c'est pourquoi il est essentiel de chiffrer les données pendant la transmission. Vous n'avez aucune idée de qui pourrait écouter, ni à quel point c'est facile à 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 des pages 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 tous beaucoup mélangés, parfois même utilisés de manière interchangeable, alors pour dissiper toute confusion persistante, voici un guide rapide:
- 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, fait référence à l'ensemble du modèle de confiance qui facilite le chiffrement à clé publique
SSL / TLS fonctionne conjointement pour activer les connexions HTTPS. Et PKI fait référence à l'ensemble lorsque vous effectuez un zoom arrière.
Je l'ai? Ne vous inquiétez pas, vous le ferez.
Building a Public Key Infrastructure
Maintenant que nous avons jeté les bases, faisons un zoom arrière et examinons 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 allons donc commencer par poser la question: comment mon ordinateur sait-il s'il doit 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 de CA, les deux lunette de vue Haute Gamme gratuite et commercial, qui peut émettre des certificats de confiance.
Ils doivent tous respecter un ensemble de normes qui ont été débattues et légiférées 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:
- Sauvegardes techniques qui doivent être en place
- Meilleures pratiques pour effectuer la validation
- Bonnes pratiques d'émission
- Procédures et délais de révocation
- 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 les clés avec le serveur. Ainsi, é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. Ne faire confiance à rien. C'est la meilleure façon de protéger leurs utilisateurs. Donc, si un navigateur veut faire 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 celui 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 tolèrent pas non plus les erreurs. Il y a un cimetière littéral d'anciens CA qui se sont heurtés aux navigateurs et ont été mis au pâturage.
Lorsqu'une autorité de certification a démontré sa conformité avec les exigences de base du forum CAB et a passé 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 de l'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 émettre des certificats numériques de confiance, après tout - donc la sécurité est la plus grande préoccupation.
C'est pourquoi les autorités de certification n'émettent presque jamais directement à partir des certificats de l'autorité de certification racine eux-mêmes. Au lieu de cela, ils lancent des certificats racine intermédiaires et les utilisent pour émettre des certificats d'utilisateur final ou de feuille. Ils peuvent également confier ces racines à des sous-autorités de certification, qui sont des autorités de certification qui n'ont pas leurs racines dédiées, mais qui peuvent toujours émettre des certificats signés croisés à partir de leurs intermédiaires.
Alors, mettons tout cela ensemble. Lorsqu'un site Web souhaite qu'un certificat TLS soit émis, il génère quelque chose appelé 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 dans un instant, la quantité d'informations peut varier des détails complets de l'entreprise à une simple identité de serveur, mais une fois le CSR terminé, il est envoyé à l'autorité de certification pour émission.
Avant d'émettre le certificat, l'AC devra faire sa diligence raisonnable mandatée par l'AC / Forum des navigateurs 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ésentera au navigateur de l'utilisateur 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 du fait 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 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 de confiance de 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 signer vous-même vos certificats.
Les navigateurs ne feront confiance qu'aux certificats SSL / TLS qu'ils peuvent chaîner à 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 hésitent à leur faire confiance.
Les navigateurs n'ont pas de telles garanties 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.
SSL/TLS Certificate Types and Functionality
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 à dicter 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 é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. Revenant à l’idée qu’en son cœur, SSL / TLS et PKI sont toutes des formes exquises d’échange de clés sécurisé, le certificat SSL / TLS permet d’informer le navigateur de la personne à qui il envoie la clé de session, de 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 affirmer son 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 niveaux de validation différents disponibles avec 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 - Confirmer l'identité du serveur
- Certificats SSL de validation d'organisation - Affirmer l'identité partielle de l'organisation
- Certificats SSL Extended Validation - Affirmer 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 réalisée de plusieurs manières différentes, mais dès que c'est le cas, le certificat peut être émis. Vous pouvez également en obtenir gratuitement des versions 30 et 90 jours, ce qui a sans aucun doute ajouté à leur part de marché.
L'inconvénient est que les certificats DV SSL revendiquent une identité minimale. Et étant donné que près de la moitié de tous les sites Web de phishing ont maintenant un certificat DV SSL 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 original de certificat SSL / TLS. C'est également le seul type de certificat SSL capable de sécuriser une adresse IP suite à une décision prise en 2016 par le forum CAB d'invalider tous les certificats SSL intranet. La validation de l'organisation nécessite un contrôle commercial léger et peut généralement être émise en un jour ou deux, parfois plus rapidement. Les certificats SSL OV confirment certaines informations organisationnelles, mais un internaute devra cliquer sur l'icône du cadenas et le rechercher. De nos jours, vous voyez de nombreux certificats SSL OV déployés sur les grandes entreprises et les réseaux d'entreprise, pour les connexions établies derrière des pare-feu par exemple.
Parce que ni les certificats DV ni OV SSL n'affirment une identité suffisante pour satisfaire la plupart des navigateurs, ils reçoivent 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 plus pour renforcer la validation dont ils dépendent. Mais, EV SSL 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 prendre plus d'une semaine dans certains cas.
Mais l'avantage est indéniable: parce qu'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'y parvenir, 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.
What endpoints to assert Identity on
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 forment qu'un seul domaine. La plupart des certificats SSL/TLS modernes sécurisent à la fois le WWW et non WWW versions de ce domaine, mais il est limité à un seul domaine. Tu peux comparez 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 un àtractive option car elle permet d'économiser de l'argent et rend la gestion des certificats (expirations/renouvellements) beaucoup plus simple.
Utilisation des certificats multi-domaines et UCC SAN, le champ Autre nom du sujet 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 seul certificat. Et la plupart des certificats multi-domaines sont livrés avec 2 à 4 SAN gratuits, le reste étant disponible à l'achat si nécessaire.
Wildcard SSL Certificates
Certificats SSL génériques sont un type de certificat extrêmement utile car ils peuvent 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 tels que:
- app.website.com
- portail.site.com
- utilisateur.site.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.
Les certificats Wildcard présentent cependant 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 comme les attaques de 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 voulez la barre d'adresse EV sur vos sous-domaines, vous devrez les crypter individuellement ou utiliser un certificat EV Multi-Domain.
Wildcard multi-domaine
Un ajout relativement nouveau à 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 tout leur accompagnant en premier. sous-domaines de niveau.
Un autre cas d'utilisation du caractère générique multi-domaine est un caractère générique à plusieurs niveaux, où il peut crypter 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é Wildcard, les Wildcards multi-domaines ne sont pas non plus disponibles dans EV.
SSL/TLS in Motion
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 émission
Commençons par le début avec 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 où 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 exécute les étapes de validation requises pour s'assurer que toutes les informations contenues dans le certificat sont exactes. En règle générale, pour les certificats d'authentification d'entreprise (et non DV), cela implique la recherche des informations d'enregistrement d'une organisation et des 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 émetteurs, 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 maintenant 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 le trafic des 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 il facilitera les connexions cryptées avec les visiteurs du site.
En arrivant 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 visualisant 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 retourne à l'une des racines du magasin de confiance du système et qu'elle soit valide, le navigateur approuvera le certificat.
Maintenant, c'est l'heure 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 chiffrements qui seront utilisés pour la connexion. Le certificat SSL / TLS fournit une liste des suites de chiffrement prises en charge par le serveur. En règle générale, 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 chiffrements 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 cryptera à l'aide de la clé publique, puis l'enverra au serveur, qui possède la clé privée nécessaire pour décrypter 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 évoqué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 en toute sécurité avec lesquelles nous communiquerons. Les certificats qui confirment 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 à clé privée symétrique qui descend des cryptosystèmes classiques de l'antiquité.
Il y a beaucoup de pièces mobiles, 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 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.
After SSL/TLS – Getting the most out of your implementation
Le simple fait d'installer un certificat et de configurer correctement votre site Web ne signifie pas que votre site Web est sûr. Le TLS n'est qu'un élément d'une stratégie de cyberdéfense plus large et holistique. Mais un élément important, néanmoins. Voyons quelques 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
Revenant à 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 de désactiver la prise en charge des anciennes versions SSL / TLS ainsi que des algorithmes spécifiques pour prévenir la vulnérabilité à plusieurs exploits connus.
SSL 2.0 et SSL 3.0 ont tous deux plus de 20 ans. La meilleure pratique consistait à abandonner le support pour eux il y a des années, mais à ce jour, environ 7% des 100,000 XNUMX meilleurs Alexa les autorisent toujours. Ceci est dangereux car cela vous expose à des attaques de suppression et de rétrogradation SSL comme POODLE.
TLS 1.0 et TLS 1.1 sont également sur le temps emprunté.
Les grandes entreprises technologiques, Apple, Microsoft, Google et Mozilla, ont annoncé cet automne qu'elles abandonneraient la prise en charge de TLS 1.0 et 1.1 au début de 2020.
Les versions de protocole sont sensibles à des vulnérabilités telles que POODLE, FREAK, BEAST et CRIME (ce sont tous des acronymes). TLS 1.2 existe depuis dix ans et devrait être la norme. TLS 1.3 a été finalisée l'été dernier et l'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 interrompu en quelques heures. RC4 est plus vulnérable qu'une fois cru et a déjà été interdit par les normes de sécurité des données de l'industrie des cartes de paiement. Et enfin, compte tenu de l'actualité des récents exploits, il n'est plus conseillé d'utiliser RSA pour l'échange de clés.
Algorithmes / chiffrements suggérés:
- Échange de clés: Elliptic Curve Diffie-Helman (ECDH)
- Authentification: algorithme de signature numérique à courbe elliptique (ECDSA)
- Cryptage symétrique / en bloc: AES 256 en mode compteur Galois (AES256-GCM)
- Algorithme MAC: SHA-2 (SHA384)
SSL toujours activé
Dans le passé, les sites Web ne migraient parfois que les pages Web qui collectent des informations vers HTTPS, tout en desservant le reste du site via HTTP. C'est une mauvaise pratique.
En plus du fait que Google marquera ces pages comme «Non sécurisées», vous exposez également potentiellement les visiteurs de votre site à des risques en faisant basculer leurs navigateurs entre les pages cryptées et les pages HTTP.
Vous devriez configurer l'intégralité de votre site Web pour HTTPS. Cela s'appelle SSL permanent. Après tout, ce n'est pas comme si vous payiez à la page, votre certificat SSL / TLS peut crypter l'ensemble de votre site. Alors faites-le.
Configurer un enregistrement d'autorisation d'autorité de certification (CAA)
L'un des risques les plus importants posés par les certificats numériques, en général, est la mauvaise émission. Si une partie 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 contribuent à atténuer ce risque en limitant les autorités de certification autorisées à é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 d'émettre 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 émission ratée et susciterait la colère de la communauté des navigateurs.
L'ajout d'un enregistrement CAA est relativement simple, c'est 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 susceptibles d'être émises pour votre domaine et déterminer si des certificats Wildcard 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 uniquement la version HTTPS. C'est important car cela ferme la fenêtre sur plusieurs exploits connus, comme les attaques de rétrogradation et le détournement 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 et le respecte pendant toute la durée de la politique. Mais lors de cette toute première visite, avant que l'en-tête n'ait été reçu, il y a encore une petite ouverture pour un attaquant.
La liste des enregistrements de préchargement HSTS est gérée par Google et une variante de celle-ci est utilisée 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. Cela peut prendre une semaine ou deux pour que votre site apparaisse sur la liste en raison du fait que les mises à jour de la liste sont diffusées en conjonction avec 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 SSL dans WordPress sur l'hébergement partagé, cloud?
SSL/TLS FAQ
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. Parfois, vous verrez des entreprises utiliser le certificat X.509 à la place du «certificat numérique» ou du «certificat PKI».
Pourquoi les certificats SSL / TLS expirent-ils?
Il y a deux raisons à cela.
Le premier est qu'Internet est en constante évolution, les sites Web arrivent et les sites Web disparaissent. Et étant donné la sensibilité des navigateurs à faire confiance à 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 d'un 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 prochainement.
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 ne peuvent réutiliser que les informations de validation qui ont été initialement fournies si longtemps avant que les exigences de base ne les obligent à les revalider.
Lorsque vous renouvelez, vous pouvez conserver le même type de certificat que vous aviez auparavant, ou vous pouvez opter pour quelque chose de nouveau, vous pouvez même changer d'autorité de certification. Le plus important est le temps qu'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 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?
De nombreuses grandes entreprises dotées de 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. 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 cryptez pas à nouveau le trafic, cela s'appelle la terminaison SSL. Lorsque vous rechiffrez, cela s'appelle le pontage 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 peut 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?
Vous vous souvenez plus tôt lorsque nous avons discuté des programmes root?
Very OS a un magasin racine qu'il utilise pour faire des jugements de confiance PKI. 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 jamais l'un devait être révoqué. Au lieu de cela, ils créent 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 terminer la chaîne de certificats et émettront un avertissement. Certains navigateurs mettent en cache les certificats intermédiaires, mais il est toujours recommandé 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 via les ressources publiques de l '«autorité gouvernementale».
Cependant, dans certains endroits, cela peut ne pas être possible. Il y a cependant quelques éléments qui peuvent aider à accélérer la validation. Bien que le nombre de contrôles de validation qu'une lettre d'opinion professionnelle puisse satisfaire a été réduit récemment, avoir un avocat ou un comptable en règle peut encore aider considérablement.
De plus, vous pouvez fournir un justificatif d’identification d’entreprise émis par le gouvernement ou un document de «preuve de droit» qui donne à votre organisation le droit de faire des affaires sous le nom indiqué. Quelques exemples de ces documents sont:
- Articles d'incorporation
- Certificats de formation
- Licences entreprise / fournisseur / commerçant
- Documents de la charte
- Accords de partenariat
- Enregistrement du commerce ou du nom présumé
- Registre du commerce
Discours de clôture
J'espère que cela vous donne une idée de SSL / TLS. Si vous souhaitez en savoir plus, je vous recommande suivre ce cours en ligne.
Cet article a été rédigé par Patrick Nohe, rédacteur en chef de Haché par le magasin SSL, un blog couvrant l'actualité et les tendances de la cybersécurité.
