Segurança: como funciona o Protocolo SSL/TLS

por Eugênio Augusto Segunda-feira, 10 de março de 2014

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.

    Você recomendaria esse artigo para um amigo?

    Nunca

     

    Com certeza

     

    Deixe seu comentário

    2 comentários

    Comentários

    O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

    Comentando como Anônimo

    Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

    1. Olá,

      parabéns pela matéria, mas ainda tenho as seguintes dúvidas:

      1. Por que algumas empresas cobram tão caro pelos certificados SSL/TLS?

      2. O certificado gratuito da StartCom Class 1, protege a comunicação cliente-servidor da mesma forma que um certificado pago? Se sim, então, o que justifica o alto preço cobrado pela maioria das empresas certificadoras?

      3. Se eu comprar um certificado eu poderei usar em quantas páginas do site eu quiser? Ou, para cada página eu terei que pagar por um certificado adicional? Por exemplo, eu compro um certificado e posso utilizar na página de login, na página de cadastro etc.; enfim, se eu quiser, comprando apenas um certificado eu posso usar em todas as páginas do site ou terei que comprar um certificado para cada página que eu decida utilizar o protocolo SSL/TLS?

      Não sei se o Eugênio Augusto, autor desta matéria, vai responder (caso responda) essas minhas dúvidas de forma imparcial, sem ser tendencioso, já que ele trabalha na Site Blindado, que é uma empresa que emite certificados e cobra por isso.

      Mas, se alguém puder tirar essas dúvidas eu, desde já, agradeço.

      Responder
    2. Malcom, se você avaliar apenas o aspecto técnico do arquivo do certificado digital, o StartCom é idêntico ao Geotrust. Agora, se você incluir outros atributos, como: atendimento, seguro contra invasão (que pode chegar a milhões de reais), serviços de anti-phising e antimalware, plataforma para renovação online, nota fiscal brasileira… você vai ver a diferença entre o gratuito e o pago. Concordo contigo que há preços abusivos, mas o custo pós-emissão precisa ser posto na sua conta. Há também a estrutura da AC. Não dá para comparar a AC do StartCom com autoridades como Symantec e GlobalSign. O CA/B Fórum faz uma série de exigências de segurança, e estas duas empresas despontam, não só aderindo, mas inovando. A Symantec, por exemplo, já lançou certificados com algoritmos em curvas elípticas. Isso significa mais segurança para o site e velocidade no handshaking.

      Sobre os sites, um certificado valida um domínio específico (www.malcom.com.br). Qualquer página dentro deste domínio será protegida. Agora, se você tem outro domínio (www.malcom.net), você precisará de outro certificado. Tem a questão de subdomínios, certificados multidomain, wildcard, etc. Sugiro você pesquisar https://ssl-tools.net a respeito.

      Responder

      Assine nossa Newsletter

    Fique por dentro de todas as novidades, eventos, cursos, conteúdos exclusivos e muito mais.

    Obrigado!

    Você está inscrito em nossa Newsletter. Enviaremos, periodicamente, novidades e conteúdos relevantes para o seu negócio.

    Não se preocupe, também detestamos spam.