Dans le module précédent,
nous avons vu beaucoup de détails sur l'authentification des utilisateurs.
Nous avions vu comment l'utilisateur envoie ses informations d'identification à son serveur à partir du côté client
dans l'en-tête de
son message de requête ou dans le corps du message de demande, puis,
quand ils sont authentifiés,
alors leur client inclura soit le cookie soit le
jeton dans l'en-tête du message de requête allant du client au serveur.
Je suis sûr que certains d'entre vous parlaient
du fait que nous communiquions sur un canal non sécurisé, ce qui
signifie que toute personne assise au milieu qui peut
écouter ses messages allant entre le client
et le serveur serait facilement capable de capturer
les informations d'identification et ensuite usurper l'identité du client authentique.
Bien sûr, à ce moment-là,
leur accent était davantage mis sur l'organisation de la
communication client et serveur avec l'authentification du client côté serveur.
Mais chaque fois que vous devez utiliser l'authentification de l'utilisateur
, d'abord, sous la forme, disons, de
fournir les informations d'identification pour vous
authentifier et par la suite, en vous authentifiant en incluant
le cookie ou le jeton dans l'en-tête du message de requête,
vous devriez le faire sur un canal sécurisé.
Vous ne devez jamais communiquer sur un canal non sécurisé,
ce qui signifie que vous ne devriez pas utiliser HTTP et inclure
ces informations d'identification dans l'en-tête ou le corps des messages de requête.
Au lieu de cela, vous devriez utiliser une version sécurisée du protocole HTTP ou du protocole HTTPS.
Parlons brièvement de HTTPS dans cette conférence. En
cours de route, je vais vous donner une introduction de cinq minutes à la cryptographie et à la sécurité.
De toute évidence, la cryptographie et la sécurité sont un sujet très important à part entière.
Je vais juste vous présenter l'essentiel que vous devez
comprendre pour apprendre comment HTTPS fonctionne réellement.
Avec cet arrière-plan, continuons à comprendre à propos de la cryptographie, puis sur
le protocole HTTPS et comment vous configurez un serveur pour utiliser
le protocole HTTPS, puis le client pour contacter le serveur en utilisant le protocole HTTPS,
ainsi, la communication entre le client et le serveur peut être effectuée de manière sécurisée
en chiffrant les données envoyées entre le client et le côté serveur.
Lorsque vous vous aventurez dans le domaine de la cryptographie et de la sécurité,
vous entendrez souvent des gens parler de cryptographie par clé symétrique.
Qu' est-ce que la cryptographie implique ?
Si vous avez besoin d'envoyer un message sur un canal à
un autre utilisateur, vous voudrez pouvoir chiffrer le message de manière à ce que seul le destinataire puisse
déchiffrer le message et obtenir les
informations que vous essayez d'envoyer au destinataire.
Donc, l'expéditeur et le destinataire doivent comprendre sur établir entre
les deux comment ce processus de cryptage et comment le décryptage va fonctionner.
Pour que cela fonctionne,
tout cryptage et déchiffrement fonctionne basé sur l'échange de clés secrètes.
Ainsi, en cryptographie par clé symétrique,
l'expéditeur et le destinataire partageront une clé secrète entre les deux sites,
et cette clé secrète n'est connue que de l'expéditeur et du destinataire.
Ainsi, lorsque l'expéditeur doit envoyer le message
, l'expéditeur cryptera ce message à l'aide d'un algorithme de cryptographie,
qui utilise la clé secrète comme autre entrée de cet algorithme.
Et une fois que ce message est passé par cet algorithme de cryptographie
, un message crypté sera généré.
Maintenant, ce message crypté sera envoyé au canal à travers du côté récepteur.
Si vous avez un utilisateur malveillant tiers
assis entre les deux et écoutant et capturant ce message chiffré,
il aurait du mal à déchiffrer
ce message car pour déchiffrer un message chiffré,
vous avez toujours besoin de la clé secrète.
Maintenant, du côté du récepteur,
lorsque le message crypté est reçu,
le destinataire s'appliquera et un algorithme de déchiffrement,
qui prend également comme entrée,
la même clé secrète qui a été utilisée du côté de l'expéditeur pour chiffrer le message.
Ainsi, lors du déchiffrement, le message original sera récupéré
et peut être traité côté récepteur.
Maintenant, si un tiers malveillant veut déchiffrer ce message crypté, il
va faire face à une bataille difficile parce que
le processus de cryptage à l'aide de la clé secrète va tourner le message et peut,
à son tour, crypter le message.
Sans posséder la clé secrète,
il sera presque impossible de déchiffrer le message chiffré.
Eh bien, c'est l'étirement aller un peu loin.
Il serait excessivement difficile de déchiffrer le message chiffré.
Si vous utilisez des techniques de force brute,
vous finirez par déchiffrer le message chiffré.
Mais cela va prendre tellement de temps et nécessiter tant de puissance de calcul.
Cela ne vaudra pas la peine pour
l'utilisateur malveillant tiers d'essayer de décoder le message crypté.
Donc, vous rendez vraiment difficile pour quelqu'un de
déchiffrer le message s'il ne possède pas la clé secrète.
Maintenant, puisque la clé secrète n'est connue que de l'expéditeur et
du destinataire, les deux parties finales, l'expéditeur et le destinataire,
peuvent communiquer avec l'assurance
que dans le message crypté
du côté de l'expéditeur ne peut être décrypté que par le côté destinataire.
C' est ainsi que fonctionne la cryptographie par clé symétrique.
Le fait que vous ayez la même clé secrète partagée entre
l'expéditeur et le destinataire signifie que
l'inclusion du processus de décryptage a utilisé la même clé secrète, d'
où la cryptographie par clé symétrique.
Bien sûr, avec la cryptographie de clé symétrique,
l'un des problèmes est que l'expéditeur et
le destinataire doivent avoir accès à la même clé secrète.
Maintenant, si l'expéditeur et le destinataire communiquent sur un canal non sécurisé,
il sera difficile pour les deux parties de s'entendre
sur la même clé secrète sans la divulguer aux autres.
C' est donc là qu'un autre algorithme appelé cryptographie à clé publique est très utile.
Comment fonctionne la cryptographie à clé publique ?
Maintenant, en cryptographie à clé publique,
l'idée est que vous avez deux clés différentes.
Vous avez une clé publique et une clé privée.
Maintenant, la clé publique peut être largement distribuée à tous ceux que vous voulez.
Donc, quand quelqu'un veut vous envoyer un message,
il va utiliser votre clé publique pour crypter le message.
Donc, si un expéditeur ici veut envoyer le message au destinataire
, l'expéditeur utilisera la clé publique du destinataire pour
chiffrer le message côté expéditeur à l'aide de l'algorithme de chiffrement.
Maintenant, une fois que le message crypté est envoyé
sur le canal non sécurisé vers le côté
récepteur, le récepteur utilisera alors la clé privée
que seul le récepteur connaît pour déchiffrer.
Maintenant, pour que la cryptographie à clé publique fonctionne comme nous l'avons vu,
la clé publique peut être largement distribuée sans aucun souci.
Mais puisque la clé privée n'est connue que du côté du récepteur,
seul le récepteur sera capable de déchiffrer le message, et,
encore une fois, un intrus tiers qui capture
ce message crypté aura énormément de difficulté à déchiffrer le message.
Maintenant, bien sûr, en cryptographie à clé publique,
la clé publique et la clé privée sont deux clés différentes.
Maintenant, alors votre prochaine question évidente serait pourquoi
ne pas simplement utiliser la cryptographie à clé publique pour le cryptage.
Le problème est que l'utilisation de la cryptographie à clé publique
pour le chiffrement et le déchiffrement est un processus coûteux,
et c'est pourquoi nous n'utilisons pas la cryptographie à clé publique pour l'ensemble de leur communication.
Au lieu de cela, la cryptographie à clé publique sera
principalement utilisée pour l'expéditeur et le destinataire pour
convenir de la clé secrète commune que les deux vont utiliser.
Nous verrons plus tard comment la cryptographie à clé publique
peut être utilisée pour établir la clé secrète commune
entre l'expéditeur et le destinataire et ensuite
utiliser la cryptographie par clé symétrique pour une communication ultérieure.
Un protocole qui utilise cette approche est le Secure Sockets
Layer et aussi les protocoles de sécurité Transport Layer,
SSL et TLS en bref.
Tant de fois lorsque vous lisez de la documentation,
vous pouvez entendre parler de SSL et TLS.
Ces protocoles de cryptographie permettent une communication sécurisée entre
l'expéditeur et le destinataire sur un réseau non sécurisé comme Internet.
L' expéditeur et le destinataire communiqueront via Internet à l'aide de messages chiffrés,
que seuls l'expéditeur et le destinataire peuvent déchiffrer.
Et cette approche, SSL ou TLS,
utilise une combinaison de cryptographie à clé publique et de cryptographie à clé symétrique.
Leur processus exact de faire cela,
je vais expliquer dans la diapositive suivante.
En outre, en utilisant SSL ou TLS,
nous essayons de maintenir deux choses différentes.
Nous essayons tout d'abord de préserver la confidentialité de
la communication entre l'expéditeur et le destinataire afin qu'
aucun tiers malveillant ne puisse extraire le message du message crypté.
Deuxièmement, nous essayons également de maintenir l'intégrité,
ce qui signifie que lorsque l'expéditeur envoie un message,
le destinataire pourra être assuré que le message n'a pas été altéré. La
sécurité et le maintien de l'intégrité sont donc très importants dans ce cas.
Ainsi, la confidentialité et l'intégrité doivent être maintenues par
ce protocole de communication sécurisé que nous construisons
pour l'échange entre l'expéditeur et le destinataire.
Parlons brièvement de la façon dont SSL ou TLS fonctionnent réellement.
Cela se fait par un processus de poignée de main que j'ai illustré dans ce diagramme ici.
Lorsqu' un client souhaite communiquer avec le serveur,
le client envoie un message au serveur,
spécifiant que le client souhaite communiquer avec le serveur en toute sécurité.
À ce stade, le serveur renvoie le certificat au client,
qui contient une clé publique,
qui a été certifiée par
l'autorité de certification comme appartenant à ce serveur particulier.
Ainsi, lorsque le client reçoit
cette clé publique ainsi que la certification par l'autorité de certification,
le client sera en mesure de vérifier les informations d'identification du serveur.
Donc, le client doit établir qu'il parle vraiment au serveur,
avec lequel il a l'intention de communiquer.
Donc, à ce stade,
lorsque le client vérifie les informations d'identification du serveur,
le client a maintenant accès à la clé publique du serveur.
Une fois que le client obtient la clé publique du serveur,
le client génère ce qu'il appelle le secret de pré-maître.
Ce secret pré-maître est quelque chose que le client et le
serveur utiliseront pour générer ce qu'on appelle une clé de session.
Ainsi, le client génère un secret pré-maître,
le client crypte ensuite ce secret à l'aide de la clé publique du serveur,
puis envoie le secret au serveur.
Maintenant, rappelez-vous qu'une fois le secret crypté à l'aide de la clé publique,
personne d'autre que le serveur ne pourra
extraire les informations du message crypté.
Ainsi, lorsque le serveur reçoit ce message chiffré,
le serveur extrait le secret pré-maître de ce message.
Maintenant, le client et le serveur possèdent le même secret pré-maître.
À ce stade, le client et le serveur utiliseront
le même ensemble d'étapes commençant par le secret du pré-maître,
et avec le même ensemble de valeurs,
qui générera une clé appelée clé de session.
Maintenant, lorsque la clé de session est générée à la fois du côté client et du côté serveur,
ce sera exactement la même clé de session,
car les deux suivront exactement le même processus pour générer la clé de session.
Donc, à ce stade,
le client et le serveur
possèdent maintenant une clé secrète qui est la même sur les deux sites.
Ainsi, toutes les communications ultérieures entre le serveur et le client,
peuvent ensuite procéder à l'aide du cryptage symétrique.
Ainsi, lorsque le client doit communiquer avec le serveur,
le client crypte les données à l'aide de la clé de session secrète,
puis envoie leurs données.
De même, lorsque le serveur doit communiquer avec le client,
le serveur utilisera évidemment
la même clé de session pour chiffrer les données, puis les envoyer au client.
Maintenant, puisque le client possède la même clé de session,
le client sera en mesure de déchiffrer le message et d'extraire le message non chiffré.
En utilisant cette procédure,
le client et le serveur ont assuré que la communication entre eux est privée.
De plus, nous parvenons à nous assurer qu'aucun tiers malveillant ne peut
intercepter le message et provoquer des modifications au message.
Ainsi, l'intégrité du message est également maintenue,
et la confidentialité de la communication entre
le client et le serveur est également maintenue.
Donc, toute cette discussion que je vous ai présentée au cours des dernières diapositives,
est en un mot,
comment la communication sécurisée entre le client et le serveur peut être assurée
en utilisant la cryptographie à clé symétrique et la cryptographie à clé publique.
Maintenant, évidemment, il y a beaucoup plus à cela que ce que j'ai expliqué ici,
mais cette compréhension du fonctionnement de la cryptographie
suffit pour que vous compreniez comment fonctionne l'ensemble du processus.
Maintenant, si vous êtes intéressé à en apprendre plus à ce sujet,
une bonne source pour en apprendre davantage sur les protocoles de cryptographie est un très bon livre de
Jim Crozon Keith Ross appelé Computer Networks.
Ce livre a un chapitre très facile à comprendre
sur la cryptographie et la sécurité appliquée à la communication réseau.
Maintenant que nous avons établi le processus
pour pouvoir communiquer en toute sécurité entre un client et un serveur,
regardons comment Internet lui-même tire parti de cela,
pour la communication entre un client et le serveur en utilisant HTTP.
Maintenant, c'est là que le protocole HTTPS entre dans l'image.
Comme vous le comprenez déjà sur Internet,
Internet est une architecture en couches,
où l'IP et le TCP forment le réseau,
et la couche de transport qui s'exécute au-dessus du réseau sous-jacent.
Maintenant, au-dessus de la couche de transport,
vous avez la couche de socket sécurisée ou la couche de sécurité de la couche de transport comme
une couche mince au-dessus de TCP qui
assure une communication sécurisée entre le client et le serveur.
Et en plus, HTTP peut s'exécuter.
Ainsi, HTTP implique essentiellement HTTP plus l'utilisation du chiffrement, du
déchiffrement pris en charge par SSL et TLS.
Évidemment, même pour le protocole HTTPS,
il y a beaucoup plus de détails.
Mais du point de vue de l'implémentation du côté serveur,
ce que nous avons compris ici est suffisant pour nous permettre de comprendre comment
configurer un serveur pour utiliser une communication sécurisée entre le client et le serveur.
Maintenant, bien sûr, la première question qui vous viendra à l'esprit est,
que le serveur a besoin d'une clé publique et d'une clé privée.
Pour une cryptographie à clé publique,
comment le serveur génére-t-il cela ?
Si vous exécutez un serveur de production réel dans
votre environnement et que vous fournissez un service aux utilisateurs pour accéder à votre serveur,
alors vous devez évidemment passer par le processus de certification.
C' est là que vous aborderez une autorité de certification, par exemple des
sociétés comme VeriSign et Thawte Corporation
qui sont des autorités de certification publiques.
Il y en a quelques autres dans le monde.
Ainsi, vous les approcherez,
et ces autorités de certification authentifieront ensuite vos informations d'identification,
elles s'assureront que vous êtes celui que vous prétendez être,
puis elles vérifieront vos informations d'identification,
puis à ce stade,
elles vous émettront une clé publique et une clé privée à utiliser sur votre site serveur.
Ainsi, une fois qu'ils émettent la clé publique et
la clé privée, la clé publique sera certifiée par l'autorité de certification,
puis la clé publique portera également,
en plus, le certificat.
Donc, c'est le certificat que vous allez envoyer sur le site du client.
Étant donné que les clients peuvent établir
l'authenticité de ces Autorités de Certification,
si vous regardez n'importe quel navigateur, vous remarquerez que la plupart des navigateurs auront
les certificats de toutes ces Autorités de Certification établies
déjà intégrées dans eux.
Ils seront donc en mesure d'établir vos identifiants,
ou plutôt, ils seront en mesure d'établir que la clé privée vous appartient, en
obtenant votre certificat puis en vérifiant ou en vérifiant
votre certificat en sachant qu'il a été signé par
l'une de ces certifications établies Autorités.
Lors de ce processus, le client sera en mesure d'établir votre authenticité.
Maintenant, dans ce cours,
nous voulons juste comprendre comment fonctionne chaque HTTPS,
et aussi avoir un moyen simple de
configurer le serveur avec une clé publique et la clé privée.
Puisque nous faisons cela comme un exercice pour comprendre HTTPS,
nous pouvons utiliser un outil appelé SSL ouvert qui est déjà disponible sur
nos ordinateurs pour générer ce qu'on appelle le certificat auto-signé.
Les clés auto-signées ne sont pas acceptables dans le travail extérieur.
Mais comme nous savons que nous l'utilisons uniquement à des fins de test,
nous pouvons utiliser des certificats auto-signés,
simplement pour comprendre le processus
de communication sécurisée entre le client et le serveur.
Alors, comment utilisons-nous SSL ouvert ?
Jusqu' à présent, en utilisant SSL ouvert, vous pouvez générer des clés,
en utilisant trois commandes que je vous montre ici.
Vous exécutez ces trois commandes dans cette séquence,
comme spécifié ici et qui vous aidera à générer
une clé privée et un certificat que vous pouvez rendre disponibles à partir de
votre serveur HTTPS pour que les clients puissent télécharger et
ainsi obtenir votre clé publique pour une communication sécurisée.
Donc, c'est l'opération que nous allons faire dans notre exercice qui suit
cette conférence pour établir et émettre le service DPS. Donc, les trois étapes que nous faisons est, d'
abord, nous allons générer la clé privée en utilisant la première commande.
Ensuite, nous allons générer un cert.csr qui sera ensuite utilisé
pour nous pour générer un certificat qui
peut être distribué côté client par la troisième commande montrée là.
Ainsi, ces étapes vous permettront de générer une clé privée et
aussi un certificat correspondant qui peut être émis au client.
Encore une fois, si vous exécutez un serveur de production,
vous devez obtenir une clé publique, paire de clés privées,
auprès d'une des autorités de certification telles que VeriSign et Thawte corporation.
Comment le nœud lui-même fonctionne-t-il pour nous aider à configurer le HTTPS ?
Maintenant, c'est là que je passe brièvement en revue le code que nous allons
utiliser dans l'exercice qui suit afin de configurer nos serveurs. Le
nœud lui-même a le HTTPS en tant que module de base au sein du nœud.
Nous allons donc configurer HTTPS en exigeant ce module de base.
Nous utiliserons également le module de base
du système de fichiers car la clé privée et le certificat que nous générons seront stockés côté serveur,
et ils seront requis par
votre application express afin de configurer votre serveur sécurisé.
Donc, ici, nous allons utiliser le système de fichiers avec
la méthode ReadFileSync pour lire dans la clé privée
et le certificat à partir des fichiers que nous
générons en utilisant les étapes que nous avons vues dans le slot précédent.
Donc, une fois ces deux valeurs prêtes,
les options pour votre serveur HTTPS sont configurées et vous pouvez ensuite configurer
votre serveur sécurisé pour fournir une communication basée sur HTTPS à partir du site du serveur.
Maintenant que vous avez une compréhension rapide du fonctionnement de votre HTTPS
et comment il tire parti de l'utilisation de la cryptographie à clé publique
et de la cryptographie à clé symétrique pour
assurer une communication sécurisée entre le client et le serveur.
Passons à l'exercice pour configurer réellement
notre serveur express que nous avons construit jusqu'à présent pour utiliser le protocole HTTPS.