No módulo anterior,
vimos sobre autenticação de usuário com muitos detalhes.
Tínhamos visto como o usuário envia suas credenciais para seu servidor do lado do cliente
no cabeçalho de
sua mensagem de solicitação ou no corpo da mensagem de solicitação e, posteriormente,
quando eles são autenticados,
então seu cliente incluirá o cookie ou o
token em o cabeçalho da mensagem de solicitação indo do cliente para o servidor.
Tenho certeza que alguns de vocês estavam se preocupando com
o fato de que estávamos nos comunicando em um canal inseguro,
significando que qualquer um sentado no meio que pudesse
ouvir suas mensagens entre o cliente
e o servidor seria facilmente capaz de capturar
as credenciais e então personificar o cliente genuíno.
É claro que, nesse ponto,
sua ênfase era mais em organizar a
comunicação do cliente e do servidor com autenticação do cliente no lado do servidor.
Mas sempre que você precisar usar a autenticação do usuário
, primeiro, na forma de, digamos,
fornecer as credenciais para se autenticar e depois disso,
autenticando-se incluindo o cookie ou
o token no cabeçalho da mensagem de solicitação,
você deve estar fazendo isso em um canal seguro.
Você nunca deve se comunicar através de um canal inseguro, o
que significa que você não deve usar HTTP e,
em seguida, incluir essas credenciais no cabeçalho ou no corpo das mensagens de solicitação.
Em vez disso, você deve estar usando uma versão segura do protocolo HTTP ou HTTPS.
Vamos falar brevemente sobre HTTPS nesta palestra.
Ao longo do caminho, vou lhe dar uma introdução de cinco minutos à criptografia e segurança.
Obviamente, criptografia e segurança são um tópico muito grande em seu próprio direito.
Vou apenas apresentá-los ao essencial que você precisa
entender para aprender como HTTPS realmente funciona.
Com este fundo, vamos continuar a entender sobre criptografia e, em seguida, para
o protocolo HTTPS e como você configuraria um servidor para usar
o protocolo HTTPS e, em seguida, o cliente para entrar em contato com o servidor usando o protocolo HTTPS,
assim, a comunicação entre o cliente e o servidor pode ser feito de forma segura,
criptografando os dados que estão sendo enviados entre o cliente e o lado do servidor.
Quando você se aventurar no campo da criptografia e segurança,
muitas vezes você ouvirá pessoas falando sobre criptografia de chave simétrica.
Agora, o que a criptografia envolve?
Se você precisar enviar uma mensagem através de um canal para outro usuário,
então você gostaria de ser capaz de criptografar a mensagem de
tal forma que apenas o receptor será capaz de
descriptografar a mensagem e obter
as informações que você está tentando enviar para o receptor.
Então, tanto o remetente quanto o receptor devem entender sobre estabelecer entre
os dois como esse processo de criptografia e como a descriptografia vai funcionar.
Para que isso funcione,
qualquer criptografia e descriptografia funciona com base na troca de chaves secretas.
Assim, na criptografia de chave simétrica,
tanto o remetente quanto o receptor compartilharão uma chave secreta entre os dois sites,
e essa chave secreta é conhecida apenas pelo remetente e pelo lado do receptor.
Então, quando o remetente precisa enviar a mensagem,
então o remetente irá criptografar esta mensagem usando um algoritmo de criptografia,
que usa a chave secreta como a outra entrada para este algoritmo.
E uma vez que esta mensagem é passada através deste algoritmo de criptografia,
em seguida, uma mensagem criptografada será gerada.
Agora, esta mensagem criptografada será enviada para o canal através do lado do receptor.
Se você tiver um usuário mal-intencionado de terceiros
sentado no meio e ouvindo e capturando essa mensagem criptografada,
ele terá dificuldade em descriptografar
essa mensagem porque, para descriptografar uma mensagem criptografada,
você ainda precisa da chave secreta.
Agora, no lado do receptor,
quando a mensagem criptografada é recebida,
então o receptor será aplicado e um algoritmo de descriptografia,
que também toma como entrada,
a mesma chave secreta que foi usada no lado do remetente para criptografar a mensagem.
Assim, após a descriptografia, a mensagem original será recuperada
e pode ser processada no lado do receptor.
Agora, se um terceiro malicioso quiser descriptografar essa mensagem criptografada,
eles enfrentarão uma batalha difícil porque
o processo de criptografia usando a chave secreta girará a mensagem e poderá,
por sua vez, criptografar a mensagem.
Sem possuir a chave secreta,
será quase impossível descriptografar a mensagem criptografada.
Bem, isso é alongamento chegar um pouco longe.
Seria extremamente difícil descriptografar a mensagem criptografada.
Se você usar técnicas de força bruta, então, eventualmente,
você vai acabar descriptografando a mensagem criptografada.
Mas vai demorar tanto tempo e exigir tanto poder computacional.
Não valerá a pena o esforço para
o usuário mal-intencionado de terceiros tentar decodificar a mensagem criptografada.
Então você está essencialmente tornando muito difícil para alguém
decifrar a mensagem se não possuir a chave secreta.
Agora, uma vez que a chave secreta é conhecida apenas para o remetente e o receptor,
as duas partes finais, o remetente e o receptor,
podem se comunicar com a garantia de
que na mensagem criptografada
do lado do remetente só pode ser descriptografada pelo lado do receptor.
Então é assim que a criptografia de chave simétrica funciona.
O fato de que você tem a mesma chave secreta sendo compartilhada entre
o remetente e o receptor significa que
a inclusão do processo de
descriptografia usou a mesma chave secreta, portanto, criptografia de chave simétrica.
Claro, com a criptografia de chave simétrica,
um dos problemas é que tanto o remetente quanto
o receptor precisam ter acesso à mesma chave secreta.
Agora, se o remetente e o receptor estão se comunicando através de um canal inseguro,
será difícil para ambos os lados chegar a um entendimento
sobre a mesma chave secreta sem revelá-la a outros.
Então é aqui que outro algoritmo chamado criptografia de chave pública é muito útil.
Como funciona a criptografia de chave pública?
Agora, na criptografia de chave pública,
a idéia é que você tem duas chaves diferentes.
Você tem uma chave pública e uma chave privada.
Agora, a chave pública pode ser amplamente distribuída para quem você quiser.
Então, quando alguém quer enviar uma mensagem para você,
ele vai usar sua chave pública para criptografar a mensagem.
Então, se um remetente aqui quiser enviar a mensagem para o receptor,
então o remetente usará a chave pública fora do receptor para
criptografar a mensagem no lado do remetente usando o algoritmo de criptografia.
Agora, uma vez que a mensagem criptografada é enviada
através do canal inseguro para o lado
do receptor, o receptor usará a chave privada
que somente o receptor conhece para descriptografar.
Agora, para que a criptografia de chave pública funcione como vimos,
a chave pública pode ser amplamente distribuída sem qualquer preocupação.
Mas uma vez que a chave privada só é conhecida pelo lado
do receptor, somente o receptor será capaz de descriptografar a mensagem e
, novamente, um intruso de terceiros que capturar
essa mensagem criptografada achará muito difícil descriptografar a mensagem.
Agora, é claro que na criptografia de chave pública,
a chave pública e a chave privada são duas chaves diferentes.
Agora, então sua próxima pergunta óbvia seria por que
não simplesmente usar criptografia de chave pública para criptografia.
O problema é que usar criptografia de chave pública
para criptografia e descriptografia é um processo caro,
e é por isso que não usamos criptografia de chave pública para toda a comunicação deles.
Em vez disso, a criptografia de chave pública será usada
principalmente para que o remetente e o receptor
concordem com a chave secreta comum que os dois vão usar.
Mais tarde veremos como a criptografia de chave pública
pode ser usada para estabelecer a chave secreta comum
entre o remetente e o receptor e, posteriormente,
usar criptografia de chave simétrica para comunicação adicional.
Um protocolo que usa essa abordagem é o Secure
Sockets Layer e também os protocolos de segurança Transport
Layer, SSL e TLS em resumo.
Muitas vezes, quando você lê a documentação,
você pode ouvir sobre SSL e TLS.
Esses protocolos de criptografia permitem a comunicação segura entre
o remetente e o receptor através de uma rede insegura como a Internet.
O remetente e o receptor se comunicarão através desta Internet usando mensagens criptografadas,
que somente o remetente e o receptor podem descriptografar.
E essa abordagem, SSL ou TLS,
usa uma combinação de criptografia de chave pública juntamente com criptografia de chave simétrica.
Seu processo exato de fazer isso,
vou explicar no próximo slide.
Além disso, usando SSL ou TLS,
estamos tentando manter duas coisas diferentes.
Estamos, em primeiro lugar, tentando manter a privacidade da
comunicação entre o remetente e o receptor para que
nenhum terceiro malicioso possa extrair a mensagem da mensagem criptografada.
Em segundo lugar, também estamos tentando manter a integridade, o
que significa que quando o remetente envia uma mensagem,
o receptor será capaz de ter certeza de que a mensagem não foi adulterada.
Portanto, tanto a segurança quanto a manutenção da integridade são muito importantes neste caso.
Portanto, tanto a privacidade como a integridade têm de ser mantidas por
este protocolo de comunicação seguro que construímos
para troca entre o remetente e o receptor.
Vamos falar brevemente sobre como SSL ou TLS realmente funcionam.
Isto é feito através de um processo de aperto de mão que eu tenho ilustrado neste diagrama aqui.
Quando um cliente deseja se comunicar com o servidor,
o cliente envia uma mensagem para o servidor,
especificando que o cliente deseja se comunicar com o servidor de forma segura.
Neste ponto, o servidor enviará de volta o certificado para o cliente,
que contém uma chave pública,
que foi certificada
pela autoridade de certificação como pertencente a esse servidor específico.
Dessa forma, quando o cliente recebe
essa chave pública mais a certificação pela autoridade de certificação,
o cliente poderá verificar as credenciais do servidor.
Então, o cliente precisa estabelecer que ele está realmente falando com o servidor,
com o qual ele pretende se comunicar.
Então, neste ponto,
quando o cliente verifica as credenciais do servidor,
o cliente agora tem acesso à chave pública do servidor.
Uma vez que o cliente se apossar da chave pública do servidor,
em seguida, o cliente irá gerar o que é chamado como o segredo pré-mestre.
Esse segredo pré-mestre é algo que tanto o cliente quanto o
servidor usarão para gerar o que é chamado como uma chave de sessão.
Então, o cliente gera um segredo pré-mestre,
o cliente criptografa esse segredo usando a chave pública do servidor
e, em seguida, envia o segredo para o servidor.
Agora, lembre-se que uma vez que o segredo é criptografado usando a chave pública,
ninguém além do servidor será capaz de
extrair as informações da mensagem criptografada.
Então, quando o servidor recebe essa mensagem criptografada,
o servidor extrai o segredo pré-mestre dessa mensagem.
Agora, tanto o cliente quanto o servidor possuem o mesmo segredo pré-mestre.
Neste ponto, tanto o cliente quanto o servidor usarão
o mesmo conjunto de etapas começando com o segredo do pré-mestre,
e com o mesmo conjunto de valores,
que gerará uma chave chamada como a chave de sessão.
Agora, quando a chave de sessão é gerada tanto no lado do cliente quanto no lado do servidor,
será exatamente a mesma chave de sessão,
porque ambos seguirão exatamente o mesmo processo para gerar a chave de sessão.
Então, neste ponto,
tanto o cliente quanto o servidor,
agora possuem uma chave secreta que é a mesma em ambos os sites.
Assim, toda a comunicação subsequente entre o servidor eo cliente,
pode então prosseguir usando criptografia simétrica.
Então, quando o cliente precisa se comunicar com o servidor,
o cliente criptografará os dados usando a chave de sessão secreta
e, em seguida, enviará seus dados.
Da mesma forma, quando o servidor precisa se comunicar com o cliente,
o servidor obviamente usará
a mesma chave de sessão para criptografar os dados e, em seguida, enviá-los para o cliente.
Agora, como o cliente possui a mesma chave de sessão,
o cliente será capaz de descriptografar a mensagem e extrair a mensagem não criptografada.
Usando este procedimento,
o cliente e o servidor garantiu que a comunicação entre eles é privada.
Além disso, conseguimos garantir que nenhum terceiro malicioso possa
interceptar a mensagem e causar alterações à mensagem.
Assim, a integridade da mensagem também é mantida,
e a privacidade da comunicação entre
o cliente e o servidor também é mantida.
Então, toda essa discussão que apresentei a vocês nos últimos slides,
é em poucas palavras,
como a comunicação segura entre o cliente e o servidor pode ser assegurada
usando a criptografia de chave simétrica e criptografia de chave pública.
Agora, obviamente, há muito mais do que o que eu expliquei aqui,
mas essa compreensão de como a criptografia funciona é
suficiente para você entender como todo o processo funciona.
Agora, se você está interessado em aprender mais sobre isso,
uma boa fonte para aprender sobre Protocolos de Criptografia é um livro muito bom
de Jim Crozon Keith Ross chamado Computer Networks.
Este livro tem um capítulo muito fácil de entender
sobre criptografia e segurança como aplicado à comunicação de rede.
Agora que estabelecemos o processo
para ser capaz de comunicar de forma segura entre um cliente e servidor,
vamos ver como a própria internet aproveita isso,
para comunicação entre um cliente e o servidor usando HTTP.
Agora, é aqui que o protocolo HTTPS entra em cena.
Como você já entende sobre a internet,
a internet é uma arquitetura em camadas,
onde o IP e o TCP formam a rede,
e a camada de transporte que é executada em cima da rede subjacente.
Agora, em cima da camada de transporte,
você tem a camada de soquete segura ou o revestimento de segurança da camada de transporte como
uma camada fina na parte superior do TCP que
garante uma comunicação segura entre o cliente e o servidor.
E em cima disso HTTP pode ser executado.
Então, HTTP envolve essencialmente HTTP mais o uso de criptografia,
descriptografia suportada através de SSL e TLS.
Obviamente, mesmo para o protocolo HTTPS,
há muito mais detalhes.
Mas do ponto de vista da implementação do lado do servidor,
o que entendemos aqui é suficiente para entendermos como
configurar um servidor para usar a comunicação segura entre o cliente e o servidor.
Agora, é claro que a primeira pergunta que virá à sua mente é,
que o servidor precisa de uma chave pública e uma chave privada.
Para uma criptografia de chave pública,
como o servidor gera isso?
Se você estiver executando um servidor de produção real em
seu ambiente e fornecendo serviços para que os usuários acessem seu servidor,
então obviamente você precisa passar pelo processo de certificação.
É aqui que você abordará uma autoridade de certificação, por exemplo,
corporações como VeriSign e Thawte Corporation,
que são Autoridades de Certificação Pública.
Há mais algumas ao redor do mundo.
Então, você abordará eles,
e essas Autoridades de Certificação autenticarão suas credenciais,
elas garantirão que você seja quem você alega ser
e,
em seguida, verificarão suas credenciais e, nesse ponto,
emitirão uma chave pública e uma chave privada para uso no site do servidor.
Assim, uma vez que eles emitem a chave pública e a chave privada,
a chave pública será certificada pela Autoridade de Certificação
e,
em seguida, a chave pública também carregará, além disso, o certificado.
Então, este é o certificado que você enviará para o site do cliente.
Como os clientes podem estabelecer
a autenticidade dessas Autoridades de Certificação,
se você olhar para qualquer navegador, você notaria que a maioria dos navegadores terá
os certificados para todas essas Autoridades de Certificação estabelecidas
já incorporados neles.
Assim, eles serão capazes de estabelecer suas credenciais,
ou melhor, eles serão capazes de estabelecer que a chave privada pertence a você,
obtendo seu certificado e, em seguida, verificando ou verificando
seu certificado sabendo que ele foi assinado por uma
dessas Certificações estabelecidas Autoridades.
Após este processo, o cliente será capaz de estabelecer a sua autenticidade.
Agora, neste curso,
nós só queremos entender como cada HTTPS funciona,
e também queremos ter uma maneira simples de
configurar o servidor com uma chave pública e a chave privada.
Como estamos fazendo isso como um exercício para entender HTTPS,
podemos usar uma ferramenta chamada SSL aberto que já está disponível em
nossos computadores para gerar o que é chamado de certificado auto-assinado.
As chaves autoassinadas não são aceitáveis no trabalho externo.
Mas como sabemos que estamos usando apenas para nossos fins de teste,
podemos usar certificados autoassinados,
simplesmente para entender o processo
de comunicação segura entre o cliente e o servidor.
Então, como usamos SSL aberto?
Até agora usando SSL aberto você pode gerar Chaves,
usando três comandos que eu mostro aqui.
Você executa esses três comandos nessa sequência,
conforme especificado aqui e que irá ajudá-lo a gerar
uma chave privada e um certificado que você pode disponibilizar a partir do
seu servidor HTTPS para que os clientes baixem e,
assim, obter sua chave pública para comunicação segura.
Então, esta é a operação que vamos fazer em nosso exercício que segue
esta palestra para estabelecer e emitir o serviço DPS. Então, os três passos que fazemos é
, primeiro, gerar a chave privada usando o primeiro comando.
Em seguida, vamos gerar um cert.csr que será então usado
para gerar um certificado que
pode ser distribuído para o lado do cliente pelo terceiro comando mostrado lá.
Portanto, essas etapas permitirão que você gere uma chave privada e
também um certificado correspondente que pode ser emitido para o cliente.
Novamente, para enfatizar, se você estiver executando um servidor de produção,
então você precisa obter uma chave pública, par de chaves privadas,
de uma das Autoridades de Certificação como VeriSign e Thawte Corporation.
Como o nó em si funciona para nos ajudar a configurar o HTTPS?
Agora é aqui que estou revisando brevemente o código que
usaremos no exercício que se segue para configurar nossos servidores.
Nó em si tem o HTTPS como um módulo núcleo dentro do nó.
Então vamos configurar HTTPS exigindo este módulo núcleo.
Também usaremos o módulo núcleo do sistema de arquivos porque
a chave privada e o certificado que geramos serão armazenados no lado do servidor,
e eles serão exigidos pela
sua aplicação expressa para configurar seu servidor seguro.
Então, aqui vamos usar o sistema de arquivos com
o método ReadFileSync para ler na chave privada
e o certificado dos arquivos que
geramos usando os passos que vimos no slot anterior.
Assim que esses dois valores estiverem prontos,
as opções para o servidor HTTPS serão configuradas e você poderá configurar
seu servidor seguro para fornecer comunicação baseada em HTTPS a partir do site do servidor.
Agora que você tem uma compreensão rápida de como seu HTTPS funciona
e como ele aproveita o uso de criptografia de chave pública
e criptografia de chave simétrica para
garantir uma comunicação segura entre o cliente e o servidor.
Vamos passar para o exercício para realmente configurar o
nosso servidor expresso que temos vindo a construir até agora para usar o protocolo HTTPS.