Se já navegou num URL HTTPS através de um browser, já experimentou o aperto de mão SSL. Mesmo que você não note, o navegador e o site estão criando uma conexão HTTPS usando o aperto de mão SSL unidirecional.
O objetivo principal de um aperto de mão SSL é fornecer privacidade e integridade de dados para a comunicação entre um servidor e um cliente. Durante o aperto de mão, servidor e cliente irão trocar informações importantes necessárias para estabelecer uma conexão segura.
Existem dois tipos de apertos de mão SSL descritos como SSL unidirecional e SSL bidirecional (Mutual SSL). A diferença entre esses dois tipos é que no SSL unidirecional, apenas o cliente valida a identidade do servidor, enquanto que no SSL bidirecional, tanto o servidor quanto o cliente validam a identidade um do outro. Normalmente, quando navegamos num site HTTPS, é utilizado o SSL unidireccional onde apenas o nosso browser (cliente) valida a identidade do site (servidor). O SSL bidirecional é usado principalmente na comunicação servidor a servidor onde ambas as partes precisam validar a identidade uma da outra.
Durante um aperto de mão SSL, o servidor e o cliente seguem o conjunto de passos abaixo.
1. Cliente Olá
O cliente enviará a informação que será requerida pelo servidor para iniciar uma conexão HTTPS.
No log acima, podemos ver que o cliente olá com o TLS v1.2. Com isso, o cliente notifica o servidor que tem o suporte para as versões 1.2 e abaixo do TLS. A lista de cifras que são suportadas pelo cliente também pode ser vista a partir do log acima. Fora desta lista, o servidor irá selecionar uma suíte de cifras que suporta. Se a lista contém suítes de cifras que o servidor não reconhece, suporta, ou deseja usar, o servidor irá ignorar essas cifras. Se nenhuma suíte de cifras suportada for encontrada, o servidor enviará um alerta de falha e fechará a conexão.
2. Server Hello
O servidor responderá com a configuração que selecionou no Client Hello junto com suas informações para proceder com o aperto de mão. Server Hello será como segue.
Sever selecionará a versão do TLS de acordo com a menor das sugeridas pelo cliente na mensagem Client Hello e a maior suportada pelo servidor. O servidor também enviará de volta o conjunto de cifras selecionado da lista de cifras apresentada pelo cliente.
Em conjunto com o Server Hello, o servidor também enviará o certificado do servidor com a cadeia de certificados. A cadeia de certificados será validada contra os certificados da loja cliente.
3. Server Key Exchange Message
Esta mensagem será enviada pelo servidor ao cliente carregando os detalhes necessários para que o cliente gere o segredo pré-mestre. Esta mensagem não será enviada se for utilizado o algoritmo de troca de chaves RSA (mais adiante) ou qualquer outro algoritmo de troca de chaves que não requeira a informação do servidor para gerar um segredo pré-mestre.
Para troca de chaves Elliptic Curve Diffie Hellman(ECDH), os seguintes detalhes sobre a chave pública ECDH do servidor estão sendo enviados ao cliente.
4. Pedido de Certificado
Este é o lugar onde o SSL unidirecional difere do SSL bidirecional. No SSL unidireccional, a autenticidade do cliente não está a ser validada. Portanto, este passo é omitido no aperto de mão unilateral do SSL.
Durante este passo, o servidor enviará um pedido de certificado do cliente com o tipo de certificado, algoritmos de assinatura de certificado e autoridades de certificado suportadas pelo servidor. Pode haver situações em que a lista de autoridades de certificado pode estar vazia. Nesses cenários, o cliente pode optar por enviar ou evitar o envio do certificado do cliente (depende da implementação do cliente)
Finalmente, o servidor envia a mensagem Server Hello Done indicando o fim do Server Hello. Após enviar esta mensagem, o servidor irá aguardar uma resposta do cliente.
5. Client Certificate
O cliente apresenta a sua cadeia de certificados ao servidor. O certificado precisa ser apropriado para o algoritmo de troca de chaves do conjunto de cifras negociado, e quaisquer extensões negociadas.
6. Client Key Exchange Message
Esta mensagem precisa ser enviada pelo cliente seguindo a mensagem de Certificado do Cliente. Se o certificado do cliente não estiver sendo apresentado (em SSL one-way), a mensagem de troca de chaves do cliente deve ser enviada após o cliente receber a mensagem ServerHelloDone.
Como todos sabemos, os dados transferidos entre o servidor e o cliente em uma conexão HTTPS serão criptografados. A criptografia simétrica está sendo usada para este fim, pois o custo computacional é muito menor do que a criptografia assimétrica. Para usar a criptografia simétrica, é necessário que haja uma chave comum entre as duas extremidades. O propósito desta mensagem é gerar aquela chave comum entre aquele cliente e o servidor sem expor a um estranho.
Existem dois métodos de troca de chaves de clientes descritos na especificação TLS v1.2. Eles são RSA e Diffie-Hellman.
Se RSA for usado como algoritmo de troca de chaves, o cliente gera um segredo pré-master de 48 bytes. O cliente encripta o segredo pré-mestrado pela chave pública do certificado e envia para o servidor. Somente o servidor terá a chave privada correspondente para decodificar e obter o segredo pré-mestre gerado pelo cliente.
Se Diffie-Hellman for utilizado, os parâmetros Diffie-Hellman são transmitidos para permitir que tanto o cliente quanto o servidor gerem o mesmo segredo pré-mestre.
Depois disso, ambos os lados irão gerar um segredo mestre utilizando o segredo pré-mestre e o segredo mestre será utilizado para gerar a chave simétrica para criptografar os dados da sessão
7. Finalizado
Após autenticação bem sucedida e geração dos segredos pré-mestre/ segredos mestre, uma mensagem de mudança de cifra será enviada tanto pelo cliente quanto pelo servidor indicando que o resto da comunicação será criptografada.
A mensagem Finalizada seguirá imediatamente a mensagem de mudança de cifra. Esta será a primeira mensagem criptografada com os algoritmos negociados. Os dados da aplicação serão transferidos somente depois que ambas as partes enviarem a mensagem finalizada e verificarem o conteúdo da mensagem.
https://tools.ietf.org/html/rfc5246
https://docs.microsoft.com/en-us/windows/desktop/secauthn/cipher-suites-in-schannel
https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https
https://docs.apigee.com/api-platform/system-administration/keystores-and-truststores
https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
https://www.globalsign.com/en/ssl-information-center/what-are-certification-authorities-trust-hierarchies/
https://www.geeksforgeeks.org/rsa-algorithm-cryptography/
https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/