Protocolo TLS Handshake

O protocolo TLS Handshake é baseado no protocolo TLS Record e é o encarregado pelo processo de handshake, por meio do qual os pares comu- nicantes combinam os parâmetros da sessão TLS (DIERKS; RESCORLA, 2008). O processo é realizado pela troca de seis a treze mensagens, dependendo da configuração do cliente e do servidor (RISTIC, 2014), como ilustrado na Figura 11. Mensagens apresentadas em itálico são opcionais e mensagens entre col- chetes não pertencem ao protocolo de handshake, mas sim ao protocolo TLS Change Cipher Spec.

A primeira mensagem do processo é do tipo ClientHello. Esta men- sagem é mandada pelo cliente para o servidor para comunicar suas capacida- des e preferências. Seu conteúdo compreende:

• A melhor versão do protocolo suportada pelo cliente;

2.3 O protocolo Transport Layer Security 41 aleatórios para o handshake;

• O identificador de uma sessão anterior, se o cliente deseja resumir uma sessão anteriormente negociada;

• A lista de suítes criptográficas suportadas, ordenadas por preferência; • A lista de métodos de compressão suportadas, também ordenados por

preferência;

• E a lista de extensões do protocolo que são suportadas.

A segunda mensagem de handshake é uma resposta do servidor para o cliente, do tipo ServerHello. Seu conteúdo é muito similar ao de uma ClientHello, exceto por possuir apenas a suíte criptográfica e o método de compressão escolhidos, ao invés de uma lista (OPPLIGER, 2016).

Uma mensagem do tipo Certificate é usada para transportar ca- deias de certificados X.509 do servidor ou cliente para o outro par da conexão. Estes certificados são codificados no padrão ASN.1 DER, como o certificado principal sendo o primeiro, seguido por todos os certificados intermediários até, mas sem incluir, um certificado raiz.

Nem todas as suítes criptográficas requem certificados, seja por se- rem suítes anônimas (que não possuem autenticação) ou porque o método de autenticação não depende de certificados. Se a suíte negociada necessitar, o servidor dará continuidade ao processo de handshake enviando uma mensa- gem do tipo Certificate.

Se o método de troca de chaves selecionado pela suíte criptográfica necessitar de mais informações do que as providas por certificados, o servidor enviará em seguida uma mensagem do tipo ServerKeyExchange, cujo conteúdo varia conforme o método de troca de chaves em uso.

Quando o servidor requer a autenticação do cliente, uma mensagem do tipo CertificateRequest é enviada. Esta mensagem contém uma lista de

2.3 O protocolo Transport Layer Security 42 tipos de certificados aceitos, tipos de algoritmos de assinatura suportados e autoridades certificadoras, identificadas por seus nomes distintos.

O servidor então sinaliza que enviou todas as mensagens de handshake que pretendia por meio de uma mensagem do tipo ServerHelloDone. Se uma mensagem do tipo CertificateRequest foi enviada, o servidor irá res- ponder com uma mensagem do tipo Certificate com o requerido certificado. Se o método de troca de chaves necessitar de mais informações do cliente, uma mensagem do tipo ClientKeyExchange é enviada.

Se uma mensagem do tipo Certificate foi enviada, o cliente dará prosseguimento ao processo de handshake com uma mensagem do tipo CertificateVerify, que prova a posse da chave privada do certificado envi- ado por meio da assinatura de todas as mensagens de handshake enviadas até este ponto. Finalmente, o cliente envia uma mensagem ChangeCipherSpec, sinalizando que possui informações suficientes para gerar os parâmetros da conexão e chaves criptográficas necessárias e que agora está apto a utilizar o canal de comunicação de forma segura.

A mensagem ChangeCipherSpec não faz parte do protocolo TLS Handshake e sim a única mensagem do protocolo TLS Change Cipher Spec. Por ser parte de um subprotocolo diferente, esta mensagem necessariamente será transportada por um quadro TLS Record próprio e todos os quadros enviados a partir deste utilizarão os novos parâmetros negociados.

O cliente então envia sua última mensagem de handshake, do tipo Finished. Esta é a primeira mensagem encriptada e sinaliza o fim do processo de handshake. Seu conteúdo é o valor hash de todas as mensagens do proto- colo TLS Handshake trocadas até este ponto, combinado com o master secret negociado por meio de uma função pseudoaleatória que pode variar de acordo com a versão do protocolo. Para a versão TLS 1.2, esta função é definida como (14) mostra. Trata-se de uma função iterativa que pode produzir uma quanti- dade arbitrária de dados e é definida em termos de Phash e A(i), apresentados

2.3 O protocolo Transport Layer Security 43 Client Server ClientHello ServerHello Certificate ServerKeyExchange CertificateRequest ServerHelloDone Certificate ClientKeyExchange CertificateVerify [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished

Figura 11: Processo de handshake do protocolo TLS

respectivamente em (15) e (16).

P RF (secret, label, seed) = Phash(secret, label + seed) (14)

Phash(secret, seed) = HM AChash(secret, A(1) + seed) +

HM AChash(secret, A(2) + seed) +

. . . (15) A (i) =    seed, if i = 0 HM AChash(secret, A (i − 1)) , if i < 0 (16)

Para gerar o conteúdo da mensagem Finished, P RF é invocada com o master secrete como secret, os bytes ASCII que representam a cadeia ‘cliente finished’ para a mensagem do cliente e ‘server finished’ par a mensa- gem do servidor como label e o valor hash de todas as mensagem trocadas como seed.

O servidor então responde com uma mensagem ChangeCipherSpec e em seguida sua própria mensagem Finished, considerando a ultima mensa-

2.3 O protocolo Transport Layer Security 44 gem enviada pelo cliente e portanto com um valor hash diferente como entrada para a P RF . Sendo P RF uma função determinística, com os dados neces- sários para seu cálculo conhecido por ambos os lados e considerando que a mensagem é encriptada e autenticada com os parâmetros negociados para a sessão, seu conteúdo pode ser utilizado para verificar o sucesso da troca de chaves e do processo de autenticação.

Após este ponto, cliente e servidor podem trocar dados da aplicação por meio de um canal seguro. A qualquer momento o cliente pode enviar uma nova mensagem do tipo ClienteHello para indicar que deseja renegociar os parâmetros da sessão. Semelhantemente, o servidor pode requisitar a renego- ciação por meio do envio de uma mensagem do tipo HelloRequest.