1 00:00:03,920 --> 00:00:06,615 No módulo anterior, 2 00:00:06,615 --> 00:00:10,905 vimos sobre autenticação de usuário com muitos detalhes. 3 00:00:10,905 --> 00:00:17,610 Tínhamos visto como o usuário envia suas credenciais para seu servidor do lado do cliente 4 00:00:17,610 --> 00:00:20,270 no cabeçalho de 5 00:00:20,270 --> 00:00:24,870 sua mensagem de solicitação ou no corpo da mensagem de solicitação e, posteriormente, 6 00:00:24,870 --> 00:00:26,460 quando eles são autenticados, 7 00:00:26,460 --> 00:00:31,680 então seu cliente incluirá o cookie ou o 8 00:00:31,680 --> 00:00:38,499 token em o cabeçalho da mensagem de solicitação indo do cliente para o servidor. 9 00:00:38,499 --> 00:00:41,820 Tenho certeza que alguns de vocês estavam se preocupando com 10 00:00:41,820 --> 00:00:47,010 o fato de que estávamos nos comunicando em um canal inseguro, 11 00:00:47,010 --> 00:00:50,520 significando que qualquer um sentado no meio que pudesse 12 00:00:50,520 --> 00:00:54,780 ouvir suas mensagens entre o cliente 13 00:00:54,780 --> 00:00:57,570 e o servidor seria facilmente capaz de capturar 14 00:00:57,570 --> 00:01:03,195 as credenciais e então personificar o cliente genuíno. 15 00:01:03,195 --> 00:01:04,815 É claro que, nesse ponto, 16 00:01:04,815 --> 00:01:09,025 sua ênfase era mais em organizar a 17 00:01:09,025 --> 00:01:13,575 comunicação do cliente e do servidor com autenticação do cliente no lado do servidor. 18 00:01:13,575 --> 00:01:19,215 Mas sempre que você precisar usar a autenticação do usuário 19 00:01:19,215 --> 00:01:21,945 , primeiro, na forma de, digamos, 20 00:01:21,945 --> 00:01:25,940 fornecer as credenciais para se autenticar e depois disso, 21 00:01:25,940 --> 00:01:29,445 autenticando-se incluindo o cookie ou 22 00:01:29,445 --> 00:01:33,840 o token no cabeçalho da mensagem de solicitação, 23 00:01:33,840 --> 00:01:36,290 você deve estar fazendo isso em um canal seguro. 24 00:01:36,290 --> 00:01:39,890 Você nunca deve se comunicar através de um canal inseguro, o 25 00:01:39,890 --> 00:01:44,160 que significa que você não deve usar HTTP e, 26 00:01:44,160 --> 00:01:48,780 em seguida, incluir essas credenciais no cabeçalho ou no corpo das mensagens de solicitação. 27 00:01:48,780 --> 00:01:56,455 Em vez disso, você deve estar usando uma versão segura do protocolo HTTP ou HTTPS. 28 00:01:56,455 --> 00:02:01,830 Vamos falar brevemente sobre HTTPS nesta palestra. 29 00:02:01,830 --> 00:02:07,140 Ao longo do caminho, vou lhe dar uma introdução de cinco minutos à criptografia e segurança. 30 00:02:07,140 --> 00:02:12,143 Obviamente, criptografia e segurança são um tópico muito grande em seu próprio direito. 31 00:02:12,143 --> 00:02:16,110 Vou apenas apresentá-los ao essencial que você precisa 32 00:02:16,110 --> 00:02:21,820 entender para aprender como HTTPS realmente funciona. 33 00:02:21,820 --> 00:02:29,430 Com este fundo, vamos continuar a entender sobre criptografia e, em seguida, para 34 00:02:29,430 --> 00:02:34,110 o protocolo HTTPS e como você configuraria um servidor para usar 35 00:02:34,110 --> 00:02:40,276 o protocolo HTTPS e, em seguida, o cliente para entrar em contato com o servidor usando o protocolo HTTPS, 36 00:02:40,276 --> 00:02:45,165 assim, a comunicação entre o cliente e o servidor pode ser feito de forma segura, 37 00:02:45,165 --> 00:02:51,180 criptografando os dados que estão sendo enviados entre o cliente e o lado do servidor. 38 00:02:51,180 --> 00:02:56,175 Quando você se aventurar no campo da criptografia e segurança, 39 00:02:56,175 --> 00:03:00,375 muitas vezes você ouvirá pessoas falando sobre criptografia de chave simétrica. 40 00:03:00,375 --> 00:03:02,970 Agora, o que a criptografia envolve? 41 00:03:02,970 --> 00:03:07,635 Se você precisar enviar uma mensagem através de um canal para outro usuário, 42 00:03:07,635 --> 00:03:10,800 então você gostaria de ser capaz de criptografar a mensagem de 43 00:03:10,800 --> 00:03:14,310 tal forma que apenas o receptor será capaz de 44 00:03:14,310 --> 00:03:16,570 descriptografar a mensagem e obter 45 00:03:16,570 --> 00:03:21,050 as informações que você está tentando enviar para o receptor. 46 00:03:21,050 --> 00:03:26,730 Então, tanto o remetente quanto o receptor devem entender sobre estabelecer entre 47 00:03:26,730 --> 00:03:32,930 os dois como esse processo de criptografia e como a descriptografia vai funcionar. 48 00:03:32,930 --> 00:03:34,365 Para que isso funcione, 49 00:03:34,365 --> 00:03:41,265 qualquer criptografia e descriptografia funciona com base na troca de chaves secretas. 50 00:03:41,265 --> 00:03:43,765 Assim, na criptografia de chave simétrica, 51 00:03:43,765 --> 00:03:50,678 tanto o remetente quanto o receptor compartilharão uma chave secreta entre os dois sites, 52 00:03:50,678 --> 00:03:55,165 e essa chave secreta é conhecida apenas pelo remetente e pelo lado do receptor. 53 00:03:55,165 --> 00:03:58,260 Então, quando o remetente precisa enviar a mensagem, 54 00:03:58,260 --> 00:04:04,755 então o remetente irá criptografar esta mensagem usando um algoritmo de criptografia, 55 00:04:04,755 --> 00:04:09,795 que usa a chave secreta como a outra entrada para este algoritmo. 56 00:04:09,795 --> 00:04:13,875 E uma vez que esta mensagem é passada através deste algoritmo de criptografia, 57 00:04:13,875 --> 00:04:17,068 em seguida, uma mensagem criptografada será gerada. 58 00:04:17,068 --> 00:04:24,160 Agora, esta mensagem criptografada será enviada para o canal através do lado do receptor. 59 00:04:24,160 --> 00:04:28,140 Se você tiver um usuário mal-intencionado de terceiros 60 00:04:28,140 --> 00:04:32,450 sentado no meio e ouvindo e capturando essa mensagem criptografada, 61 00:04:32,450 --> 00:04:34,740 ele terá dificuldade em descriptografar 62 00:04:34,740 --> 00:04:38,580 essa mensagem porque, para descriptografar uma mensagem criptografada, 63 00:04:38,580 --> 00:04:40,645 você ainda precisa da chave secreta. 64 00:04:40,645 --> 00:04:42,375 Agora, no lado do receptor, 65 00:04:42,375 --> 00:04:44,856 quando a mensagem criptografada é recebida, 66 00:04:44,856 --> 00:04:48,815 então o receptor será aplicado e um algoritmo de descriptografia, 67 00:04:48,815 --> 00:04:50,715 que também toma como entrada, 68 00:04:50,715 --> 00:04:56,590 a mesma chave secreta que foi usada no lado do remetente para criptografar a mensagem. 69 00:04:56,590 --> 00:05:00,585 Assim, após a descriptografia, a mensagem original será recuperada 70 00:05:00,585 --> 00:05:05,240 e pode ser processada no lado do receptor. 71 00:05:05,240 --> 00:05:11,260 Agora, se um terceiro malicioso quiser descriptografar essa mensagem criptografada, 72 00:05:11,260 --> 00:05:14,280 eles enfrentarão uma batalha difícil porque 73 00:05:14,280 --> 00:05:18,240 o processo de criptografia usando a chave secreta girará a mensagem e poderá, 74 00:05:18,240 --> 00:05:19,590 por sua vez, criptografar a mensagem. 75 00:05:19,590 --> 00:05:21,830 Sem possuir a chave secreta, 76 00:05:21,830 --> 00:05:26,760 será quase impossível descriptografar a mensagem criptografada. 77 00:05:26,760 --> 00:05:30,200 Bem, isso é alongamento chegar um pouco longe. 78 00:05:30,200 --> 00:05:35,490 Seria extremamente difícil descriptografar a mensagem criptografada. 79 00:05:35,490 --> 00:05:39,210 Se você usar técnicas de força bruta, então, eventualmente, 80 00:05:39,210 --> 00:05:43,245 você vai acabar descriptografando a mensagem criptografada. 81 00:05:43,245 --> 00:05:48,880 Mas vai demorar tanto tempo e exigir tanto poder computacional. 82 00:05:48,880 --> 00:05:53,175 Não valerá a pena o esforço para 83 00:05:53,175 --> 00:05:58,580 o usuário mal-intencionado de terceiros tentar decodificar a mensagem criptografada. 84 00:05:58,580 --> 00:06:01,770 Então você está essencialmente tornando muito difícil para alguém 85 00:06:01,770 --> 00:06:05,355 decifrar a mensagem se não possuir a chave secreta. 86 00:06:05,355 --> 00:06:09,480 Agora, uma vez que a chave secreta é conhecida apenas para o remetente e o receptor, 87 00:06:09,480 --> 00:06:12,390 as duas partes finais, o remetente e o receptor, 88 00:06:12,390 --> 00:06:16,335 podem se comunicar com a garantia de 89 00:06:16,335 --> 00:06:18,780 que na mensagem criptografada 90 00:06:18,780 --> 00:06:22,240 do lado do remetente só pode ser descriptografada pelo lado do receptor. 91 00:06:22,240 --> 00:06:25,485 Então é assim que a criptografia de chave simétrica funciona. 92 00:06:25,485 --> 00:06:30,330 O fato de que você tem a mesma chave secreta sendo compartilhada entre 93 00:06:30,330 --> 00:06:32,400 o remetente e o receptor significa que 94 00:06:32,400 --> 00:06:35,420 a inclusão do processo de 95 00:06:35,420 --> 00:06:38,911 descriptografia usou a mesma chave secreta, portanto, criptografia de chave simétrica. 96 00:06:38,911 --> 00:06:41,395 Claro, com a criptografia de chave simétrica, 97 00:06:41,395 --> 00:06:44,440 um dos problemas é que tanto o remetente quanto 98 00:06:44,440 --> 00:06:48,805 o receptor precisam ter acesso à mesma chave secreta. 99 00:06:48,805 --> 00:06:53,940 Agora, se o remetente e o receptor estão se comunicando através de um canal inseguro, 100 00:06:53,940 --> 00:06:58,230 será difícil para ambos os lados chegar a um entendimento 101 00:06:58,230 --> 00:07:03,510 sobre a mesma chave secreta sem revelá-la a outros. 102 00:07:03,510 --> 00:07:09,315 Então é aqui que outro algoritmo chamado criptografia de chave pública é muito útil. 103 00:07:09,315 --> 00:07:12,195 Como funciona a criptografia de chave pública? 104 00:07:12,195 --> 00:07:14,610 Agora, na criptografia de chave pública, 105 00:07:14,610 --> 00:07:17,595 a idéia é que você tem duas chaves diferentes. 106 00:07:17,595 --> 00:07:21,085 Você tem uma chave pública e uma chave privada. 107 00:07:21,085 --> 00:07:26,520 Agora, a chave pública pode ser amplamente distribuída para quem você quiser. 108 00:07:26,520 --> 00:07:29,335 Então, quando alguém quer enviar uma mensagem para você, 109 00:07:29,335 --> 00:07:34,350 ele vai usar sua chave pública para criptografar a mensagem. 110 00:07:34,350 --> 00:07:39,795 Então, se um remetente aqui quiser enviar a mensagem para o receptor, 111 00:07:39,795 --> 00:07:44,385 então o remetente usará a chave pública fora do receptor para 112 00:07:44,385 --> 00:07:50,240 criptografar a mensagem no lado do remetente usando o algoritmo de criptografia. 113 00:07:50,240 --> 00:07:53,100 Agora, uma vez que a mensagem criptografada é enviada 114 00:07:53,100 --> 00:07:56,640 através do canal inseguro para o lado 115 00:07:56,640 --> 00:07:59,625 do receptor, o receptor usará a chave privada 116 00:07:59,625 --> 00:08:03,210 que somente o receptor conhece para descriptografar. 117 00:08:03,210 --> 00:08:06,645 Agora, para que a criptografia de chave pública funcione como vimos, 118 00:08:06,645 --> 00:08:10,760 a chave pública pode ser amplamente distribuída sem qualquer preocupação. 119 00:08:10,760 --> 00:08:14,150 Mas uma vez que a chave privada só é conhecida pelo lado 120 00:08:14,150 --> 00:08:19,325 do receptor, somente o receptor será capaz de descriptografar a mensagem e 121 00:08:19,325 --> 00:08:23,070 , novamente, um intruso de terceiros que capturar 122 00:08:23,070 --> 00:08:28,410 essa mensagem criptografada achará muito difícil descriptografar a mensagem. 123 00:08:28,410 --> 00:08:29,670 Agora, é claro que na criptografia de chave pública, 124 00:08:29,670 --> 00:08:33,385 a chave pública e a chave privada são duas chaves diferentes. 125 00:08:33,385 --> 00:08:36,900 Agora, então sua próxima pergunta óbvia seria por que 126 00:08:36,900 --> 00:08:40,686 não simplesmente usar criptografia de chave pública para criptografia. 127 00:08:40,686 --> 00:08:44,445 O problema é que usar criptografia de chave pública 128 00:08:44,445 --> 00:08:48,383 para criptografia e descriptografia é um processo caro, 129 00:08:48,383 --> 00:08:54,890 e é por isso que não usamos criptografia de chave pública para toda a comunicação deles. 130 00:08:54,890 --> 00:09:00,600 Em vez disso, a criptografia de chave pública será usada 131 00:09:00,600 --> 00:09:04,290 principalmente para que o remetente e o receptor 132 00:09:04,290 --> 00:09:08,270 concordem com a chave secreta comum que os dois vão usar. 133 00:09:08,270 --> 00:09:12,210 Mais tarde veremos como a criptografia de chave pública 134 00:09:12,210 --> 00:09:16,380 pode ser usada para estabelecer a chave secreta comum 135 00:09:16,380 --> 00:09:19,845 entre o remetente e o receptor e, posteriormente, 136 00:09:19,845 --> 00:09:24,686 usar criptografia de chave simétrica para comunicação adicional. 137 00:09:24,686 --> 00:09:29,790 Um protocolo que usa essa abordagem é o Secure 138 00:09:29,790 --> 00:09:35,088 Sockets Layer e também os protocolos de segurança Transport 139 00:09:35,088 --> 00:09:37,365 Layer, SSL e TLS em resumo. 140 00:09:37,365 --> 00:09:40,395 Muitas vezes, quando você lê a documentação, 141 00:09:40,395 --> 00:09:44,020 você pode ouvir sobre SSL e TLS. 142 00:09:44,020 --> 00:09:48,660 Esses protocolos de criptografia permitem a comunicação segura entre 143 00:09:48,660 --> 00:09:55,110 o remetente e o receptor através de uma rede insegura como a Internet. 144 00:09:55,110 --> 00:10:03,150 O remetente e o receptor se comunicarão através desta Internet usando mensagens criptografadas, 145 00:10:03,150 --> 00:10:06,410 que somente o remetente e o receptor podem descriptografar. 146 00:10:06,410 --> 00:10:09,266 E essa abordagem, SSL ou TLS, 147 00:10:09,266 --> 00:10:16,220 usa uma combinação de criptografia de chave pública juntamente com criptografia de chave simétrica. 148 00:10:16,220 --> 00:10:18,905 Seu processo exato de fazer isso, 149 00:10:18,905 --> 00:10:21,290 vou explicar no próximo slide. 150 00:10:21,290 --> 00:10:25,050 Além disso, usando SSL ou TLS, 151 00:10:25,050 --> 00:10:27,415 estamos tentando manter duas coisas diferentes. 152 00:10:27,415 --> 00:10:29,940 Estamos, em primeiro lugar, tentando manter a privacidade da 153 00:10:29,940 --> 00:10:32,880 comunicação entre o remetente e o receptor para que 154 00:10:32,880 --> 00:10:39,165 nenhum terceiro malicioso possa extrair a mensagem da mensagem criptografada. 155 00:10:39,165 --> 00:10:42,150 Em segundo lugar, também estamos tentando manter a integridade, o 156 00:10:42,150 --> 00:10:44,550 que significa que quando o remetente envia uma mensagem, 157 00:10:44,550 --> 00:10:50,025 o receptor será capaz de ter certeza de que a mensagem não foi adulterada. 158 00:10:50,025 --> 00:10:57,145 Portanto, tanto a segurança quanto a manutenção da integridade são muito importantes neste caso. 159 00:10:57,145 --> 00:11:01,110 Portanto, tanto a privacidade como a integridade têm de ser mantidas por 160 00:11:01,110 --> 00:11:04,200 este protocolo de comunicação seguro que construímos 161 00:11:04,200 --> 00:11:08,235 para troca entre o remetente e o receptor. 162 00:11:08,235 --> 00:11:13,865 Vamos falar brevemente sobre como SSL ou TLS realmente funcionam. 163 00:11:13,865 --> 00:11:22,585 Isto é feito através de um processo de aperto de mão que eu tenho ilustrado neste diagrama aqui. 164 00:11:22,585 --> 00:11:26,020 Quando um cliente deseja se comunicar com o servidor, 165 00:11:26,020 --> 00:11:28,920 o cliente envia uma mensagem para o servidor, 166 00:11:28,920 --> 00:11:34,405 especificando que o cliente deseja se comunicar com o servidor de forma segura. 167 00:11:34,405 --> 00:11:40,068 Neste ponto, o servidor enviará de volta o certificado para o cliente, 168 00:11:40,068 --> 00:11:42,105 que contém uma chave pública, 169 00:11:42,105 --> 00:11:43,800 que foi certificada 170 00:11:43,800 --> 00:11:48,410 pela autoridade de certificação como pertencente a esse servidor específico. 171 00:11:48,410 --> 00:11:51,210 Dessa forma, quando o cliente recebe 172 00:11:51,210 --> 00:11:56,325 essa chave pública mais a certificação pela autoridade de certificação, 173 00:11:56,325 --> 00:11:59,960 o cliente poderá verificar as credenciais do servidor. 174 00:11:59,960 --> 00:12:03,510 Então, o cliente precisa estabelecer que ele está realmente falando com o servidor, 175 00:12:03,510 --> 00:12:07,345 com o qual ele pretende se comunicar. 176 00:12:07,345 --> 00:12:09,040 Então, neste ponto, 177 00:12:09,040 --> 00:12:11,788 quando o cliente verifica as credenciais do servidor, 178 00:12:11,788 --> 00:12:17,110 o cliente agora tem acesso à chave pública do servidor. 179 00:12:17,110 --> 00:12:20,850 Uma vez que o cliente se apossar da chave pública do servidor, 180 00:12:20,850 --> 00:12:25,005 em seguida, o cliente irá gerar o que é chamado como o segredo pré-mestre. 181 00:12:25,005 --> 00:12:28,560 Esse segredo pré-mestre é algo que tanto o cliente quanto o 182 00:12:28,560 --> 00:12:33,045 servidor usarão para gerar o que é chamado como uma chave de sessão. 183 00:12:33,045 --> 00:12:36,870 Então, o cliente gera um segredo pré-mestre, 184 00:12:36,870 --> 00:12:41,880 o cliente criptografa esse segredo usando a chave pública do servidor 185 00:12:41,880 --> 00:12:44,880 e, em seguida, envia o segredo para o servidor. 186 00:12:44,880 --> 00:12:48,735 Agora, lembre-se que uma vez que o segredo é criptografado usando a chave pública, 187 00:12:48,735 --> 00:12:51,690 ninguém além do servidor será capaz de 188 00:12:51,690 --> 00:12:55,110 extrair as informações da mensagem criptografada. 189 00:12:55,110 --> 00:12:58,440 Então, quando o servidor recebe essa mensagem criptografada, 190 00:12:58,440 --> 00:13:03,300 o servidor extrai o segredo pré-mestre dessa mensagem. 191 00:13:03,300 --> 00:13:08,863 Agora, tanto o cliente quanto o servidor possuem o mesmo segredo pré-mestre. 192 00:13:08,863 --> 00:13:12,720 Neste ponto, tanto o cliente quanto o servidor usarão 193 00:13:12,720 --> 00:13:18,150 o mesmo conjunto de etapas começando com o segredo do pré-mestre, 194 00:13:18,150 --> 00:13:20,902 e com o mesmo conjunto de valores, 195 00:13:20,902 --> 00:13:24,230 que gerará uma chave chamada como a chave de sessão. 196 00:13:24,230 --> 00:13:28,157 Agora, quando a chave de sessão é gerada tanto no lado do cliente quanto no lado do servidor, 197 00:13:28,157 --> 00:13:30,630 será exatamente a mesma chave de sessão, 198 00:13:30,630 --> 00:13:36,565 porque ambos seguirão exatamente o mesmo processo para gerar a chave de sessão. 199 00:13:36,565 --> 00:13:37,950 Então, neste ponto, 200 00:13:37,950 --> 00:13:39,540 tanto o cliente quanto o servidor, 201 00:13:39,540 --> 00:13:44,670 agora possuem uma chave secreta que é a mesma em ambos os sites. 202 00:13:44,670 --> 00:13:48,570 Assim, toda a comunicação subsequente entre o servidor eo cliente, 203 00:13:48,570 --> 00:13:52,599 pode então prosseguir usando criptografia simétrica. 204 00:13:52,599 --> 00:13:55,035 Então, quando o cliente precisa se comunicar com o servidor, 205 00:13:55,035 --> 00:13:59,640 o cliente criptografará os dados usando a chave de sessão secreta 206 00:13:59,640 --> 00:14:01,340 e, em seguida, enviará seus dados. 207 00:14:01,340 --> 00:14:05,100 Da mesma forma, quando o servidor precisa se comunicar com o cliente, 208 00:14:05,100 --> 00:14:07,440 o servidor obviamente usará 209 00:14:07,440 --> 00:14:12,365 a mesma chave de sessão para criptografar os dados e, em seguida, enviá-los para o cliente. 210 00:14:12,365 --> 00:14:15,215 Agora, como o cliente possui a mesma chave de sessão, 211 00:14:15,215 --> 00:14:21,255 o cliente será capaz de descriptografar a mensagem e extrair a mensagem não criptografada. 212 00:14:21,255 --> 00:14:23,453 Usando este procedimento, 213 00:14:23,453 --> 00:14:30,099 o cliente e o servidor garantiu que a comunicação entre eles é privada. 214 00:14:30,099 --> 00:14:33,930 Além disso, conseguimos garantir que nenhum terceiro malicioso possa 215 00:14:33,930 --> 00:14:38,310 interceptar a mensagem e causar alterações à mensagem. 216 00:14:38,310 --> 00:14:41,125 Assim, a integridade da mensagem também é mantida, 217 00:14:41,125 --> 00:14:43,260 e a privacidade da comunicação entre 218 00:14:43,260 --> 00:14:46,108 o cliente e o servidor também é mantida. 219 00:14:46,108 --> 00:14:50,970 Então, toda essa discussão que apresentei a vocês nos últimos slides, 220 00:14:50,970 --> 00:14:52,635 é em poucas palavras, 221 00:14:52,635 --> 00:14:58,210 como a comunicação segura entre o cliente e o servidor pode ser assegurada 222 00:14:58,210 --> 00:15:05,454 usando a criptografia de chave simétrica e criptografia de chave pública. 223 00:15:05,454 --> 00:15:10,080 Agora, obviamente, há muito mais do que o que eu expliquei aqui, 224 00:15:10,080 --> 00:15:14,490 mas essa compreensão de como a criptografia funciona é 225 00:15:14,490 --> 00:15:19,540 suficiente para você entender como todo o processo funciona. 226 00:15:19,540 --> 00:15:22,860 Agora, se você está interessado em aprender mais sobre isso, 227 00:15:22,860 --> 00:15:28,515 uma boa fonte para aprender sobre Protocolos de Criptografia é um livro muito bom 228 00:15:28,515 --> 00:15:34,800 de Jim Crozon Keith Ross chamado Computer Networks. 229 00:15:34,800 --> 00:15:38,910 Este livro tem um capítulo muito fácil de entender 230 00:15:38,910 --> 00:15:44,995 sobre criptografia e segurança como aplicado à comunicação de rede. 231 00:15:44,995 --> 00:15:48,985 Agora que estabelecemos o processo 232 00:15:48,985 --> 00:15:54,440 para ser capaz de comunicar de forma segura entre um cliente e servidor, 233 00:15:54,440 --> 00:16:00,640 vamos ver como a própria internet aproveita isso, 234 00:16:00,640 --> 00:16:05,320 para comunicação entre um cliente e o servidor usando HTTP. 235 00:16:05,320 --> 00:16:09,950 Agora, é aqui que o protocolo HTTPS entra em cena. 236 00:16:09,950 --> 00:16:13,915 Como você já entende sobre a internet, 237 00:16:13,915 --> 00:16:17,905 a internet é uma arquitetura em camadas, 238 00:16:17,905 --> 00:16:22,165 onde o IP e o TCP formam a rede, 239 00:16:22,165 --> 00:16:27,490 e a camada de transporte que é executada em cima da rede subjacente. 240 00:16:27,490 --> 00:16:29,755 Agora, em cima da camada de transporte, 241 00:16:29,755 --> 00:16:35,800 você tem a camada de soquete segura ou o revestimento de segurança da camada de transporte como 242 00:16:35,800 --> 00:16:39,265 uma camada fina na parte superior do TCP que 243 00:16:39,265 --> 00:16:43,095 garante uma comunicação segura entre o cliente e o servidor. 244 00:16:43,095 --> 00:16:45,492 E em cima disso HTTP pode ser executado. 245 00:16:45,492 --> 00:16:52,830 Então, HTTP envolve essencialmente HTTP mais o uso de criptografia, 246 00:16:52,830 --> 00:16:56,073 descriptografia suportada através de SSL e TLS. 247 00:16:56,073 --> 00:17:00,150 Obviamente, mesmo para o protocolo HTTPS, 248 00:17:00,150 --> 00:17:01,530 há muito mais detalhes. 249 00:17:01,530 --> 00:17:05,745 Mas do ponto de vista da implementação do lado do servidor, 250 00:17:05,745 --> 00:17:12,075 o que entendemos aqui é suficiente para entendermos como 251 00:17:12,075 --> 00:17:19,120 configurar um servidor para usar a comunicação segura entre o cliente e o servidor. 252 00:17:19,120 --> 00:17:23,070 Agora, é claro que a primeira pergunta que virá à sua mente é, 253 00:17:23,070 --> 00:17:25,800 que o servidor precisa de uma chave pública e uma chave privada. 254 00:17:25,800 --> 00:17:27,360 Para uma criptografia de chave pública, 255 00:17:27,360 --> 00:17:29,330 como o servidor gera isso? 256 00:17:29,330 --> 00:17:32,265 Se você estiver executando um servidor de produção real em 257 00:17:32,265 --> 00:17:36,792 seu ambiente e fornecendo serviços para que os usuários acessem seu servidor, 258 00:17:36,792 --> 00:17:40,525 então obviamente você precisa passar pelo processo de certificação. 259 00:17:40,525 --> 00:17:45,100 É aqui que você abordará uma autoridade de certificação, por exemplo, 260 00:17:45,100 --> 00:17:48,915 corporações como VeriSign e Thawte Corporation, 261 00:17:48,915 --> 00:17:53,630 que são Autoridades de Certificação Pública. 262 00:17:53,630 --> 00:17:55,987 Há mais algumas ao redor do mundo. 263 00:17:55,987 --> 00:17:58,160 Então, você abordará eles, 264 00:17:58,160 --> 00:18:03,960 e essas Autoridades de Certificação autenticarão suas credenciais, 265 00:18:03,960 --> 00:18:07,220 elas garantirão que você seja quem você alega ser 266 00:18:07,220 --> 00:18:09,285 e, 267 00:18:09,285 --> 00:18:10,680 em seguida, verificarão suas credenciais e, nesse ponto, 268 00:18:10,680 --> 00:18:18,725 emitirão uma chave pública e uma chave privada para uso no site do servidor. 269 00:18:18,725 --> 00:18:21,705 Assim, uma vez que eles emitem a chave pública e a chave privada, 270 00:18:21,705 --> 00:18:27,010 a chave pública será certificada pela Autoridade de Certificação 271 00:18:27,010 --> 00:18:30,540 e, 272 00:18:30,540 --> 00:18:32,626 em seguida, a chave pública também carregará, além disso, o certificado. 273 00:18:32,626 --> 00:18:38,165 Então, este é o certificado que você enviará para o site do cliente. 274 00:18:38,165 --> 00:18:43,935 Como os clientes podem estabelecer 275 00:18:43,935 --> 00:18:48,446 a autenticidade dessas Autoridades de Certificação, 276 00:18:48,446 --> 00:18:52,950 se você olhar para qualquer navegador, você notaria que a maioria dos navegadores terá 277 00:18:52,950 --> 00:18:58,115 os certificados para todas essas Autoridades de Certificação estabelecidas 278 00:18:58,115 --> 00:18:59,715 já incorporados neles. 279 00:18:59,715 --> 00:19:03,685 Assim, eles serão capazes de estabelecer suas credenciais, 280 00:19:03,685 --> 00:19:07,605 ou melhor, eles serão capazes de estabelecer que a chave privada pertence a você, 281 00:19:07,605 --> 00:19:12,540 obtendo seu certificado e, em seguida, verificando ou verificando 282 00:19:12,540 --> 00:19:16,620 seu certificado sabendo que ele foi assinado por uma 283 00:19:16,620 --> 00:19:20,955 dessas Certificações estabelecidas Autoridades. 284 00:19:20,955 --> 00:19:26,370 Após este processo, o cliente será capaz de estabelecer a sua autenticidade. 285 00:19:26,370 --> 00:19:27,870 Agora, neste curso, 286 00:19:27,870 --> 00:19:31,125 nós só queremos entender como cada HTTPS funciona, 287 00:19:31,125 --> 00:19:34,050 e também queremos ter uma maneira simples de 288 00:19:34,050 --> 00:19:38,460 configurar o servidor com uma chave pública e a chave privada. 289 00:19:38,460 --> 00:19:43,791 Como estamos fazendo isso como um exercício para entender HTTPS, 290 00:19:43,791 --> 00:19:48,690 podemos usar uma ferramenta chamada SSL aberto que já está disponível em 291 00:19:48,690 --> 00:19:55,375 nossos computadores para gerar o que é chamado de certificado auto-assinado. 292 00:19:55,375 --> 00:19:59,780 As chaves autoassinadas não são aceitáveis no trabalho externo. 293 00:19:59,780 --> 00:20:03,705 Mas como sabemos que estamos usando apenas para nossos fins de teste, 294 00:20:03,705 --> 00:20:06,300 podemos usar certificados autoassinados, 295 00:20:06,300 --> 00:20:08,685 simplesmente para entender o processo 296 00:20:08,685 --> 00:20:12,910 de comunicação segura entre o cliente e o servidor. 297 00:20:12,910 --> 00:20:15,405 Então, como usamos SSL aberto? 298 00:20:15,405 --> 00:20:18,585 Até agora usando SSL aberto você pode gerar Chaves, 299 00:20:18,585 --> 00:20:22,680 usando três comandos que eu mostro aqui. 300 00:20:22,680 --> 00:20:26,475 Você executa esses três comandos nessa sequência, 301 00:20:26,475 --> 00:20:30,020 conforme especificado aqui e que irá ajudá-lo a gerar 302 00:20:30,020 --> 00:20:34,990 uma chave privada e um certificado que você pode disponibilizar a partir do 303 00:20:34,990 --> 00:20:38,910 seu servidor HTTPS para que os clientes baixem e, 304 00:20:38,910 --> 00:20:44,555 assim, obter sua chave pública para comunicação segura. 305 00:20:44,555 --> 00:20:48,510 Então, esta é a operação que vamos fazer em nosso exercício que segue 306 00:20:48,510 --> 00:20:54,510 esta palestra para estabelecer e emitir o serviço DPS. Então, os três passos que fazemos é 307 00:20:54,510 --> 00:20:59,740 , primeiro, gerar a chave privada usando o primeiro comando. 308 00:20:59,740 --> 00:21:07,980 Em seguida, vamos gerar um cert.csr que será então usado 309 00:21:07,980 --> 00:21:12,090 para gerar um certificado que 310 00:21:12,090 --> 00:21:16,720 pode ser distribuído para o lado do cliente pelo terceiro comando mostrado lá. 311 00:21:16,720 --> 00:21:22,545 Portanto, essas etapas permitirão que você gere uma chave privada e 312 00:21:22,545 --> 00:21:30,590 também um certificado correspondente que pode ser emitido para o cliente. 313 00:21:30,590 --> 00:21:34,094 Novamente, para enfatizar, se você estiver executando um servidor de produção, 314 00:21:34,094 --> 00:21:38,610 então você precisa obter uma chave pública, par de chaves privadas, 315 00:21:38,610 --> 00:21:44,205 de uma das Autoridades de Certificação como VeriSign e Thawte Corporation. 316 00:21:44,205 --> 00:21:50,400 Como o nó em si funciona para nos ajudar a configurar o HTTPS? 317 00:21:50,400 --> 00:21:54,900 Agora é aqui que estou revisando brevemente o código que 318 00:21:54,900 --> 00:22:00,357 usaremos no exercício que se segue para configurar nossos servidores. 319 00:22:00,357 --> 00:22:07,910 Nó em si tem o HTTPS como um módulo núcleo dentro do nó. 320 00:22:07,910 --> 00:22:11,815 Então vamos configurar HTTPS exigindo este módulo núcleo. 321 00:22:11,815 --> 00:22:15,410 Também usaremos o módulo núcleo do sistema de arquivos porque 322 00:22:15,410 --> 00:22:20,760 a chave privada e o certificado que geramos serão armazenados no lado do servidor, 323 00:22:20,760 --> 00:22:23,250 e eles serão exigidos pela 324 00:22:23,250 --> 00:22:28,170 sua aplicação expressa para configurar seu servidor seguro. 325 00:22:28,170 --> 00:22:30,810 Então, aqui vamos usar o sistema de arquivos com 326 00:22:30,810 --> 00:22:36,135 o método ReadFileSync para ler na chave privada 327 00:22:36,135 --> 00:22:40,440 e o certificado dos arquivos que 328 00:22:40,440 --> 00:22:45,380 geramos usando os passos que vimos no slot anterior. 329 00:22:45,380 --> 00:22:48,780 Assim que esses dois valores estiverem prontos, 330 00:22:48,780 --> 00:22:54,930 as opções para o servidor HTTPS serão configuradas e você poderá configurar 331 00:22:54,930 --> 00:23:02,225 seu servidor seguro para fornecer comunicação baseada em HTTPS a partir do site do servidor. 332 00:23:02,225 --> 00:23:07,680 Agora que você tem uma compreensão rápida de como seu HTTPS funciona 333 00:23:07,680 --> 00:23:12,120 e como ele aproveita o uso de criptografia de chave pública 334 00:23:12,120 --> 00:23:14,970 e criptografia de chave simétrica para 335 00:23:14,970 --> 00:23:18,545 garantir uma comunicação segura entre o cliente e o servidor. 336 00:23:18,545 --> 00:23:21,885 Vamos passar para o exercício para realmente configurar o 337 00:23:21,885 --> 00:23:29,230 nosso servidor expresso que temos vindo a construir até agora para usar o protocolo HTTPS.