Muito bem, pessoal, no último vídeo, nós nos divertimos muito, e espero que vocês tenham brincado um pouco
com a configuração e com os homens no meio, seus dispositivos, se tiverem permissão para isso.
Neste vídeo, vamos dar uma olhada no https.
Por que ele é mais seguro do que o HTTP?
E também, como essa criptografia está sendo estabelecida?
Mas não se preocupe, apenas em um nível alto.
Você não vai entrar na toca do coelho e fazer uma análise criptográfica sobre isso.
Muito bem.
Então vamos ver.
E aqui temos nossa configuração muito bem desenhada.
Quero dizer, ele parece absolutamente realista e incrível, certo?
Isso não é nenhuma surpresa.
É isso que está acontecendo no momento.
Está bem.
Portanto, temos nosso smartphone.
O smartphone está sendo conectado via wi-fi ao nosso roteador e este está sendo conectado à nossa
VM Ubuntu, que está sendo conectada à Internet.
Isso é bem conhecido por nós no momento.
Está bem.
Mas agora vem a pergunta: por que recebemos esse tipo de sinal de aviso de erro,
seja qual for o nome que você dê a isso, se estivermos tentando fazer uma conexão HTTPS e man
in the middle?
Há algum tipo de sim.
Algum tipo de relação de confiança entre o dispositivo e o servidor.
E essa relação de confiança cria um forte canal criptográfico.
Em seguida, depois de criar esse canal, ele está sendo usado para transferir dados do smartphone
para o servidor e vice-versa.
É por isso que o HTTPS.
Isso é mais seguro?
Tudo bem.
Isso é tudo para este vídeo no momento.
Não, estou brincando.
Vamos dar uma olhada.
Sob o capô.
Ele é chamado de "under the hood" (sob o capô)?
Acho que sim.
E se não, ainda assim faremos isso.
Esta é a nossa configuração bem conhecida aqui.
E agora.
Agora, digamos que o smartphone queira abrir essa página e esta, por exemplo, example dot org.
Mas, desta vez, é HTTPS.
O smartphone agora está elaborando esse pacote, esse pacote HTTPS, e ele será enviado ao roteador.
Esse será encaminhado por meio de nossas interfaces para a Internet.
Agora esse servidor da Web percebe que a solicitação é essa, mas relacionada a https.
Portanto, o servidor da Web agora está gritando de volta para o smartphone, onde quer que ele esteja no momento, neste mundo.
Esta aqui é uma solicitação HTTPS.
Precisamos estabelecer um canal seguro aqui, portanto, precisamos executar alguma criptografia para provar que sou
realmente o example dot org.
Aqui está o meu certificado e este aqui, que foi assinado pelo Google.
Tudo bem.
Então, talvez com uma voz um pouco mais grave, mas acho que entendemos o ponto.
O servidor da Web agora está apresentando o certificado, que foi assinado pelo Google, e esse certificado será transferido
de volta para o smartphone.
Há várias outras coisas envolvidas, como a chave pública deste servidor da Web aqui.
Mas agora vamos tornar isso não mais complexo.
Portanto, nos concentramos apenas no certificado.
Muito bem.
Portanto, agora estamos enviando de volta o certificado para o cliente.
O cliente agora está extraindo o certificado e percebe que, ok, agora temos o certificado
de example dot org, mas não conhecemos example dot org.
Então, como podemos provar que esse é realmente o example dot org?
Bem, não precisamos fazer isso.
Isso já foi feito pelo Google.
O Google verificou, neste caso, que este aqui é o example dot org.
E depois de verificar isso, o Google assinou o certificado aqui com a chave privada.
Portanto, essa assinatura foi criada com a chave privada do Google.
E se esse for o caso e estivermos confiando no Google, também confiaremos que este aqui é o example
dot org.
Essa é a base do https.
Temos algumas autoridades confiáveis e tudo o que foi assinado por elas será automaticamente confiável.
Tudo bem.
Está bem.
Mas agora a questão é: como podemos verificar se esse certificado foi realmente assinado pelo
Google com a chave privada do Google e não por um terceiro aqui?
A resposta para essa pergunta é a criptografia assimétrica.
Com base nesse princípio, o Google pode assinar o certificado com a chave privada e nós podemos verificar isso
com a chave pública correspondente.
Portanto, a chave privada nunca sai da escola neste momento e permanece segura, o
que é muito importante.
Caso contrário, teríamos um grande problema com a Internet no momento.
Está bem.
Portanto, a chave privada está segura no Google, e o Google agora pode nos fornecer a chave pública para a chave privada
correspondente.
Ter essa chave pública não é absolutamente nenhum problema, pois somente a chave privada relacionada a ela pode descriptografar
esses dados.
Portanto, agora podemos distribuir essa chave para todos os outros.
E o bom dessa criptografia assimétrica é que agora podemos usar essa chave pública para verificar
se essa assinatura foi realmente assinada pelo Google, pois, com a chave pública,
podemos verificar se essa assinatura foi criada com a chave privada correspondente, a chave privada
do Google aqui.
E é exatamente isso que o smartphone está fazendo no momento.
Então, o smartphone procura por ele.
O smartphone verifica em seu armazenamento interno de certificados se há alguns carros.
A chave pública para essa chave privada está aqui.
Portanto, a chave pública do Google.
E sabe de uma coisa?
É claro que está lá.
Portanto, esse servidor foi assinado pelo Google.
Portanto, podemos confiar que example dot org está relacionado a este servidor aqui que tem a chave pública.
Absolutamente nenhum problema.
Obter a chave privada seria absolutamente perigoso.
A Internet seria definitivamente interrompida.
E, portanto, o Google não está cedendo ou colocando sua chave privada em outros servidores.
Ela está sendo mantida em sigilo no Google, e o Google apenas assina outros certificados com essa chave privada, que agora
pode ser comprovada.
Tudo bem.
Depois de verificar que este servidor aqui é realmente example dot org e não um invasor mal-intencionado
que está tentando falsificar este aqui, podemos agora estabelecer nossa mágica.
Com este aqui, podemos criar nosso canal criptografado entre o smartphone e o servidor da Web.
E sabe de uma coisa?
Isso é possível.
Mesmo tendo um invasor diretamente à nossa frente, ou não apenas à nossa frente, também estamos usando os dispositivos
de rede que esse ataque está fornecendo para nós.
Portanto, um invasor está estabelecendo uma conexão "man in the middle" por meio de seus próprios dispositivos,
que estamos usando.
E, mesmo assim, o invasor não consegue descriptografar esse canal aqui.
Isso não é incrível?
Com certeza é.
Então, como isso é possível?
Como esses dois componentes podem trocar dados de segurança, que não podem ser obtidos por esse invasor
aqui?
Bem, vamos dar uma olhada neste na mesa digitalizadora.
Vamos descobrir como esse incrível recurso funciona.
Está bem.
Então, primeiro, vamos dar uma olhada na diferença entre criptografia simétrica e assimétrica.
E não se preocupe, estamos fazendo isso em um nível elevado.
Na criptografia simétrica.
Temos um segredo compartilhado e o usamos para criptografar e descriptografar a mensagem.
Veja um exemplo.
Bob deseja enviar uma mensagem para Ellis, mas não em texto simples.
Bob deseja criptografar essa mensagem e usar esse segredo P. W. ponto de exclamação como uma espécie de senha.
Se Ellis agora quiser ver essa mensagem, ela precisará saber a senha para descriptografá-la.
Portanto, ambos precisam saber o mesmo segredo.
E esse é um problema em nosso caso no momento.
Por quê?
Porque não podemos simplesmente enviar o segredo para Ellis por fio.
Um invasor obteria essa senha imediatamente e também poderia descriptografar essa mensagem posteriormente.
Portanto, precisamos de algum tipo de criptografia assimétrica.
E já falamos sobre isso.
Mas, mesmo assim, vamos recapitular isso rapidamente.
Mais uma vez, Ellis e Bopp.
Mas, desta vez, estamos falando de criptografia assimétrica, o que significa que não estamos usando o mesmo segredo para
descriptografar e criptografar uma mensagem.
Bob tem, portanto, uma chave pública e uma privada.
O mesmo vale para Ellis.
Bob agora está obtendo a chave pública de Ellis por meio da conexão e usa essa chave para criptografar a mensagem,
criptografando a mensagem com a chave pública de Ellis, e somente a chave privada de Ellis é capaz de descriptografá-la.
A chave privada indica.
Pelo menos essa chave não foi transferida pelo cabo e agora pode ser usada para descriptografar essa mensagem
por Ellis.
Se Ellis quiser responder a Bob, ela precisará obter a chave pública de Bob.
Mais uma vez, isso pode ser facilmente transferido pelo fio e, posteriormente, essa chave está sendo usada para criptografar
a mensagem.
Isso significa que, após a criptografia, nem mesmo Ellis é capaz de descriptografar essa mensagem.
Isso só pode ser feito com a chave privada de Bob.
E Bob não está divulgando sua chave privada.
Portanto, essa chave privada também fica com Bob.
Isso significa que essas chaves públicas podem ser facilmente trocadas, mesmo que um invasor esteja entre elas,
porque elas só podem ser usadas para escrever mensagens criptografadas para as pessoas correspondentes, portanto, não podem ser usadas
para descriptografar essas mensagens.
Isso só pode ser feito com a chave privada, com a chave privada correspondente.
Está bem.
Portanto, agora sabemos um pouco sobre criptografia simétrica e assimétrica.
Portanto, a criptografia simétrica não é uma opção para nós se tivermos que enviar uma senha por fio.
Essa é uma ideia absolutamente ruim, porque o invasor simplesmente obtém a senha e pode descriptografar
nosso tráfego facilmente, certo?
Com certeza.
Está bem.
Então, nada demais, simplesmente por não usar criptografia assimétrica baseada em chave pública e privada.
Sim, isso funcionaria, eu acho.
Mas vamos imaginar a quantidade de coisas que temos que lidar lá.
Portanto, cada cliente precisa ter uma chave privada e uma chave pública.
Quem está gerando essas chaves?
Quem tem acesso a essas chaves?
Este é o usuário.
E se ele for revogado?
Portanto, temos que lidar com todas essas coisas para bilhões de certificados.
Portanto, isso seria absolutamente ridículo.
O outro problema que vejo no momento é que vamos supor que a chave privada seja comprometida.
Portanto, se um invasor tiver acesso à chave privada, ele poderá descriptografar todo esse
tráfego de rede para essa pessoa aqui.
Sim, é claro.
Mas como devemos lidar com isso agora?
Se isso for tudo, não é uma opção.
A resposta para essa pergunta é que não precisamos, porque há muitas pessoas inteligentes por aí que querem
a solução para nós.
E dois deles são o sr. Diffie e o sr. Hellman.
E todo esse conceito por trás disso é incrível.
E isso é algo que vamos analisar agora.
Então, vamos dar uma olhada rápida em alto nível nessa troca de chaves via Diffie Hellman.
E isso é absolutamente alucinante.
Portanto, vamos dar uma olhada.
Está bem.
Portanto, o problema que ainda temos é que queremos estabelecer uma conexão segura com o nosso servidor
Web, mesmo que um invasor esteja sentado em uma posição intermediária entre nós e o servidor Web.
E também queremos criptografar nossos dados de uma maneira diferente para cada conexão que estivermos fazendo.
Portanto, isso é ridículo.
E esse é o problema que, se Hellman resolver, tudo bem, então vamos ver isso.
Na maioria das vezes, as pessoas tentam explicar essa troca de chaves com algumas cores, mas eu gostaria de tentar
de outra forma.
Estou tentando explicar isso com base em alguns truques.
Portanto, no final, Ellis e Bob devem ter exatamente a mesma corda com exatamente os mesmos componentes e exatamente a
mesma quantidade de mililitros.
Portanto, bebidas idênticas.
Tudo bem.
Está bem.
Então, aqui estamos nós com LZ e Pop.
Começamos com uma criptografia assimétrica porque, caso contrário, o invasor poderia facilmente detectar nossos
componentes e o jogo acabaria.
Portanto, criptografia assimétrica significa que temos uma parte privada e uma parte pública.
Tudo bem.
Sim.
Eles estão falando sobre misturar uma bebida, que é idêntica e não pode ser misturada por um invasor que obtém todas
as informações por estar sentado entre nós.
Então, vamos começar uma lição, Bob.
É preciso se comprometer com uma rota básica que ambos estão colocando em suas bebidas.
Neste caso, agora, é uma maçã.
E este aqui, o candidato está misturado e a verdade está sendo colocada em seus óculos e o atacante tem essas
informações.
Mas isso está bom no momento.
Está bem.
Agora, Bob está colocando essa fruta em sua bebida.
Você não sabe o que é essa fruta?
É claro que não.
Porque esse é o segredo do Bob.
E também não sabemos quanto dessa fruta Bob está colocando em sua bebida.
Pode ser 42 mililitros ou 122 mililitros.
Não sabemos isso.
Ellis está fazendo o mesmo.
E não, isso não é um limão.
Esse é o segredo do LLS.
Portanto, menos segredos, frutas.
Ambos estão tomando a maçã e suas próprias frutas misturadas em suas bebidas no momento.
Mas como Ellis agora obtém as informações de Bob sobre qual fruta e quanto dessa fruta ela precisa
colocar em sua bebida?
A resposta é que ela não tem.
Uma loucura, não é?
Porque, no final, os dois drinques precisam ser absolutamente idênticos.
Mas como?
A pista é que Bob e Liz estão trocando seus óculos.
Essa também é a razão pela qual estamos tomando a maçã no início, porque, caso contrário, eu veria imediatamente
a quantidade e talvez também provaria qual fruta ambos estão usando.
Mas junto com uma maçã, isso é absolutamente impossível.
E agora você já pode ver o que está acontecendo a seguir.
Ambos estão pegando seus copos de ponto e inserindo suas próprias frutas.
Mais uma vez, eles sabem qual fruta e também sabem quanto de sua própria fruta precisam colocar de
volta nesse copo aqui, porque esse é seu próprio segredo.
Incrível, não é?
Porque agora eles estão tomando exatamente os mesmos drinques.
Mas Ellis não conhece o fruto secreto do pop.
E o pai não conhece o fruto de Alice.
Eles agora estão tomando um drinque, o que pode ser visto como um segredo compartilhado.
Essa bebida secreta pode agora ser usada como uma chave simétrica para criptografar e descriptografar os dados entre
Alice e Bob.
E eles podem escolher uma nova chave para cada conexão que estão fazendo, pois só precisam pensar
em alguma receita de coquetel ou, na realidade, em números primos muito grandes.
Isso é absolutamente ridículo.
O invasor sentado entre eles não percebe o que está acontecendo e toda a conexão já foi
estabelecida de forma segura.
Está bem.
Agora, vimos como podemos estabelecer uma conexão segura, mesmo que um invasor esteja sentado
em uma posição intermediária entre nós e os invasores, que também possuem o hardware.
Portanto, mesmo assim, podemos estabelecer uma conexão segura com nosso parceiro de conexão.
E isso é absolutamente incrível.
Mas, é claro, não para o invasor, o que é bom, mas não no nosso caso agora, porque nós, como invasores,
queremos entrar nessa conexão.
Quebrar as criptomoedas definitivamente não é uma opção, como já vimos agora.
Isso é algo que não podemos contornar.
Portanto, se quebrar as criptomoedas não é uma opção para nós no momento, o que mais podemos fazer?
Porque precisamos chegar a essa posição.
Precisamos descriptografar o tráfego desse aplicativo móvel, pois é por isso que estamos aqui.
Queremos analisar e hackear esse aplicativo.
Então, como podemos fazer isso?
A solução mais fácil para esse caso seria tornar-se uma autoridade inválida.
E isso parece absolutamente ridículo, porque é algo que nunca acontece no mundo real
on-line neste momento.
Mas não estamos no mundo real on-line.
Estamos no smartphone.
Portanto, temos o controle do nosso smartphone.
E, portanto, também podemos ajustar essas configurações.
Portanto, se formos capazes de dizer ao smartphone que somos uma autoridade confiável com nossos perpetradores, por exemplo, então
nossos perpetradores poderão reivindicar todos os certificados que desejamos ter no momento.
Por exemplo, podemos pegar nossa certidão de nascimento e dizer que este certificado é, por exemplo, ponto
com ou este é, por exemplo, ponto org e que somos uma autoridade confiável.
Portanto, o cliente também está confiando em nós.
O bom desse caso é que não precisamos nos preocupar com essa criptografia.
Quero dizer, toda a troca de contaminação ainda está acontecendo, mas está acontecendo conosco.
Portanto, somos o parceiro de conexão no momento e, portanto, não precisamos quebrar a criptografia
porque somos um parceiro válido no momento em que o cliente está se conectando.
E, é claro, precisamos ser capazes de descriptografar essa mensagem, pois ela é dirigida a nós neste exato momento.
Nós somos o parceiro que deve ler essa mensagem do cliente e, portanto, também precisamos ter essa troca de
chaves de desenvolvimento.
Mas, desta vez, estamos recebendo todas essas informações e, portanto, também podemos misturar exatamente
a mesma bebida, analisar o tráfego ou descriptografar esses pacotes.
Tudo bem.
Vamos dar uma olhada em como podemos fazer isso.
Está bem.
Então, vamos adicionar nosso atacante aqui e ver o que acontece, como essa interação funciona.
Muito bem, lá vamos nós.
Aqui temos agora o nosso atacante e o smartphone ainda está fazendo uma conexão com https example dot org.
Tudo bem.
Ainda temos nosso servidor da Web aqui.
Este é o nosso exemplo de ponto de organização e servidor da Web.
Agora, o smartphone está fazendo essa conexão, mas o invasor fica no meio dessa conexão.
Então, é assim.
O servidor da Web ainda pode apresentar o certificado, mas isso é absolutamente irrelevante neste momento, pois
esse tipo de conexão não chega a esse servidor da Web.
O smartphone agora vê nossa máquina atacante.
Entre essa conexão, o invasor precisa apresentar seu próprio certificado, pois ele não
tem um certificado inválido, que foi assinado por uma autoridade que prova que example dot org
está localizado nessa máquina.
Portanto, é claro que esse não é o caso, pois nenhuma autoridade afirmaria que o example dot org está localizado
no computador desse invasor aqui.
Tudo bem.
Está bem.
Portanto, o smartphone não recebe o certificado do invasor e o consulta.
Esse certificado não é conhecido pelo smartphone e também não foi assinado por uma autoridade
válida, como, por exemplo, o Google ou a Comodo ou o que você quiser usar aqui.
Isso significa que o smartphone simplesmente diz ao invasor: "Não, não vou fazer
uma conexão com essa instância porque você não é example dot org".
Caso contrário, ele teria sido assinado por uma autoridade válida ou, pelo menos, o certificado estaria incluído em
meu armazenamento de certificados aqui.
Portanto, o cliente simplesmente interrompe essa conexão.
Assim, a conexão é encerrada e o cliente não está mais se comunicando com o invasor até que
ele forneça um certificado válido.
Mas é claro que isso não é possível porque nenhuma autoridade assinará um certificado para o invasor
em um domínio que ele não possui.
Portanto, neste momento, parece estar perdido.
No momento, não podemos interagir com esse cliente.
E o cliente também não confia em nós.
Quero dizer, o cliente tem motivos absolutamente válidos para não confiar em nós no momento, mas como ainda podemos estabelecer
esse tipo de conexão?
O cliente precisa confiar em nós e, se não obtivermos uma assinatura de uma autoridade válida, a única chance que temos
no momento é adicionar nosso certificado ao armazenamento de certificados do cliente.
Portanto, se você enviar nosso certificado para o cliente, ele será inserido no armazenamento de certificados
do cliente, como este aqui.
E agora, se o cliente estiver estabelecendo uma conexão com https example dot org e nós estivermos entre essa
conexão, o cliente dará uma olhada no armazenamento de certificados e verá o certificado lá.
Então, o cliente está nos dizendo, ok, eu confio em você neste momento e passo.
Pesca e conexão conosco.
Tudo o que precisamos fazer agora é encaminhar essa conexão ao site real para example dot org.
Mas isso não é absolutamente nenhum problema, porque nós, como clientes, podemos fazer ou estabelecer uma conexão HBS com
o example dot org e podemos simplesmente passar esses dados entre esses dois componentes.
Portanto, entre o smartphone e o example dot org, ambos os canais estão sendo criptografados, mas nós, como invasores,
interrompemos essa conexão para que possamos dar uma olhada nos dados e também nos referirmos
a eles no aplicativo real.
Portanto, estamos em um proxy real em uma conexão HTTPS.
Portanto, o único vetor de ataque relacionado a isso é adicionar nosso certificado ao cliente.
Essa também é a explicação para a mensagem de erro que recebemos no último vídeo aqui.
Portanto, estou recebendo uma mensagem de erro informando que esse certificado não é confiável.
Portanto, agora sabemos o motivo por trás disso.
E no próximo vídeo, nos livramos dessa mensagem simplesmente instalando nosso próprio certificado em nosso smartphone.
Então, esse site será confiável e não receberemos mais nenhum aviso.
Tudo bem.
Está bem.
Portanto, se você tiver alguma dúvida sobre esse tópico aqui, escreva-me uma mensagem.
Ficarei muito feliz, como sempre, se eu receber algum feedback sobre isso aqui.
Está bem.
Caso contrário, estou ansioso para vê-lo no próximo vídeo.