<< Criptografia Básica Modelo de camadas >> 

3. Modelo de Operação

3.1. Aspecto Geral

A conexão baseada em protocolo TLS / SSL possui uma arquitetura do tipo cliente/servidor bem definida, já que a negociação delega papeis distintos às duas partes. O cliente é responsável por iniciar a conexão, e é ele quem propõe a configuração com a qual os nós trabalharão, mesmo sendo o servidor quem determina os parâmetros que serão realmente utilizados, ele determina baseado somente nos parâmetros propostos pelo cliente.

Quando cliente e servidor se comunicam, eles utilizam mensagens TLS / SSL, que indicam as ações a serem tomadas pelos nós, a tabela abaixo lista as mensagens utilizadas em todos as camadas do protocolo e seus significados:

Mensagem
Descrição
   Alert
Informa a outra parte de uma possível quebra de segurança ou uma falha de comunicação
   ApplicationData
Informação real transmitida pelas duas partes, encriptada, autenticada e/ou verificada pelo TLS /SSL
   Certificate
Mensagem que contém o certificado de chave pública do remetente
   CertificateRequest
Pedido de envio do certificado de chave pública do cliente, enviado pelo servidor
   CertificateVerify
Mensagem do cliente que verifica que ele possui a chave privada do certificado de chave pública enviado ao servidor
   ChangeCipherSpec
Indicação para início de uso dos serviços de segurança (como encriptação) definidos durante a etapa de negociação
   ClientHello
Mensagem do cliente indicando os serviços de segurança que ele deseja e é capaz de suportar
   ClientKeyExchange
Mensagem do cliente contendo as chaves de criptografia para a comunicação
   Finished
Indicação que a etapa inicial de negociação foi concluída e a conexão segura foi estabelecida
   HelloRequest
Mensagem do servidor exigindo que o cliente inicie ou reinicie a etapa de negociação
   ServerHello
Mensagem do servidor indicando os serviços de segurança que seram usados na comunicação
   ServerHelloDone
Indicação do servidor que ele concluiu todos os pedidos do cliente para estabelecer a comunicação
   ServerKeyExchange
Mensagem do servidor contendo as chaves de criptografia para a comunicação

 

3.2. Estabelecendo uma conexão segura

A partir de agora, analisaremos como acontecem as negociações de segurança para a conexão, começando com uma conexão onde o único serviço de segurança realizado é a encriptação.

A figura abaixo apresenta o diagrama das mensagens trocadas pelo cliente e servidor durante a etapa de negociação (handshake) para este cenário:

Sequência de comandos:

  1. O Cliente envia o ClientHello propondo as opções TLS / SSL
  2. O Servidor responde com o ServerHello, selecionando as opções TLS / SSL
  3. O Servidor envia sua chave pública na mensagem ServerKeyExchange
  4. O Servidor conclui sua parte na negociação enviando a mensagem ServerHelloDone
  5. O Cliente manda a informação de chaves da sessão, encriptada com a chave pública do servidor na mensagem ClientKeyExchange
  6. O Cliente manda a mensagem ChangeCipherSpec para ativar as opções negociadas para todas as demais mensagens enviadas por ele
  7. O Cliente manda a mensagem Finished para deixar o servidor checar as opções ativadas
  8. O Servidor manda a mensagem ChangeCipherSpec para ativar as opções negociadas para todas as demais mensagens enviadas por ele
  9. O Servidor manda a mensagem Finished para deixar o cliente checar as opções ativadas

Junto com a mensagem #1, o cliente envia as informações da versão mais alta do protocolo que ele suporta (no caso do SSLv3: 3.0 e do TLSv1: 3.1), um número de 32 bits utilizado para randomizar a criação das chaves criptográficas, um identificador para a sessão da transmissão, uma lista com os algoritmos de criptografia que ele suporta e uma lista dos métodos de compressão que ele suporta.

Na segunda mensagem, o servidor envia para os clientes os parâmetros que serão realmente utilizados na conexão. Ele compara a lista de algoritmos de criptografia suportados pelo cliente com os suportados por ele e escolhe aquele que achar ser mais forte, faz o mesmo com os métodos de compressão e com a versão do protocolo.

Em seguida, o servidor envia ao cliente sua chave pública na mensagem #3 e indica que aguarda resposta do cliente na mensagem #4. Neste ponto o cliente checa as opções setadas pelo servidor e escolhe ou abandonar a conexão por não satisfazerem suas necessidades de segurança ou configura seus parâmetros de criptografia com as opções setadas e envia na mensagem #5 para o servidor a chave simétrica que será usada durante toda a conexão, encriptada com a chave pública enviada pelo servidor. Na mensagem #6, o cliente informa ao servidor a atualizar o estado de leitura quanto à segurança nas mensagens enviadas pelo cliente, isto é, determinando que todos as próximas mensagens recebidas pelo servidor sejam tratadas com a segurança negociada. O cliente envia uma mensagem indicando que aguarda a resposta do servidor, o servidor manda o cliente também atualizar seu estado para receber mensagens já criptografadas com as configurações negociadas e indica o fim da negociação na mensagem #9.

3.3. Autenticando o Servidor

A figura abaixo representa a modificação na sequência de comandos no handshake para realizar a autenticação do servidor.

Sequência de comandos:

  1. O Cliente envia o ClientHello propondo as opções TLS / SSL
  2. O Servidor responde com o ServerHello, selecionando as opções TLS / SSL
  3. O Servidor envia seu certificado de chave pública na mensagem Certificate
  4. O Servidor conclui sua parte na negociação enviando a mensagem ServerHelloDone
  5. O Cliente manda a informação de chaves da sessão, encriptada com a chave pública do servidor (enviada no certificado) na mensagem ClientKeyExchange
  6. O Cliente manda a mensagem ChangeCipherSpec para ativar as opções negociadas para todas as demais mensagens enviadas por ele
  7. O Cliente manda a mensagem Finished para deixar o servidor checar as opções ativadas
  8. O Servidor manda a mensagem ChangeCipherSpec para ativar as opções negociadas para todas as demais mensagens enviadas por ele
  9. O Servidor manda a mensagem Finished para deixar o cliente checar as opções ativadas

No caso em que acontece a autenticação do servidor, ocorrem mudanças nas mensagens #3 e #5 no handshake. Ao invés do servidor enviar sua chave pública somente, ele envia seu certificado de chave pública, que contém além da chave pública, informações que permitiram fazer com que o cliente verifique a entidade a qual ele está se conectando. Na mensagem #5 a mudança se dá no fato que ao invés do cliente encriptar a chave simétrica com a chave pública do servidor, ele retira a chave pública do certificado e encripta a simétrica com ela.

A mudança na mensagem #5 é importante pois ainda existe uma outra forma de handshake para autenticar o servidor, onde o servidor envia alem da mensagem Certificate a mensagem ServerKeyExchange. Na mensagem Certificate o servidor envia o certificado que prova sua identidade, e na mensagem ServerKeyExchange ele envia o certificado com o qual o cliente deve encriptar a chave simétrica . A chave enviada na mensagem ServerKeyExchange é encriptada com a chave privada equivalente à pública contida no certificado, possibilitando assim, que o cliente possa verificar que o servidor possui a chave privada da pública enviada no certificado. A necessidade do envio de duas chaves por parte do servidor se dá por conta da política de exportação de chaves criptográficas por parte de algumas entidades de criptografia(em sua maioria controladas pelo governo americano), que limitam o tamanho em algumas chaves de conexão, mas não limitam o tamanho das chaves emitidas por entidades certificadoras em seus certificados.

3.3. Autenticando o Cliente

Na figura abaixo, é apresentado o diagrama para a negociação onde é realizada a autenticação da identidade do cliente.

Sequência de comandos:

  1. O Cliente envia o ClientHello propondo as opções TLS / SSL
  2. O Servidor responde com o ServerHello, selecionando as opções TLS / SSL
  3. O Servidor envia seu certificado de chave pública na mensagem Certificate
  4. O Servidor envia o pedido para que o cliente envie seu certificado para autenticação na mensagem CertificateRequest
  5. O Servidor conclui sua parte na negociação enviando a mensagem ServerHelloDone
  6. O Cliente envia seu certicado para autenticação na mensagem Certificate
  7. O Cliente manda a informação de chaves da sessão, encriptada com a chave pública do servidor (enviada no certificado) na mensagem ClientKeyExchange
  8. O Cliente envia a mensagem CertificateVerify encriptada com sua chave privada para conferência da chave pública enviada no certicado
  9. O Cliente manda a mensagem ChangeCipherSpec para ativar as opções negociadas para todas as demais mensagens enviadas por ele
  10. O Cliente manda a mensagem Finished para deixar o servidor checar as opções ativadas
  11. O Servidor manda a mensagem ChangeCipherSpec para ativar as opções negociadas para todas as demais mensagens enviadas por ele
  12. O Servidor manda a mensagem Finished para deixar o cliente checar as opções ativadas

No processo apresentado acima, é realizada a autenticação de ambos os nós, tanto o cliente como o servidor. No caso da autenticação do cliente, que não é usual em transações seguras sobre HTTP, o servidor explicita a necessidade do certificado do cliente na mensagem CertificateRequest. Ao receber esta mensagem, o cliente espera o fim do Hello do servidor e envia seu certificado.

Como somente o certificado não é suficiente para provar que o cliente possui o domínio sobre as informações presentes no mesmo, o cliente deve provar ao servidor que possue a chave privada análoga à pública presente no certificado enviado, assim, o cliente envia uma mensagem criptografada com sua chave privada, para que o servidor desencripte com a chave pública por ele recebida e verifique a informação contida nela, que é de domínio de ambos. Esta informação é obtida através da união da chave de criptografia simétrica com todas as mensagens anteriores transitadas na conexão durante o handshake.

 

 << Criptografia Básica Modelo de camadas >>