O cadeado verde desmistificado: como funciona o handshake SSL?

Todos os dias, ao navegar na Web com segurança em mente, você pensa no famoso cadeado verde próximo ao endereço URL do site em seu navegador e na versão HTTPS do protocolo de transferência de dados. Neste artigo, vamos descobrir por que o HTTPS é realmente seguro e como a comunicação está sendo protegida contra espionagem por terceiros.

Primeiro, vamos apresentar brevemente os dois conceitos criptográficos básicos: assinatura digital e criptografia, vamos mergulhar em um processo chamado SSL handshake , que é executado antes que o cliente e o servidor comecem a trocar a comunicação e é usado para estabelecer um contexto criptográfico seguro. Terminaremos com informações sobre como aumentar ainda mais a segurança com uma etapa opcional chamada autenticação de certificado de cliente.

Criptografia de chave pública 101: par de chaves

Conheça Alice e Bob, duas pessoas que decidiram usar métodos criptográficos para trocar suas mensagens privadas com segurança. A primeira escolha que eles têm que enfrentar é entre dois tipos diferentes de criptografia: criptografia de chave simétrica e assimétrica (também chamada de criptografia de chave pública).

Mas espere, o que são essas chaves ? Basicamente, podemos simplificar que uma chave é uma sequência aleatória de caracteres. Podemos usar essa sequência para transformar (fazer uma certa operação criptográfica) em uma mensagem – vamos nos aprofundar nisso em breve.

Criptografia de chave simétrica

Ao usar criptografia de chave simétrica, um remetente gera uma chave e a duplica para o destinatário. O remetente salva a chave original e uma duplicata é entregue ao destinatário. A mesma chave é usada para operações de criptografia em ambas as extremidades da comunicação.

E quais são os principais benefícios e desvantagens da criptografia de chave simétrica?

Criptografia de chave assimétrica

Ao usar a criptografia de chave assimétrica, o remetente e o destinatário geram um par de chaves – uma chave pública e uma chave privada. As chaves são matematicamente acopladas umas às outras para trabalharem juntas em várias operações de criptografia. Tanto o remetente quanto o destinatário salvam suas chaves privadas com segurança, mas podem trocar chaves públicas sem precauções especiais. Eles podem até usar uma espécie de “páginas amarelas de chaves públicas” – um servidor de chave pública para enviar suas chaves públicas para serem acessadas por qualquer pessoa.

Quais são os prós e contras da criptografia de chave assimétrica?

Como uma configuração de criptografia assimétrica é mais segura, Alice e Bob decidiram seguir com ela! Agora eles podem aproveitar isso e começar a pensar em garantir a segurança e a integridade da comunicação.

Criptografia de chave pública 101: criptografia

Quando Alice envia uma mensagem para Bob, ela quer ter certeza de que ninguém mais pode ver qual é o conteúdo. Ela decide criptografar a mensagem. Para conseguir isso, Alice deve primeiro obter a chave pública de Bob de um servidor de chaves ou diretamente de Bob por meio de um canal de comunicação. Depois que Alice obtém a chave, ela pode aplicar uma operação de criptografia usando a chave pública de Bob na mensagem que deseja enviar.

De um modo geral, neste processo, a mensagem está sendo tomada por um algoritmo criptográfico (também conhecido como cifra) em blocos (mais comumente) e algumas operações de bits entre a mensagem e a chave são realizadas, produzindo uma saída que é a mensagem criptografada (também conhecido como texto cifrado). . Quando Bob recebe a mensagem criptografada, ele é a única pessoa que pode descriptografá-la com sua chave privada.

Observação:

• Criptografia de mensagem – o remetente criptografa uma mensagem com a chave pública do destinatário
• Descriptografia da mensagem – o receptor descriptografa uma mensagem com sua chave privada

Criptografia de chave pública 101: assinatura

Além de evitar que o conteúdo da mensagem seja revelado, é igualmente importante poder confirmar a identidade do remetente e verificar se a mensagem não foi alterada. Uma assinatura digital (um objeto separado anexado à mensagem) é usada exatamente por esses dois motivos.

Alice primeiro usa um algoritmo de hash para desenvolver um hash de mensagem para gerar sua assinatura. Hashing é computar uma função matemática unidirecional em uma mensagem que produz uma saída de valor fixo mais curta – diferente para uma entrada diferente. Em seguida, ela usa sua chave privada para criptografar (assinar) o hash gerado.

Em seguida, quando Bob recebe a mensagem e a assinatura, ele pode primeiro descriptografar a assinatura usando a chave pública de Alice. Quando isso acontecer, ele saberá que a assinatura foi realmente gerada por Alice (caso contrário, a descriptografia com sua chave pública falharia).

Em segundo lugar, Bob pode pegar a mensagem e fazer um hash usando o mesmo algoritmo que Alice tinha antes e confirmar que seu hash da mensagem é o mesmo que o gerado por Alice. Quando os hashes correspondem, ele sabe que a mensagem não foi adulterada.

Observação:

• Gerando assinatura – o remetente criptografa (assina) o hash da mensagem com sua chave privada e cria uma assinatura
• Verificando assinatura – o receptor primeiro descriptografa o hash da mensagem da assinatura e verifica se um hash calculado por ele corresponde ao da assinatura
• Criptografia e assinatura podem ser usadas separadamente , mas para maior segurança, elas geralmente são combinadas. Portanto, a maioria das funções de criptografia que você pode encontrar são chamadas encryptSignMessage() , decryptVerifyMessage() , etc.

Espero que você não esteja tendo problemas para acompanhar a história de Alice e Bob. Deixe-me ilustrar todo o fluxo mais uma vez para garantir que tudo esteja claro e resumir as coisas.

1. Alice quer enviar uma mensagem para Bob
2. Alice pega sua chave privada e gera uma assinatura
3. Alice pega a chave pública de Bob e criptografa a mensagem
4. Alice envia a mensagem para Bob
5. Bob pega a chave pública de Alice e verifica a assinatura
6. Bob usa sua chave privada para descriptografar a mensagem

Tudo bem, isso é teoria suficiente. Agora vamos ver como tudo isso é usado em HTTPS!

Aperto de mão SSL

Diga olá por favor

Quando um cliente inicia uma conexão com um servidor, primeiro é fundamental fazer uma introdução adequada para estabelecer o contexto criptográfico para o restante da comunicação. Isso pode ser feito na etapa HTTPS CONNECT, muito antes de analisar cabeçalhos e corpos de solicitação. Tudo começa com o cliente enviando uma mensagem de saudação ao cliente .

Mais importante ainda, a mensagem contém os algoritmos de criptografia que o cliente entende e algum material adicional, como algoritmos de compressão suportados, versões de protocolo, id de sessão, etc. contém o certificado do servidor com a chave pública do servidor (sim, o processo é baseado em criptografia de chave pública – o mesmo método que Alice e Bob escolheram).

Autoridade de certificação

Agora é hora de dar as boas-vindas ao nosso próximo convidado no palco: uma autoridade de certificação (CA). O nome parece sério – mas é apenas uma entidade terceirizada com muito crédito de rua que é basicamente considerada confiável em todo o mundo. Essa entidade pode validar a identidade de um servidor e colocar sua assinatura digital junto com o certificado do servidor (semelhante a Alice ao enviar mensagens para Bob).

Verificação do certificado

Agora vamos finalmente considerar o título do cadeado verde ao lado do endereço de URL do seu navegador.

Cada cliente da Web tem uma lista agrupada de chaves públicas de autoridades de certificação conhecidas e confiáveis ​​. Você deve se lembrar que no início do artigo, mencionei que a assinatura é gerada usando a chave privada de um remetente e pode ser verificada usando a chave pública de um remetente. Bem, isso é exatamente o que o cliente faz . Ele passa pela lista de CAs confiáveis ​​agrupadas e verifica se a assinatura do certificado do servidor pertence a uma das CAs confiáveis. Se isso acontecer, ele aceita o certificado – e é nesse momento que o cadeado fica verde .

Mas isso é apenas um primeiro passo, que ainda não tem nada a ver com segurança. Qualquer um pode copiar qualquer certificado de chave pública, colocá-lo em um servidor e apresentá-lo a um cliente conectado, certo?

Depois que o cliente verifica o certificado do servidor, ele cria uma chave simétrica para criptografar a comunicação. Mas, como mencionei no início, o problema com as chaves simétricas é que elas são vulneráveis ​​a serem interceptadas durante o transporte. Nesta etapa, cliente e servidor não têm um contexto criptográfico comum. Assim, o cliente envia a chave simétrica ao servidor, mas primeiro a criptografa com a chave pública do servidor. Em seguida, o servidor o recebe e precisa da capacidade de descriptografá-lo para estabelecer uma conexão segura.

Portanto, mesmo que alguém apresentasse um certificado de chave pública roubado , essa é a etapa em que falharia. Uma chave privada válida vinculada à chave pública do certificado do servidor é essencial para descriptografar a chave simétrica. Obviamente, isso não é um problema para um servidor legítimo, pois ele tem a chave privada salva com segurança. Ele pode ser usado para descriptografar a chave simétrica e criptografar outras comunicações.

Então, para resumir, um handshake SSL é um processo no qual os tipos de criptografia simétrica e assimétrica são usados . A princípio, o par de chaves assimétricas inicia a conexão e fornece uma maneira segura para a chave simétrica viajar. Como apontamos no início, as operações de criptografia simétrica são mais rápidas, portanto, usá-lo para toda a comunicação após a configuração é benéfico. Além disso, uma vez que uma conexão segura é estabelecida, ela é reutilizada até expirar, de modo que a configuração da chave assimétrica não é feita antes de cada solicitação do cliente.

Vale ressaltar também que, na vida real, os certificados não são assinados diretamente pelas CAs confiáveis ​​mais famosas (chamadas raízes ). Ainda assim, as CAs raiz assinam certificados intermediários, que finalmente assinam o certificado do servidor – criando assim uma cadeia de certificados, que o cliente conectado verifica até que uma assinatura válida seja encontrada. Ele certamente oferece melhor segurança – quando uma das CAs intermediárias é comprometida, isso afeta menos pessoas.

Validação do certificado do cliente

Agora, há um passo opcional que podemos mencionar brevemente, pois temos todo o conhecimento necessário para entendê-lo. Um servidor pode ser configurado para solicitar e validar um certificado de cliente após estabelecer uma conexão segura para obter segurança adicional.

Isso funciona da mesma maneira - mas desta vez, o cliente envia seu certificado e o servidor analisa sua lista de autoridades de certificação confiáveis ​​e a verifica. Também vale a pena notar que o servidor está sob o controle dos desenvolvedores (ao contrário de um cliente, ou seja, um navegador da Web ou um sistema operacional móvel), para que os desenvolvedores de back-end possam modificar facilmente a lista de certificados confiáveis.

As redes corporativas costumam usar esse mecanismo. Mais frequentemente, os certificados do cliente são gerados por um sistema de gerenciamento de dispositivos instalado no dispositivo do funcionário e são assinados com um certificado raiz gerado pela empresa. O mesmo certificado também é adicionado ao ambiente de back-end. Dessa forma, o back-end corporativo pode verificar facilmente o certificado quando o cliente se conectar.

Vamos navegar pelas nossas soluções de back-end

Consulte Mais informação

Agora, para resumir, vamos ver um diagrama para todo o fluxo:

Resumo

Você chegou ao final do artigo! Espero que você já tenha entendido o mecanismo de implementação da configuração de criptografia em HTTPS e os métodos de aplicação de processos de assinatura e criptografia.

Como você sabe como as coisas funcionam, certamente deve se sentir mais confiante sobre a criptografia de dados. Ainda assim, é fundamental lembrar que um cadeado verde no seu navegador ainda não garante segurança . No contexto sensível à segurança, você também deve examinar o certificado de perto. Como se costuma dizer, prevenido é prevenido!