<< Criptografia Básica | Modelo de camadas >> |
3. Modelo de Operação
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 |
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:
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.
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:
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.
Na figura abaixo, é apresentado o diagrama para a negociação onde é realizada a autenticação da identidade do cliente.
Sequência de comandos:
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 >> |