O que é um aperto de mão TLS?

Um handshake de segurança da camada de transporte (TLS) estabelece uma comunicação criptografada e autenticada entre um cliente (como um navegador da web) e um server. O aperto de mão envolve a troca de mensagens, concordando com criptografia algoritmos, verificando o serveridentidade do (e opcionalmente do cliente) e gerar chaves secretas para criptografar subsequente transferências de dados. É a base para a troca segura de dados, garantindo que as informações transmitidas permaneçam confidenciais e à prova de violação.

O que significa TLS Handshake?

Um handshake TLS é uma série de etapas que inicia uma conexão segura validando as partes envolvidas, selecionando parâmetros de segurança compatíveis e criando chaves de criptografia compartilhadas. O handshake determina como os dados serão criptografados, verifica a servercertificado digital e estabelece o canal seguro necessário para proteger integridade de dados e confidencialidade. É uma parte essencial do TLS, um protocolo projetado para fornecer privacidade e data security pelas redes.

Quais são os componentes de um handshake TLS?

Abaixo estão os principais componentes que tornam possível um handshake TLS.

Cliente e Server

O handshake envolve duas entidades principais: o cliente, que inicia a conexão (por exemplo, um navegador web ou outro Formulário on line), e as server, que hospeda o recurso ou serviço que o cliente deseja acessar. O cliente inicia o handshake propondo vários parâmetros para criptografia e autenticação, e o server responde com suas opções escolhidas com base nas configurações suportadas.

Conjuntos de cifras

Um conjunto de cifras é uma coleção de algoritmos criptográficos usados ​​durante o handshake e transferências de dados subsequentes. Ele inclui o algoritmo de troca de chaves, a cifra de criptografia em massa, o algoritmo de código de autenticação de mensagem e, às vezes, o algoritmo de assinatura digital. O cliente sugere uma lista de conjuntos de cifras que ele suporta, e o server seleciona uma que reconhece e considera aceitável.

Profissionais

Os certificados são documentos digitais usados ​​para confirmar a identidade de uma parte comunicante. Na maioria das conexões TLS, o server apresenta um certificado X.509, que é emitido por uma entidade confiável autoridade de certificação (CA). Este certificado vincula o server'S domínio nome para uma chave pública. O cliente verifica a cadeia de certificados para garantir que ela não foi adulterada e que foi emitida por uma CA legítima.

Chaves Públicas e Privadas

As chaves públicas e privadas são parte integrante do TLS. server mantém uma chave privada que corresponde à chave pública listada em seu certificado. Durante o handshake, essas chaves participam de operações criptográficas assimétricas. Os clientes usam a chave pública no server certificado para criptografar um pedaço de dados (como o segredo pré-mestre) e apenas o serverA chave privada de pode descriptografar .

Chaves de sessão

Uma vez que o cliente e server concordam com um conjunto de parâmetros criptográficos, eles geram simétricos chaves de sessão. Essas chaves criptografam e descriptografam mensagens durante a fase de transferência de dados, fornecendo benefícios de confidencialidade e desempenho. Algoritmos de criptografia simétrica geralmente são muito mais rápidos do que os assimétricos, e é por isso que o handshake usa métodos assimétricos para autenticação e troca de chaves, e depois volta para métodos simétricos para criptografia de dados em massa.

Como funciona o handshake TLS?

O handshake TLS normalmente se desdobra em várias etapas que garantem um canal seguro e autenticado. Cada fase tem um propósito definido e consiste em trocas de mensagens que finalizam os parâmetros de criptografia e verificam a autenticidade do server e possivelmente o cliente.

Cliente Olá

O cliente inicia o handshake enviando uma mensagem ClientHello para o server. Esta mensagem contém as seguintes informações:

• Uma lista de conjuntos de criptografia e versões de TLS suportados.
• Um valor aleatório (aleatório do cliente) usado posteriormente na geração de chaves.
• Suportado no mundo métodos (embora a compactação esteja amplamente obsoleta nas versões recentes do TLS).

ServerOlá

A server responde com um ServerOlá mensagem. Esta resposta inclui:

• A versão TLS selecionada.
• O conjunto de cifras escolhido da proposta do cliente.
• Outro valor aleatório (server aleatório).

Troca de Certificados e Chaves

A server envia seu certificado, que contém o serverchave pública junto com a cadeia de certificados. Depois disso, o server pode enviar parâmetros de troca de chaves adicionais se o conjunto de cifras escolhido exigir (por exemplo, em Diffie-Hellman ou cifras de Diffie-Hellman de curva elíptica).

O cliente verifica o servercertificado, garantindo que ele seja válido, não tenha expirado e seja assinado por uma CA confiável.

Verificação do cliente e segredo pré-mestre

Após o cliente verificar o servercertificado, ele gera um segredo pré-mestre e o criptografa usando o serverchave pública. Este segredo pré-mestre criptografado é então enviado para o server.

A server usa sua chave privada para descriptografar o segredo pré-mestre, e ambas as partes derivam chaves de sessão do segredo pré-mestre, do cliente aleatório e do server aleatória.

Finalização do aperto de mão

Tanto o cliente como server enviam mensagens “Finished” entre si, que são criptografadas com as chaves de sessão recém-derivadas. Essas mensagens verificam se as chaves acordadas estão funcionando corretamente e se nenhuma adulteração ocorreu.

Depois que essas mensagens são trocadas e verificadas com sucesso, o handshake é concluído e as comunicações subsequentes são criptografadas usando as chaves de sessão.

Quando ocorre um handshake TLS?

Um handshake TLS ocorre sempre que um cliente inicia uma nova conexão segura com um server sobre TLS. Cenários comuns incluem:

• Acessando um site usando HTTPS (HTTP sobre TLS).
• Iniciando email seguro comunicações (como SMTPS, IMAPS ou POP3S).
• Conectar-se a aplicativos seguros que dependem de TLS para criptografia (por exemplo, Túneis VPN ou seguro lima transferências).

O handshake se repete se uma nova sessão for estabelecida ou se uma renegociação TLS for acionada para atualizar as chaves criptográficas para conexões de longa duração.

Exemplo de handshake TLS

Abaixo está um passo a passo de como um handshake HTTPS (HTTP sobre TLS) típico ocorre entre um cliente e um server.

Etapa 1: o cliente solicita uma página segura

O navegador da web de um usuário inicia uma conexão segura enviando uma mensagem ClientHello para o server em “example.com”. A mensagem ClientHello faz parte do Protocolo de Handshake TLS e contém várias informações importantes:

• Versões de protocolo suportadas. O cliente propõe uma ou mais versões do TLS (por exemplo, TLS 1.2, TLS 1.3) que ele é capaz de usar.
• Cliente aleatório. Um 32-byte valor aleatório gerado pelo cliente, posteriormente usado na derivação de chaves.
• ID da sessão ou tíquete da sessão. Se o cliente se conectou recentemente ao mesmo server e possui um tíquete de sessão ou ID de sessão válido, ele pode oferecê-lo para solicitar a retomada da sessão, o que pode pular ou encurtar algumas etapas do handshake.
• Conjuntos de cifras. Essas suítes são uma lista de algoritmos criptográficos que o cliente suporta. Cada suíte de cifras especifica um mecanismo de troca de chaves (por exemplo, RSA, ECDHE), um algoritmo de criptografia (por exemplo, AES) e um código de autenticação de mensagem ou algoritmo de tag de autenticação (por exemplo, SHA256).
• Extensões. As implementações modernas de TLS incluem várias extensões, como server indicação de nome (SNI), que indica a hostname o cliente está tentando alcançar. Extensões adicionais podem indicar curvas elípticas suportadas, algoritmos de assinatura e outros parâmetros que melhoram a segurança ou o desempenho.

Ao receber este ClientHello, o server examina os conjuntos de cifras propostos e as versões TLS para determinar se ele suporta algum deles. O handshake TLS continua somente se o server encontra pelo menos um conjunto compatível de parâmetros.

- Server Responde

Após processar o ClientHello, o server responde com um ServerOlá mensagem. Vários elementos-chave estão incluídos:

• Versão do protocolo escolhido. O server seleciona uma versão do TLS (por exemplo, TLS 1.2) que tanto o cliente quanto server .
• Server acaso. Outro valor aleatório de 32 bytes gerado pelo server, usado com o cliente aleatório para derivar chaves compartilhadas.
• Seleção de conjunto de cifras. Da lista do cliente, o server escolhe um único conjunto de cifras que ele suporta. Por exemplo, ele pode escolher uma troca de chaves ECDHE_RSA, criptografia AES_128_GCM e SHA256 para autenticação de mensagens.
• ID da sessão ou novo tíquete de sessão. Se o server suporta retomada de sessão, ele pode aceitar o ID de sessão proposto pelo cliente ou fornecer um novo.
• Extensões. O server inclui respostas de extensão relevantes, indicando quaisquer parâmetros ou restrições específicas.

Seguindo as ServerOlá, server normalmente envia mensagens de handshake adicionais:

• Certificado. O server transmite sua cadeia de certificados, que inclui seu certificado de entidade final (o real server certificado) e quaisquer certificados intermediários necessários para vinculá-lo a uma autoridade de certificação raiz (CA).
• Server troca de chaves. Dependendo do conjunto de cifras escolhido, o server fornece parâmetros de troca de chaves (por exemplo, chave pública Diffie-Hellman efêmera) que o cliente usará para gerar um segredo compartilhado.
• Solicitação de certificado (opcional). Se o server requer autenticação de cliente, ele solicita um certificado de cliente neste estágio. Isso é menos comum em navegação típica na web, mas mais frequente em ambientes que precisam de TLS mútuo.

Etapa 3: Validação do certificado

O cliente examina o serverCertificado do para garantir que a conexão seja realmente com o host pretendido e não com um impostor:

• Verificação da cadeia de certificados. O cliente verifica se o serverO certificado é emitido e assinado por uma CA confiável. O navegador ou sistema operativo mantém um armazenamento de certificados raiz confiáveis. O navegador também verifica certificados intermediários para formar uma cadeia de confiança válida até uma CA raiz reconhecida.
• Expiração e validade. O cliente inspeciona as datas “Não antes” e “Não depois” do certificado para confirmar se o certificado é válido no momento.
• Correspondência de nome de domínio. O cliente confirma que o nome de domínio listado no certificado (comumente encontrado no campo Nome Alternativo do Assunto) corresponde a “example.com” ou a qualquer domínio que tenha sido solicitado.
• Verificação de revogação. O cliente pode usar a lista de revogação de certificados (CRL) ou o protocolo de status de certificado on-line (OCSP) para verificar se o certificado ou qualquer certificado intermediário foi revogado.

Se qualquer parte do processo de validação falhar, como uma assinatura inválida, certificado expirado ou nome de domínio incompatível, o cliente normalmente encerra a conexão ou exibe um aviso ao usuário.

Etapa 4: Troca de chaves e geração de chaves de sessão

Uma vez que o cliente tenha validado o server(e opcionalmente enviou seu próprio certificado, se solicitado), o cliente prossegue com a troca de chaves:

• Troca de chaves do cliente. Se uma troca de chave RSA for usada, o cliente gera um segredo pré-mestre e criptografa-o com o serverchave pública (obtida do server certificado). Se um conjunto de cifras ECDHE ou DHE for usado, o cliente também fornece sua própria chave pública efêmera para cálculos Diffie-Hellman.
• Descriptografia ou computação de chave compartilhada. O server decifra o segredo pré-mestre com sua chave privada ou, no caso de Diffie-Hellman/ECDHE, combina o segredo do cliente e serverchaves públicas para calcular um segredo compartilhado.
• Derivação do segredo mestre. Usando o segredo pré-mestre (ou segredo compartilhado DH), o cliente e server ambos derivam um segredo mestre. Essa derivação também envolve o cliente aleatório e server aleatório. Funções pseudoaleatórias (como aquelas no TLS 1.2 ou o “Handshake Secret” no TLS 1.3) são usadas para garantir forte aleatoriedade criptográfica.
• Criação de chave de sessão. Do segredo mestre, o cliente e server gerar chaves simétricas separadas para criptografar dados de saída, descriptografar dados de entrada e verificar a integridade da mensagem. Essas chaves de sessão são normalmente negociadas para serem efêmeras (especialmente em cifras baseadas em ECDHE), o que fornece sigilo para a frente.

Etapa 5: Transferência segura de dados

Depois que ambos os lados derivam as chaves de sessão, o cliente e server exchange Acabado mensagens:

• Mensagens finalizadas. Cada lado computa um hash criptográfico de todas as mensagens de handshake enviadas até agora (a transcrição do handshake) e o criptografa com as chaves de sessão recém-estabelecidas. Essas mensagens “Finished” verificam se ambas as partes compartilham o mesmo estado de handshake e se nenhuma adulteração ocorreu.
• Confirmação de aperto de mão. O cliente e server confirme o recebimento da mensagem Finished um do outro. Se os hashes corresponderem, isso indica que o handshake foi concluído com sucesso e segurança.
• Dados de aplicação criptografados. Dados subsequentes — como HTML arquivos, imagens ou qualquer outro conteúdo da camada de aplicação — é criptografado com a chave simétrica acordada. A criptografia garante a confidencialidade, enquanto a criptografia hash ou MAC (dependendo do conjunto de cifras) garante a integridade.
• Persistência de conexão e retomada de sessão. Se qualquer um dos lados suportar a retomada de sessão TLS, eles podem reutilizar o segredo mestre negociado para uma conexão futura. Isso reduz a sobrecarga de executar um handshake completo novamente.

Uma vez concluída a fase de handshake, o navegador e server comunicar por meio de um canal seguro. Os navegadores geralmente exibem um ícone de cadeado ou indicador semelhante na barra de endereço para mostrar que a conexão é criptografada e autenticada usando TLS.

Por que os handshakes TLS são importantes?

Um handshake TLS fornece um método para estabelecer comunicações seguras em redes que podem ser suscetíveis a espionagem ou adulteração.

 Vários benefícios surgem de um aperto de mão bem-sucedido:

• Autenticação. O cliente tem a garantia de serveridentidade de, prevenindo ataques man-in-the-middle.
• Confidencialidade. Todo o tráfego que segue o handshake é criptografado, garantindo que partes não autorizadas não consigam ler os dados.
• Integridade de dados. A autenticação de mensagens garante que os dados transmitidos não foram alterados durante o trânsito.

O processo de handshake, por meio do uso de algoritmos criptográficos e certificados, estabelece uma camada robusta de confiança que protege as informações durante o trânsito.

O que acontece se um handshake TLS falhar?

Um handshake TLS com falha resulta na incapacidade de criar uma conexão segura. A conexão é frequentemente encerrada, e os usuários podem encontrar mensagens de erro como “SSL / TLS “Falha no handshake” ou “Não foi possível estabelecer uma conexão segura”.

A falha ocorre quando problemas como versões incompatíveis de TLS, certificados inválidos, certificados expirados ou relógios de sistema incorretos impedem uma negociação bem-sucedida.

Como corrigir um handshake TLS?

Administradores de sistema e os usuários finais podem resolver falhas de handshake abordando as causas raiz:

• Atualizar ou instalar certificados válidos. Você deve substituir certificados expirados ou inválidos. Os provedores de hospedagem e administradores devem garantir que os certificados sejam assinados por CAs confiáveis ​​e permaneçam atualizados.
• Verifique a configuração e os protocolos suportados. Garantir que tanto o cliente como server suportar as mesmas versões TLS e conjuntos de cifras é crucial. Desabilitar protocolos antigos como SSLv3 ou TLS 1.0 elimina vulnerabilidades e evita falhas de handshake relacionadas a métodos de criptografia obsoletos.
• Sincronizar relógios do sistema. Relógios de sistema precisos são importantes para validar os tempos de expiração e validade do certificado. A server ou o cliente com a configuração de hora errada pode rejeitar certificados válidos.
• Verificar lojas de confiança da CA. O sistema operacional ou aplicativo do cliente mantém uma lista de CAs confiáveis. Verificar se a CA raiz ou intermediária relevante está presente e não revogada ajuda a evitar erros de handshake.
• Inspecionar server • Configuração. Mal configurado servers (por exemplo, prioridades incorretas de conjuntos de cifras ou cadeias de certificados incompletas) geralmente levam a problemas de handshake. Examinando server logs e configurações ajudam a identificar a incompatibilidade e permitem uma resolução rápida.

Qual é a diferença entre handshake SSL e TLS?

O termo “handshake SSL” refere-se ao processo de handshake usado pelo camada de soquetes seguros (SSL) protocolo, que era um padrão anterior para criptografar e proteger dados. O handshake TLS é a evolução moderna do SSL, oferecendo medidas de segurança mais fortes e algoritmos criptográficos atualizados.

Embora os fluxos de trabalho sejam semelhantes, o TLS introduziu melhorias em relação ao SSL, incluindo conjuntos de cifras aprimorados, melhor manuseio de certificados e mecanismos criptográficos mais robustos. O SSL foi descontinuado devido a vulnerabilidades conhecidas, e a maioria dos sistemas modernos usa o TLS para comunicações seguras.

Muitas referências ainda usam “SSL” para descrever o handshake seguro, mesmo quando o TLS é usado por baixo dos panos, mas o termo mais preciso nas implementações atuais é “handshake TLS”. O princípio básico continua o mesmo: um processo de handshake negocia parâmetros de segurança, troca certificados e estabelece chaves compartilhadas para comunicação criptografada.