O que é SSL e TLS
O SSL (Secure Sockets Layer) e seu sucessor TLS (Transport Layer Security) são protocolos de criptografia projetados para internet. Permitem a comunicação segura entre os lados cliente e servidor de uma aplicação web.
A grande vantagem desses protocolos é que eles agem como uma subcamada nos protocolos de comunicação na internet (TCP/IP). É aí que entra a diferença entre o HTTP e o HTTPS, do qual o primeiro é trafegado em texto puro e o segundo encriptado com SSL/TLS. Ou seja, é possível operar com ou sem TLS (ou SSL), basta o cliente indicar ao servidor se quer configurar uma conexão segura ou não. Existem duas principais formas de alcançar este objetivo: uma é usar portas diferentes para conexões TLS, por exemplo, a porta TCP/443 para HTTPS; a outra é usar a mesma porta e ter a solicitação do cliente ao servidor para mudar a conexão com TLS usando um mecanismo específico do protocolo, por exemplo, STARTTLS para protocolos de e-mail como IMAP e POP3.
Funcionamento
Uma vez que o cliente e o servidor tenham decidido usar TLS/SSL, eles negociam um estado de conexão usando um procedimento de handshaking, no qual o cliente e o servidor concordam em vários parâmetros utilizados para estabelecer a conexão segura.
- O cliente envia ao servidor a versão que possui do TSL/SSL, as configurações de criptografia, os dados específicos da sessão (session ID), e outras informações que o servidor precisa para se comunicar com o cliente usando SSL.
- O servidor envia ao cliente a sua versão do TSL/SSL, as configurações de criptografia, os dados específicos da sessão, e outras informações que o cliente também precisa. O servidor também envia seu próprio certificado e, se o cliente está solicitando um recurso de servidor que requer autenticação do cliente, o servidor solicita o certificado do cliente.
- O cliente utiliza as informações enviadas pelo servidor para autenticar o servidor, ou seja, confirmar se todas as configurações recebidas pelo servidor são as esperadas para, então, dar continuidade a conexão segura. Caso contrário, a solicitação é interrompida e o usuário é informado.
- Usando todos os dados gerados no handshaking até agora, o cliente (com a cooperação do servidor, dependendo da cifra em uso) cria o segredo pré-mestre para a sessão, criptografa com a chave pública do servidor (obtido a partir de certificado do servidor, enviado no passo 2), e, em seguida, envia o criptografado segredo pré-mestre para o servidor.
- Se o servidor solicitou autenticação do cliente (opcional), o cliente também assina outro pedaço de dados que é exclusivo para este handshaking e conhecido tanto pelo cliente quanto pelo servidor. Neste caso, o cliente envia os dados assinados e seu certificado para o servidor, juntamente com o criptografado segredo pré-mestre.
- Se o servidor solicitou autenticação do cliente, o servidor tenta autenticar o cliente. Se o cliente não pode ser autenticado, a sessão termina da mesma forma que no passo 3. Se o cliente é autenticado com sucesso, o servidor usa sua chave privada para descriptografar o segredo pré-mestre, e em seguida, executa uma série de etapas (que o cliente também realiza, a partir do mesmo segredo pré-mestre) para gerar o segredo principal.
- Tanto o cliente quanto servidor devem usar o segredo principal para gerar as chaves de sessão, que são chaves simétricas usadas para criptografar e descriptografar as informações trocadas durante a sessão TSL/SSL e para verificar a sua integridade (ou seja, para detectar quaisquer alterações nos dados entre o tempo que foi enviado e o momento em que é recebido através da conexão SSL).
- O cliente envia uma mensagem para o servidor, informando que as próximas mensagens do cliente serão criptografadas com a chave de sessão. Em seguida, envia uma mensagem separada (criptografada), indicando que a parte handshanking do cliente esta concluída.
- O servidor envia uma mensagem para o cliente também informando que suas próximas mensagens serão criptografadas com a chave de sessão. Em seguida, envia uma mensagem separada (criptografada), indicando que a parte handshaking do servidor esta concluída.
O handshaking TSL/SSL está concluído e a sessão segura começa. O cliente e o servidor usam as chaves de sessão para criptografar e descriptografar os dados que enviam para o outro e para validar a sua integridade. Se qualquer um dos passos acima falhar, o handshaking e a conexão não são criados. No passo 3, o cliente deve verificar uma cadeia de “assinaturas” de uma “raiz de confiança” embutidos, ou adicionados, ao cliente que também deve verificar se nenhuma delas não foi revogada, o que em muitas versões não foi bem implementado, mas é uma exigência de qualquer sistema de autenticação de chave pública.