1 00:00:03,920 --> 00:00:06,615 Dans le module précédent, 2 00:00:06,615 --> 00:00:10,905 nous avons vu beaucoup de détails sur l'authentification des utilisateurs. 3 00:00:10,905 --> 00:00:17,610 Nous avions vu comment l'utilisateur envoie ses informations d'identification à son serveur à partir du côté client 4 00:00:17,610 --> 00:00:20,270 dans l'en-tête de 5 00:00:20,270 --> 00:00:24,870 son message de requête ou dans le corps du message de demande, puis, 6 00:00:24,870 --> 00:00:26,460 quand ils sont authentifiés, 7 00:00:26,460 --> 00:00:31,680 alors leur client inclura soit le cookie soit le 8 00:00:31,680 --> 00:00:38,499 jeton dans l'en-tête du message de requête allant du client au serveur. 9 00:00:38,499 --> 00:00:41,820 Je suis sûr que certains d'entre vous parlaient 10 00:00:41,820 --> 00:00:47,010 du fait que nous communiquions sur un canal non sécurisé, ce qui 11 00:00:47,010 --> 00:00:50,520 signifie que toute personne assise au milieu qui peut 12 00:00:50,520 --> 00:00:54,780 écouter ses messages allant entre le client 13 00:00:54,780 --> 00:00:57,570 et le serveur serait facilement capable de capturer 14 00:00:57,570 --> 00:01:03,195 les informations d'identification et ensuite usurper l'identité du client authentique. 15 00:01:03,195 --> 00:01:04,815 Bien sûr, à ce moment-là, 16 00:01:04,815 --> 00:01:09,025 leur accent était davantage mis sur l'organisation de la 17 00:01:09,025 --> 00:01:13,575 communication client et serveur avec l'authentification du client côté serveur. 18 00:01:13,575 --> 00:01:19,215 Mais chaque fois que vous devez utiliser l'authentification de l'utilisateur 19 00:01:19,215 --> 00:01:21,945 , d'abord, sous la forme, disons, de 20 00:01:21,945 --> 00:01:25,940 fournir les informations d'identification pour vous 21 00:01:25,940 --> 00:01:29,445 authentifier et par la suite, en vous authentifiant en incluant 22 00:01:29,445 --> 00:01:33,840 le cookie ou le jeton dans l'en-tête du message de requête, 23 00:01:33,840 --> 00:01:36,290 vous devriez le faire sur un canal sécurisé. 24 00:01:36,290 --> 00:01:39,890 Vous ne devez jamais communiquer sur un canal non sécurisé, 25 00:01:39,890 --> 00:01:44,160 ce qui signifie que vous ne devriez pas utiliser HTTP et inclure 26 00:01:44,160 --> 00:01:48,780 ces informations d'identification dans l'en-tête ou le corps des messages de requête. 27 00:01:48,780 --> 00:01:56,455 Au lieu de cela, vous devriez utiliser une version sécurisée du protocole HTTP ou du protocole HTTPS. 28 00:01:56,455 --> 00:02:01,830 Parlons brièvement de HTTPS dans cette conférence. En 29 00:02:01,830 --> 00:02:07,140 cours de route, je vais vous donner une introduction de cinq minutes à la cryptographie et à la sécurité. 30 00:02:07,140 --> 00:02:12,143 De toute évidence, la cryptographie et la sécurité sont un sujet très important à part entière. 31 00:02:12,143 --> 00:02:16,110 Je vais juste vous présenter l'essentiel que vous devez 32 00:02:16,110 --> 00:02:21,820 comprendre pour apprendre comment HTTPS fonctionne réellement. 33 00:02:21,820 --> 00:02:29,430 Avec cet arrière-plan, continuons à comprendre à propos de la cryptographie, puis sur 34 00:02:29,430 --> 00:02:34,110 le protocole HTTPS et comment vous configurez un serveur pour utiliser 35 00:02:34,110 --> 00:02:40,276 le protocole HTTPS, puis le client pour contacter le serveur en utilisant le protocole HTTPS, 36 00:02:40,276 --> 00:02:45,165 ainsi, la communication entre le client et le serveur peut être effectuée de manière sécurisée 37 00:02:45,165 --> 00:02:51,180 en chiffrant les données envoyées entre le client et le côté serveur. 38 00:02:51,180 --> 00:02:56,175 Lorsque vous vous aventurez dans le domaine de la cryptographie et de la sécurité, 39 00:02:56,175 --> 00:03:00,375 vous entendrez souvent des gens parler de cryptographie par clé symétrique. 40 00:03:00,375 --> 00:03:02,970 Qu' est-ce que la cryptographie implique ? 41 00:03:02,970 --> 00:03:10,800 Si vous avez besoin d'envoyer un message sur un canal à 42 00:03:10,800 --> 00:03:14,310 un autre utilisateur, vous voudrez pouvoir chiffrer le message de manière à ce que seul le destinataire puisse 43 00:03:14,310 --> 00:03:16,570 déchiffrer le message et obtenir les 44 00:03:16,570 --> 00:03:21,050 informations que vous essayez d'envoyer au destinataire. 45 00:03:21,050 --> 00:03:26,730 Donc, l'expéditeur et le destinataire doivent comprendre sur établir entre 46 00:03:26,730 --> 00:03:32,930 les deux comment ce processus de cryptage et comment le décryptage va fonctionner. 47 00:03:32,930 --> 00:03:34,365 Pour que cela fonctionne, 48 00:03:34,365 --> 00:03:41,265 tout cryptage et déchiffrement fonctionne basé sur l'échange de clés secrètes. 49 00:03:41,265 --> 00:03:43,765 Ainsi, en cryptographie par clé symétrique, 50 00:03:43,765 --> 00:03:50,678 l'expéditeur et le destinataire partageront une clé secrète entre les deux sites, 51 00:03:50,678 --> 00:03:55,165 et cette clé secrète n'est connue que de l'expéditeur et du destinataire. 52 00:03:55,165 --> 00:03:58,260 Ainsi, lorsque l'expéditeur doit envoyer le message 53 00:03:58,260 --> 00:04:04,755 , l'expéditeur cryptera ce message à l'aide d'un algorithme de cryptographie, 54 00:04:04,755 --> 00:04:09,795 qui utilise la clé secrète comme autre entrée de cet algorithme. 55 00:04:09,795 --> 00:04:13,875 Et une fois que ce message est passé par cet algorithme de cryptographie 56 00:04:13,875 --> 00:04:17,068 , un message crypté sera généré. 57 00:04:17,068 --> 00:04:24,160 Maintenant, ce message crypté sera envoyé au canal à travers du côté récepteur. 58 00:04:24,160 --> 00:04:28,140 Si vous avez un utilisateur malveillant tiers 59 00:04:28,140 --> 00:04:32,450 assis entre les deux et écoutant et capturant ce message chiffré, 60 00:04:32,450 --> 00:04:34,740 il aurait du mal à déchiffrer 61 00:04:34,740 --> 00:04:38,580 ce message car pour déchiffrer un message chiffré, 62 00:04:38,580 --> 00:04:40,645 vous avez toujours besoin de la clé secrète. 63 00:04:40,645 --> 00:04:42,375 Maintenant, du côté du récepteur, 64 00:04:42,375 --> 00:04:44,856 lorsque le message crypté est reçu, 65 00:04:44,856 --> 00:04:48,815 le destinataire s'appliquera et un algorithme de déchiffrement, 66 00:04:48,815 --> 00:04:50,715 qui prend également comme entrée, 67 00:04:50,715 --> 00:04:56,590 la même clé secrète qui a été utilisée du côté de l'expéditeur pour chiffrer le message. 68 00:04:56,590 --> 00:05:00,585 Ainsi, lors du déchiffrement, le message original sera récupéré 69 00:05:00,585 --> 00:05:05,240 et peut être traité côté récepteur. 70 00:05:05,240 --> 00:05:11,260 Maintenant, si un tiers malveillant veut déchiffrer ce message crypté, il 71 00:05:11,260 --> 00:05:14,280 va faire face à une bataille difficile parce que 72 00:05:14,280 --> 00:05:18,240 le processus de cryptage à l'aide de la clé secrète va tourner le message et peut, 73 00:05:18,240 --> 00:05:19,590 à son tour, crypter le message. 74 00:05:19,590 --> 00:05:21,830 Sans posséder la clé secrète, 75 00:05:21,830 --> 00:05:26,760 il sera presque impossible de déchiffrer le message chiffré. 76 00:05:26,760 --> 00:05:30,200 Eh bien, c'est l'étirement aller un peu loin. 77 00:05:30,200 --> 00:05:35,490 Il serait excessivement difficile de déchiffrer le message chiffré. 78 00:05:35,490 --> 00:05:39,210 Si vous utilisez des techniques de force brute, 79 00:05:39,210 --> 00:05:43,245 vous finirez par déchiffrer le message chiffré. 80 00:05:43,245 --> 00:05:48,880 Mais cela va prendre tellement de temps et nécessiter tant de puissance de calcul. 81 00:05:48,880 --> 00:05:53,175 Cela ne vaudra pas la peine pour 82 00:05:53,175 --> 00:05:58,580 l'utilisateur malveillant tiers d'essayer de décoder le message crypté. 83 00:05:58,580 --> 00:06:01,770 Donc, vous rendez vraiment difficile pour quelqu'un de 84 00:06:01,770 --> 00:06:05,355 déchiffrer le message s'il ne possède pas la clé secrète. 85 00:06:05,355 --> 00:06:09,480 Maintenant, puisque la clé secrète n'est connue que de l'expéditeur et 86 00:06:09,480 --> 00:06:12,390 du destinataire, les deux parties finales, l'expéditeur et le destinataire, 87 00:06:12,390 --> 00:06:16,335 peuvent communiquer avec l'assurance 88 00:06:16,335 --> 00:06:18,780 que dans le message crypté 89 00:06:18,780 --> 00:06:22,240 du côté de l'expéditeur ne peut être décrypté que par le côté destinataire. 90 00:06:22,240 --> 00:06:25,485 C' est ainsi que fonctionne la cryptographie par clé symétrique. 91 00:06:25,485 --> 00:06:30,330 Le fait que vous ayez la même clé secrète partagée entre 92 00:06:30,330 --> 00:06:32,400 l'expéditeur et le destinataire signifie que 93 00:06:32,400 --> 00:06:35,420 l'inclusion du processus de décryptage a utilisé la même clé secrète, d' 94 00:06:35,420 --> 00:06:38,911 où la cryptographie par clé symétrique. 95 00:06:38,911 --> 00:06:41,395 Bien sûr, avec la cryptographie de clé symétrique, 96 00:06:41,395 --> 00:06:44,440 l'un des problèmes est que l'expéditeur et 97 00:06:44,440 --> 00:06:48,805 le destinataire doivent avoir accès à la même clé secrète. 98 00:06:48,805 --> 00:06:53,940 Maintenant, si l'expéditeur et le destinataire communiquent sur un canal non sécurisé, 99 00:06:53,940 --> 00:06:58,230 il sera difficile pour les deux parties de s'entendre 100 00:06:58,230 --> 00:07:03,510 sur la même clé secrète sans la divulguer aux autres. 101 00:07:03,510 --> 00:07:09,315 C' est donc là qu'un autre algorithme appelé cryptographie à clé publique est très utile. 102 00:07:09,315 --> 00:07:12,195 Comment fonctionne la cryptographie à clé publique ? 103 00:07:12,195 --> 00:07:14,610 Maintenant, en cryptographie à clé publique, 104 00:07:14,610 --> 00:07:17,595 l'idée est que vous avez deux clés différentes. 105 00:07:17,595 --> 00:07:21,085 Vous avez une clé publique et une clé privée. 106 00:07:21,085 --> 00:07:26,520 Maintenant, la clé publique peut être largement distribuée à tous ceux que vous voulez. 107 00:07:26,520 --> 00:07:29,335 Donc, quand quelqu'un veut vous envoyer un message, 108 00:07:29,335 --> 00:07:34,350 il va utiliser votre clé publique pour crypter le message. 109 00:07:34,350 --> 00:07:39,795 Donc, si un expéditeur ici veut envoyer le message au destinataire 110 00:07:39,795 --> 00:07:44,385 , l'expéditeur utilisera la clé publique du destinataire pour 111 00:07:44,385 --> 00:07:50,240 chiffrer le message côté expéditeur à l'aide de l'algorithme de chiffrement. 112 00:07:50,240 --> 00:07:53,100 Maintenant, une fois que le message crypté est envoyé 113 00:07:53,100 --> 00:07:56,640 sur le canal non sécurisé vers le côté 114 00:07:56,640 --> 00:07:59,625 récepteur, le récepteur utilisera alors la clé privée 115 00:07:59,625 --> 00:08:03,210 que seul le récepteur connaît pour déchiffrer. 116 00:08:03,210 --> 00:08:06,645 Maintenant, pour que la cryptographie à clé publique fonctionne comme nous l'avons vu, 117 00:08:06,645 --> 00:08:10,760 la clé publique peut être largement distribuée sans aucun souci. 118 00:08:10,760 --> 00:08:14,150 Mais puisque la clé privée n'est connue que du côté du récepteur, 119 00:08:14,150 --> 00:08:19,325 seul le récepteur sera capable de déchiffrer le message, et, 120 00:08:19,325 --> 00:08:23,070 encore une fois, un intrus tiers qui capture 121 00:08:23,070 --> 00:08:28,410 ce message crypté aura énormément de difficulté à déchiffrer le message. 122 00:08:28,410 --> 00:08:29,670 Maintenant, bien sûr, en cryptographie à clé publique, 123 00:08:29,670 --> 00:08:33,385 la clé publique et la clé privée sont deux clés différentes. 124 00:08:33,385 --> 00:08:36,900 Maintenant, alors votre prochaine question évidente serait pourquoi 125 00:08:36,900 --> 00:08:40,686 ne pas simplement utiliser la cryptographie à clé publique pour le cryptage. 126 00:08:40,686 --> 00:08:44,445 Le problème est que l'utilisation de la cryptographie à clé publique 127 00:08:44,445 --> 00:08:48,383 pour le chiffrement et le déchiffrement est un processus coûteux, 128 00:08:48,383 --> 00:08:54,890 et c'est pourquoi nous n'utilisons pas la cryptographie à clé publique pour l'ensemble de leur communication. 129 00:08:54,890 --> 00:09:00,600 Au lieu de cela, la cryptographie à clé publique sera 130 00:09:00,600 --> 00:09:04,290 principalement utilisée pour l'expéditeur et le destinataire pour 131 00:09:04,290 --> 00:09:08,270 convenir de la clé secrète commune que les deux vont utiliser. 132 00:09:08,270 --> 00:09:12,210 Nous verrons plus tard comment la cryptographie à clé publique 133 00:09:12,210 --> 00:09:16,380 peut être utilisée pour établir la clé secrète commune 134 00:09:16,380 --> 00:09:19,845 entre l'expéditeur et le destinataire et ensuite 135 00:09:19,845 --> 00:09:24,686 utiliser la cryptographie par clé symétrique pour une communication ultérieure. 136 00:09:24,686 --> 00:09:29,790 Un protocole qui utilise cette approche est le Secure Sockets 137 00:09:29,790 --> 00:09:35,088 Layer et aussi les protocoles de sécurité Transport Layer, 138 00:09:35,088 --> 00:09:37,365 SSL et TLS en bref. 139 00:09:37,365 --> 00:09:40,395 Tant de fois lorsque vous lisez de la documentation, 140 00:09:40,395 --> 00:09:44,020 vous pouvez entendre parler de SSL et TLS. 141 00:09:44,020 --> 00:09:48,660 Ces protocoles de cryptographie permettent une communication sécurisée entre 142 00:09:48,660 --> 00:09:55,110 l'expéditeur et le destinataire sur un réseau non sécurisé comme Internet. 143 00:09:55,110 --> 00:10:03,150 L' expéditeur et le destinataire communiqueront via Internet à l'aide de messages chiffrés, 144 00:10:03,150 --> 00:10:06,410 que seuls l'expéditeur et le destinataire peuvent déchiffrer. 145 00:10:06,410 --> 00:10:09,266 Et cette approche, SSL ou TLS, 146 00:10:09,266 --> 00:10:16,220 utilise une combinaison de cryptographie à clé publique et de cryptographie à clé symétrique. 147 00:10:16,220 --> 00:10:18,905 Leur processus exact de faire cela, 148 00:10:18,905 --> 00:10:21,290 je vais expliquer dans la diapositive suivante. 149 00:10:21,290 --> 00:10:25,050 En outre, en utilisant SSL ou TLS, 150 00:10:25,050 --> 00:10:27,415 nous essayons de maintenir deux choses différentes. 151 00:10:27,415 --> 00:10:29,940 Nous essayons tout d'abord de préserver la confidentialité de 152 00:10:29,940 --> 00:10:32,880 la communication entre l'expéditeur et le destinataire afin qu' 153 00:10:32,880 --> 00:10:39,165 aucun tiers malveillant ne puisse extraire le message du message crypté. 154 00:10:39,165 --> 00:10:42,150 Deuxièmement, nous essayons également de maintenir l'intégrité, 155 00:10:42,150 --> 00:10:44,550 ce qui signifie que lorsque l'expéditeur envoie un message, 156 00:10:44,550 --> 00:10:50,025 le destinataire pourra être assuré que le message n'a pas été altéré. La 157 00:10:50,025 --> 00:10:57,145 sécurité et le maintien de l'intégrité sont donc très importants dans ce cas. 158 00:10:57,145 --> 00:11:01,110 Ainsi, la confidentialité et l'intégrité doivent être maintenues par 159 00:11:01,110 --> 00:11:04,200 ce protocole de communication sécurisé que nous construisons 160 00:11:04,200 --> 00:11:08,235 pour l'échange entre l'expéditeur et le destinataire. 161 00:11:08,235 --> 00:11:13,865 Parlons brièvement de la façon dont SSL ou TLS fonctionnent réellement. 162 00:11:13,865 --> 00:11:22,585 Cela se fait par un processus de poignée de main que j'ai illustré dans ce diagramme ici. 163 00:11:22,585 --> 00:11:26,020 Lorsqu' un client souhaite communiquer avec le serveur, 164 00:11:26,020 --> 00:11:28,920 le client envoie un message au serveur, 165 00:11:28,920 --> 00:11:34,405 spécifiant que le client souhaite communiquer avec le serveur en toute sécurité. 166 00:11:34,405 --> 00:11:40,068 À ce stade, le serveur renvoie le certificat au client, 167 00:11:40,068 --> 00:11:42,105 qui contient une clé publique, 168 00:11:42,105 --> 00:11:43,800 qui a été certifiée par 169 00:11:43,800 --> 00:11:48,410 l'autorité de certification comme appartenant à ce serveur particulier. 170 00:11:48,410 --> 00:11:51,210 Ainsi, lorsque le client reçoit 171 00:11:51,210 --> 00:11:56,325 cette clé publique ainsi que la certification par l'autorité de certification, 172 00:11:56,325 --> 00:11:59,960 le client sera en mesure de vérifier les informations d'identification du serveur. 173 00:11:59,960 --> 00:12:03,510 Donc, le client doit établir qu'il parle vraiment au serveur, 174 00:12:03,510 --> 00:12:07,345 avec lequel il a l'intention de communiquer. 175 00:12:07,345 --> 00:12:09,040 Donc, à ce stade, 176 00:12:09,040 --> 00:12:11,788 lorsque le client vérifie les informations d'identification du serveur, 177 00:12:11,788 --> 00:12:17,110 le client a maintenant accès à la clé publique du serveur. 178 00:12:17,110 --> 00:12:20,850 Une fois que le client obtient la clé publique du serveur, 179 00:12:20,850 --> 00:12:25,005 le client génère ce qu'il appelle le secret de pré-maître. 180 00:12:25,005 --> 00:12:28,560 Ce secret pré-maître est quelque chose que le client et le 181 00:12:28,560 --> 00:12:33,045 serveur utiliseront pour générer ce qu'on appelle une clé de session. 182 00:12:33,045 --> 00:12:36,870 Ainsi, le client génère un secret pré-maître, 183 00:12:36,870 --> 00:12:41,880 le client crypte ensuite ce secret à l'aide de la clé publique du serveur, 184 00:12:41,880 --> 00:12:44,880 puis envoie le secret au serveur. 185 00:12:44,880 --> 00:12:48,735 Maintenant, rappelez-vous qu'une fois le secret crypté à l'aide de la clé publique, 186 00:12:48,735 --> 00:12:51,690 personne d'autre que le serveur ne pourra 187 00:12:51,690 --> 00:12:55,110 extraire les informations du message crypté. 188 00:12:55,110 --> 00:12:58,440 Ainsi, lorsque le serveur reçoit ce message chiffré, 189 00:12:58,440 --> 00:13:03,300 le serveur extrait le secret pré-maître de ce message. 190 00:13:03,300 --> 00:13:08,863 Maintenant, le client et le serveur possèdent le même secret pré-maître. 191 00:13:08,863 --> 00:13:12,720 À ce stade, le client et le serveur utiliseront 192 00:13:12,720 --> 00:13:18,150 le même ensemble d'étapes commençant par le secret du pré-maître, 193 00:13:18,150 --> 00:13:20,902 et avec le même ensemble de valeurs, 194 00:13:20,902 --> 00:13:24,230 qui générera une clé appelée clé de session. 195 00:13:24,230 --> 00:13:28,157 Maintenant, lorsque la clé de session est générée à la fois du côté client et du côté serveur, 196 00:13:28,157 --> 00:13:30,630 ce sera exactement la même clé de session, 197 00:13:30,630 --> 00:13:36,565 car les deux suivront exactement le même processus pour générer la clé de session. 198 00:13:36,565 --> 00:13:37,950 Donc, à ce stade, 199 00:13:37,950 --> 00:13:39,540 le client et le serveur 200 00:13:39,540 --> 00:13:44,670 possèdent maintenant une clé secrète qui est la même sur les deux sites. 201 00:13:44,670 --> 00:13:48,570 Ainsi, toutes les communications ultérieures entre le serveur et le client, 202 00:13:48,570 --> 00:13:52,599 peuvent ensuite procéder à l'aide du cryptage symétrique. 203 00:13:52,599 --> 00:13:55,035 Ainsi, lorsque le client doit communiquer avec le serveur, 204 00:13:55,035 --> 00:13:59,640 le client crypte les données à l'aide de la clé de session secrète, 205 00:13:59,640 --> 00:14:01,340 puis envoie leurs données. 206 00:14:01,340 --> 00:14:05,100 De même, lorsque le serveur doit communiquer avec le client, 207 00:14:05,100 --> 00:14:07,440 le serveur utilisera évidemment 208 00:14:07,440 --> 00:14:12,365 la même clé de session pour chiffrer les données, puis les envoyer au client. 209 00:14:12,365 --> 00:14:15,215 Maintenant, puisque le client possède la même clé de session, 210 00:14:15,215 --> 00:14:21,255 le client sera en mesure de déchiffrer le message et d'extraire le message non chiffré. 211 00:14:21,255 --> 00:14:23,453 En utilisant cette procédure, 212 00:14:23,453 --> 00:14:30,099 le client et le serveur ont assuré que la communication entre eux est privée. 213 00:14:30,099 --> 00:14:33,930 De plus, nous parvenons à nous assurer qu'aucun tiers malveillant ne peut 214 00:14:33,930 --> 00:14:38,310 intercepter le message et provoquer des modifications au message. 215 00:14:38,310 --> 00:14:41,125 Ainsi, l'intégrité du message est également maintenue, 216 00:14:41,125 --> 00:14:43,260 et la confidentialité de la communication entre 217 00:14:43,260 --> 00:14:46,108 le client et le serveur est également maintenue. 218 00:14:46,108 --> 00:14:50,970 Donc, toute cette discussion que je vous ai présentée au cours des dernières diapositives, 219 00:14:50,970 --> 00:14:52,635 est en un mot, 220 00:14:52,635 --> 00:14:58,210 comment la communication sécurisée entre le client et le serveur peut être assurée 221 00:14:58,210 --> 00:15:05,454 en utilisant la cryptographie à clé symétrique et la cryptographie à clé publique. 222 00:15:05,454 --> 00:15:10,080 Maintenant, évidemment, il y a beaucoup plus à cela que ce que j'ai expliqué ici, 223 00:15:10,080 --> 00:15:14,490 mais cette compréhension du fonctionnement de la cryptographie 224 00:15:14,490 --> 00:15:19,540 suffit pour que vous compreniez comment fonctionne l'ensemble du processus. 225 00:15:19,540 --> 00:15:22,860 Maintenant, si vous êtes intéressé à en apprendre plus à ce sujet, 226 00:15:22,860 --> 00:15:28,515 une bonne source pour en apprendre davantage sur les protocoles de cryptographie est un très bon livre de 227 00:15:28,515 --> 00:15:34,800 Jim Crozon Keith Ross appelé Computer Networks. 228 00:15:34,800 --> 00:15:38,910 Ce livre a un chapitre très facile à comprendre 229 00:15:38,910 --> 00:15:44,995 sur la cryptographie et la sécurité appliquée à la communication réseau. 230 00:15:44,995 --> 00:15:48,985 Maintenant que nous avons établi le processus 231 00:15:48,985 --> 00:15:54,440 pour pouvoir communiquer en toute sécurité entre un client et un serveur, 232 00:15:54,440 --> 00:16:00,640 regardons comment Internet lui-même tire parti de cela, 233 00:16:00,640 --> 00:16:05,320 pour la communication entre un client et le serveur en utilisant HTTP. 234 00:16:05,320 --> 00:16:09,950 Maintenant, c'est là que le protocole HTTPS entre dans l'image. 235 00:16:09,950 --> 00:16:13,915 Comme vous le comprenez déjà sur Internet, 236 00:16:13,915 --> 00:16:17,905 Internet est une architecture en couches, 237 00:16:17,905 --> 00:16:22,165 où l'IP et le TCP forment le réseau, 238 00:16:22,165 --> 00:16:27,490 et la couche de transport qui s'exécute au-dessus du réseau sous-jacent. 239 00:16:27,490 --> 00:16:29,755 Maintenant, au-dessus de la couche de transport, 240 00:16:29,755 --> 00:16:35,800 vous avez la couche de socket sécurisée ou la couche de sécurité de la couche de transport comme 241 00:16:35,800 --> 00:16:39,265 une couche mince au-dessus de TCP qui 242 00:16:39,265 --> 00:16:43,095 assure une communication sécurisée entre le client et le serveur. 243 00:16:43,095 --> 00:16:45,492 Et en plus, HTTP peut s'exécuter. 244 00:16:45,492 --> 00:16:52,830 Ainsi, HTTP implique essentiellement HTTP plus l'utilisation du chiffrement, du 245 00:16:52,830 --> 00:16:56,073 déchiffrement pris en charge par SSL et TLS. 246 00:16:56,073 --> 00:17:00,150 Évidemment, même pour le protocole HTTPS, 247 00:17:00,150 --> 00:17:01,530 il y a beaucoup plus de détails. 248 00:17:01,530 --> 00:17:05,745 Mais du point de vue de l'implémentation du côté serveur, 249 00:17:05,745 --> 00:17:12,075 ce que nous avons compris ici est suffisant pour nous permettre de comprendre comment 250 00:17:12,075 --> 00:17:19,120 configurer un serveur pour utiliser une communication sécurisée entre le client et le serveur. 251 00:17:19,120 --> 00:17:23,070 Maintenant, bien sûr, la première question qui vous viendra à l'esprit est, 252 00:17:23,070 --> 00:17:25,800 que le serveur a besoin d'une clé publique et d'une clé privée. 253 00:17:25,800 --> 00:17:27,360 Pour une cryptographie à clé publique, 254 00:17:27,360 --> 00:17:29,330 comment le serveur génére-t-il cela ? 255 00:17:29,330 --> 00:17:32,265 Si vous exécutez un serveur de production réel dans 256 00:17:32,265 --> 00:17:36,792 votre environnement et que vous fournissez un service aux utilisateurs pour accéder à votre serveur, 257 00:17:36,792 --> 00:17:40,525 alors vous devez évidemment passer par le processus de certification. 258 00:17:40,525 --> 00:17:45,100 C' est là que vous aborderez une autorité de certification, par exemple des 259 00:17:45,100 --> 00:17:48,915 sociétés comme VeriSign et Thawte Corporation 260 00:17:48,915 --> 00:17:53,630 qui sont des autorités de certification publiques. 261 00:17:53,630 --> 00:17:55,987 Il y en a quelques autres dans le monde. 262 00:17:55,987 --> 00:17:58,160 Ainsi, vous les approcherez, 263 00:17:58,160 --> 00:18:03,960 et ces autorités de certification authentifieront ensuite vos informations d'identification, 264 00:18:03,960 --> 00:18:07,220 elles s'assureront que vous êtes celui que vous prétendez être, 265 00:18:07,220 --> 00:18:09,285 puis elles vérifieront vos informations d'identification, 266 00:18:09,285 --> 00:18:10,680 puis à ce stade, 267 00:18:10,680 --> 00:18:18,725 elles vous émettront une clé publique et une clé privée à utiliser sur votre site serveur. 268 00:18:18,725 --> 00:18:21,705 Ainsi, une fois qu'ils émettent la clé publique et 269 00:18:21,705 --> 00:18:27,010 la clé privée, la clé publique sera certifiée par l'autorité de certification, 270 00:18:27,010 --> 00:18:30,540 puis la clé publique portera également, 271 00:18:30,540 --> 00:18:32,626 en plus, le certificat. 272 00:18:32,626 --> 00:18:38,165 Donc, c'est le certificat que vous allez envoyer sur le site du client. 273 00:18:38,165 --> 00:18:43,935 Étant donné que les clients peuvent établir 274 00:18:43,935 --> 00:18:48,446 l'authenticité de ces Autorités de Certification, 275 00:18:48,446 --> 00:18:52,950 si vous regardez n'importe quel navigateur, vous remarquerez que la plupart des navigateurs auront 276 00:18:52,950 --> 00:18:58,115 les certificats de toutes ces Autorités de Certification établies 277 00:18:58,115 --> 00:18:59,715 déjà intégrées dans eux. 278 00:18:59,715 --> 00:19:03,685 Ils seront donc en mesure d'établir vos identifiants, 279 00:19:03,685 --> 00:19:07,605 ou plutôt, ils seront en mesure d'établir que la clé privée vous appartient, en 280 00:19:07,605 --> 00:19:12,540 obtenant votre certificat puis en vérifiant ou en vérifiant 281 00:19:12,540 --> 00:19:16,620 votre certificat en sachant qu'il a été signé par 282 00:19:16,620 --> 00:19:20,955 l'une de ces certifications établies Autorités. 283 00:19:20,955 --> 00:19:26,370 Lors de ce processus, le client sera en mesure d'établir votre authenticité. 284 00:19:26,370 --> 00:19:27,870 Maintenant, dans ce cours, 285 00:19:27,870 --> 00:19:31,125 nous voulons juste comprendre comment fonctionne chaque HTTPS, 286 00:19:31,125 --> 00:19:34,050 et aussi avoir un moyen simple de 287 00:19:34,050 --> 00:19:38,460 configurer le serveur avec une clé publique et la clé privée. 288 00:19:38,460 --> 00:19:43,791 Puisque nous faisons cela comme un exercice pour comprendre HTTPS, 289 00:19:43,791 --> 00:19:48,690 nous pouvons utiliser un outil appelé SSL ouvert qui est déjà disponible sur 290 00:19:48,690 --> 00:19:55,375 nos ordinateurs pour générer ce qu'on appelle le certificat auto-signé. 291 00:19:55,375 --> 00:19:59,780 Les clés auto-signées ne sont pas acceptables dans le travail extérieur. 292 00:19:59,780 --> 00:20:03,705 Mais comme nous savons que nous l'utilisons uniquement à des fins de test, 293 00:20:03,705 --> 00:20:06,300 nous pouvons utiliser des certificats auto-signés, 294 00:20:06,300 --> 00:20:08,685 simplement pour comprendre le processus 295 00:20:08,685 --> 00:20:12,910 de communication sécurisée entre le client et le serveur. 296 00:20:12,910 --> 00:20:15,405 Alors, comment utilisons-nous SSL ouvert ? 297 00:20:15,405 --> 00:20:18,585 Jusqu' à présent, en utilisant SSL ouvert, vous pouvez générer des clés, 298 00:20:18,585 --> 00:20:22,680 en utilisant trois commandes que je vous montre ici. 299 00:20:22,680 --> 00:20:26,475 Vous exécutez ces trois commandes dans cette séquence, 300 00:20:26,475 --> 00:20:30,020 comme spécifié ici et qui vous aidera à générer 301 00:20:30,020 --> 00:20:34,990 une clé privée et un certificat que vous pouvez rendre disponibles à partir de 302 00:20:34,990 --> 00:20:38,910 votre serveur HTTPS pour que les clients puissent télécharger et 303 00:20:38,910 --> 00:20:44,555 ainsi obtenir votre clé publique pour une communication sécurisée. 304 00:20:44,555 --> 00:20:48,510 Donc, c'est l'opération que nous allons faire dans notre exercice qui suit 305 00:20:48,510 --> 00:20:54,510 cette conférence pour établir et émettre le service DPS. Donc, les trois étapes que nous faisons est, d' 306 00:20:54,510 --> 00:20:59,740 abord, nous allons générer la clé privée en utilisant la première commande. 307 00:20:59,740 --> 00:21:07,980 Ensuite, nous allons générer un cert.csr qui sera ensuite utilisé 308 00:21:07,980 --> 00:21:12,090 pour nous pour générer un certificat qui 309 00:21:12,090 --> 00:21:16,720 peut être distribué côté client par la troisième commande montrée là. 310 00:21:16,720 --> 00:21:22,545 Ainsi, ces étapes vous permettront de générer une clé privée et 311 00:21:22,545 --> 00:21:30,590 aussi un certificat correspondant qui peut être émis au client. 312 00:21:30,590 --> 00:21:34,094 Encore une fois, si vous exécutez un serveur de production, 313 00:21:34,094 --> 00:21:38,610 vous devez obtenir une clé publique, paire de clés privées, 314 00:21:38,610 --> 00:21:44,205 auprès d'une des autorités de certification telles que VeriSign et Thawte corporation. 315 00:21:44,205 --> 00:21:50,400 Comment le nœud lui-même fonctionne-t-il pour nous aider à configurer le HTTPS ? 316 00:21:50,400 --> 00:21:54,900 Maintenant, c'est là que je passe brièvement en revue le code que nous allons 317 00:21:54,900 --> 00:22:00,357 utiliser dans l'exercice qui suit afin de configurer nos serveurs. Le 318 00:22:00,357 --> 00:22:07,910 nœud lui-même a le HTTPS en tant que module de base au sein du nœud. 319 00:22:07,910 --> 00:22:11,815 Nous allons donc configurer HTTPS en exigeant ce module de base. 320 00:22:11,815 --> 00:22:15,410 Nous utiliserons également le module de base 321 00:22:15,410 --> 00:22:20,760 du système de fichiers car la clé privée et le certificat que nous générons seront stockés côté serveur, 322 00:22:20,760 --> 00:22:23,250 et ils seront requis par 323 00:22:23,250 --> 00:22:28,170 votre application express afin de configurer votre serveur sécurisé. 324 00:22:28,170 --> 00:22:30,810 Donc, ici, nous allons utiliser le système de fichiers avec 325 00:22:30,810 --> 00:22:36,135 la méthode ReadFileSync pour lire dans la clé privée 326 00:22:36,135 --> 00:22:40,440 et le certificat à partir des fichiers que nous 327 00:22:40,440 --> 00:22:45,380 générons en utilisant les étapes que nous avons vues dans le slot précédent. 328 00:22:45,380 --> 00:22:48,780 Donc, une fois ces deux valeurs prêtes, 329 00:22:48,780 --> 00:22:54,930 les options pour votre serveur HTTPS sont configurées et vous pouvez ensuite configurer 330 00:22:54,930 --> 00:23:02,225 votre serveur sécurisé pour fournir une communication basée sur HTTPS à partir du site du serveur. 331 00:23:02,225 --> 00:23:07,680 Maintenant que vous avez une compréhension rapide du fonctionnement de votre HTTPS 332 00:23:07,680 --> 00:23:12,120 et comment il tire parti de l'utilisation de la cryptographie à clé publique 333 00:23:12,120 --> 00:23:14,970 et de la cryptographie à clé symétrique pour 334 00:23:14,970 --> 00:23:18,545 assurer une communication sécurisée entre le client et le serveur. 335 00:23:18,545 --> 00:23:21,885 Passons à l'exercice pour configurer réellement 336 00:23:21,885 --> 00:23:29,230 notre serveur express que nous avons construit jusqu'à présent pour utiliser le protocole HTTPS.