4. Funcionamento do TLS

4.1 Introdução

O principal objetivo do protocolo TLS é garantir a privacidade e a integridade dos dados em uma comunicação entre duas aplicações. O protocolo é composto de duas camadas: o protocolo de Registro (TLS Record Protocol) e os protocolos Handshaking (TLS Handshaking Protocols) . A figura 4.1 apresenta a arquitetura to TLS.

Fig. 4.1

O primeiro se localiza acima de um protocolo de transporte confiável (por ex: TCP), provendo a segurança da conexão que apresenta duas propriedades:

• A conexão é privada. É utilizada criptografia simétrica para encriptação dos dados, por exemplo. As chaves para esta encriptação simétrica são geradas unicamente para cada conexão e são baseadas em um segredo negociado (ou negociação secreta) por um outro protocolo, neste caso o protocolo Handshake. O protocolo de Registro pode ser usado sem criptografia.

• A conexão é confiável. O transporte da mensagem inclui uma verificação da integridade da mensagem, utilizando uma keyed-HMAC (Hashing Message Authentication Code). Funções hash seguras são utilizadas para computação da MAC. O protocolo de Registro pode operar sem uma MAC, porém geralmente, só é utilizado desta maneira, enquanto outro protocolo está usando o protocolo de Registro como transporte para a negociação dos parâmetros de segurança.

O protocolo de Registro é usado para o encapsulação de vários protocolos de níveis acima, por exemplo, o protocolo Handshake, que permite a autenticação entre cliente e servidor e a negociação de algoritmos de encriptação e de chaves criptográficas antes da transmissão ou recepção do primeiro octeto de dados por parte de um protocolo de aplicação. Os protocolos Handshaking provêem segurança da conexão que apresenta três propriedades:

• A identificação de uma das partes pode ser autenticada através da criptografia assimétrica. Esta autenticação pode ser opcional, mas geralmente é exigida para pelo menos uma das partes.
• A negociação de um segredo compartilhado é segura. O segredo negociado fica indisponível para bisbilhoteiros, e para qualquer conexão autenticada o segredo não pode ser obtido, mesmo por um atacante que pode se colocar no meio da conexão.
• A negociação é confiável. Nenhum atacante pode modificar a comunicação da negociação sem ser detectado pelas partes legítimas da comunicação.

Uma vantagem do TLS é a independência em relação aos protocolos de aplicação. Protocolos de nível acima podem comunicar com o TLS de forma transparente.

4.2 Objetivos

Os objetivos do protocolo TLS, em ordem de prioridade, são:

1. Segurança com criptografia: TLS deve ser usado para estabelecer uma conexão segura entre duas partes.
2. Interoperabilidade: Programadores independentes devem conseguir desenvolver aplicações utilizando TLS que possam trocar parâmetros criptográficos sem um conhecer o código do outro.
3. Extensibilidade: TLS busca o fornecimento de uma estrutura (framework), em que novos métodos de criptografia simétrica e assimétrica podem ser adicionados, sem a necessidade da implementação de uma nova biblioteca de segurança.
4. Eficiência Relativa: Operações de criptografia, principalmente de chave pública, exigem um alto processamento. Sendo assim, o protocolo TLS incorporou um mecanismo de armazenamento para evitar que toda conexão ao ser estabelecida não precise processar operações de criptografia. Com isso, reduz-se também a atividade da rede.

4.3 Protocolo de Registro

          O TLS utiliza esta camada para encapsular todas as mensagens dos demais protocolos das camadas superiores, explicando a sua independência com os protocolos de aplicação, facilitando o desenvolvimento de aplicações que necessitam de conexões seguras. Enquanto os protocolos Handshaking realizam a negociação de parâmetros de segurança, o protocolo de Registro é quem realmente efetua as operações necessárias para garantir a segurança da conexão.
O protocolo de Registro recebe as mensagens para serem transmitidas, fragmenta os dados em blocos, opcionalmente realiza a compressão dos dados, aplica o MAC, encripta e transmite o resultado. Logicamente, com os dados recebidos, o protocolo de Registro realiza a decriptação, verificação da integridade, realiza descompressão, reagrupa os blocos e os entrega para as camadas superiores.
 

4.4 Protocolos de Handshaking

O TLS possui três subprotocolos que permitem às partes chegarem a um acordo sobre os parâmetros de segurança que serão utilizados na camada de registro para autenticação, comunicação e para reportar condições de erro entre as partes.

4.4.1 Protocolo Handshake

O protocolo de Handshake é responsável pelos seguintes itens:

• Identificador da sessão: uma seqüência de bytes escolhida pelo servidor para identificar uma sessão ativa ou uma sessão reiniciável.
• Método de compressão: qual o método de compressão que será utilizada antes da criptografia dos dados.
• Cipher Spec: especifica qual o algoritmo de criptografia vai ser utilizado, por exemplo, DES. Qual algoritmo de MAC (MD5, SHA) que vai ser utilizado. E define alguns atributos criptográficos como, por exemplo, o tamanho do hash
• Chave Mestre (master key): chave secreta de 48 bytes que será compartilhada entre o cliente e o servidor
• Is Resumable: flag que indica se a sessão pode ser utilizada para iniciar novas conexões.

Com os itens acima são criados os parâmetros de segurança para serem usados pela Camada de Registro para proteger os dados. Muitas conexões podem ser retomadas usando a mesma sessão, caso essa característica seja suportada pela mesma. Isso evita que todos os parâmetros de segurança tenham que ser novamente negociados.

4.4.2 Protocolo Change Cipher Spec

O protocolo Change Cipher Spec existe para sinalizar mudanças nas estratégias de criptografia que estavam sendo utilizadas. Este protocolo é formado por apenas uma mensagem, a qual é encriptada e comprimida com os parâmetros que estavam previamente estabelecidos.

A mensagem Change Cipher Spec é enviada por ambos, cliente e servidor, para que cada um deles passe a usar as novas regras de criptografia que foram negociadas.

Um cuidado deve ser tomado ao fazer as alterações nas estratégias de criptografia, pois existe a possibilidade de que o primeiro a receber a mensagem de troca de estratégia possa ainda estar computando uma mensagem que recebeu anteriormente, já que os algoritmos de chave pública demandam muito processamento. Para resolver isso, deve ser esperado um tempo antes de mandar essa mensagem para garantir que o outro lado não perderá informações.

4.4.3 Protocolo de Alerta

Um dos tipos de conteúdo suportado pela camada de registros do TLS é o conteúdo de alerta.

As mensagens de alerta transportam a importância do alerta e a descrição do alerta. Mensagens com importância denominada fatal, resultam imediatamente no encerramento da conexão. Nesse caso outras conexões correspondendo à mesma sessão podem continuar, mas o identificador da sessão deve ser invalidado, prevenindo que essa sessão seja utilizada posteriormente para estabelecer novas conexões.

Assim como as outras mensagens do TLS as mensagens de alerta também são encriptadas e comprimidas de acordo com os parâmetros de segurança que estão ativos no momento em que a mensagem é enviada.

Tipos de mensagem de alerta:

1.      Alertas de Encerramento

São utilizados para informar às partes que a conexão será encerrada, evitando assim truncation attacks. Todos os dados recebidos após o recebimento de uma mensagem de encerramento são descartados.

2.      Alertas de Erro

            O tratamento de erros pelo TLS Handshake Protocol é muito simples. Quando um erro é detectado, quem detectou o erro envia um alerta para o outro lado. Se for um alerta fatal, imediatamente ambos terminam a conexão. Clientes e servidores devem esquecer quaisquer identificadores de sessões e chaves secretas associados com uma conexão que falhou. Por conseguinte qualquer conexão que tenha sido encerrada por um alerta fatal não pode ser restabelecida. Exemplos de mensagem de erro são: bad_certificate, certificate_expired, illegal_parameter, unknown CA, insuffiecient security, entre outros.

4.4.4 Estabelecendo uma conexão

            Os parâmetros criptográficos de uma sessão são determinados pelo TLS Handshake Protocol como já foi dito anteriormente. O TLS Handshake Protocol opera acima da Camada de Registro.

            Quando um cliente e um servidor começam a se comunicar eles têm que entrar em acordo sobre qual versão será utilizada, qual algoritmo criptográfico será usado, opcionalmente autenticar um ao outro e usar criptografia assimétrica para compartilhar um segredo a ser usado pela criptografia simétrica, que é responsável pela maior parte da criptografia realizada pelo protocolo.

            O TLS Handshake Protocol é composto pelas seguintes etapas:

• Troca de mensagens de hello para chegar a um acordo sobre qual algoritmo criptográfico será usado, troca de valores aleatórios e checar se uma sessão está sendo restabelecida.
• Troca dos parâmetros criptográficos necessários para permitir ao cliente e ao servidor chegarem a uma premaster key.
• Troca de certificados para permitir que o cliente e o servidor se autentiquem.
• Gerar chave mestre (master key) a partir da premaster key.
• Informar a camada de registro sobre os parâmetros de segurança negociados.
• Permitir que cliente e servidor possam verificar se ambos estão usando os mesmos parâmetros de segurança e verificar se a negociação não foi interceptada por um atacante.

O processo de estabelecimento de uma conexão segura está ilustrado na figura 4.2 abaixo.

Fig. 4.2: Processo completo de negociação

As mensagens com * são opcionais, ou seja, nem sempre são enviadas em todos os processos de negociação.

            O processo de negociação mostrado acima pode ser explicado da seguinte forma, o cliente envia uma mensagem de ClientHello para o servidor, o servidor deve então enviar de volta uma mensagem ServerHello, caso contrário um erro fatal será caracterizado e a conexão encerrada. As mensagens de Hello servem para estabelecer quais as capacidades de segurança cada um dos lados possui. Essas mensagens estabelecem os seguintes parâmetros: versão do protocolo, ID da sessão, Suíte de Criptografia e método de compressão. Adicionalmente dois valores aleatórios são gerados e trocados, ClientHello.random e ServerHello.random. Após a troca das mensagens de Hello o servidor poderá enviar seu certificado, caso haja a necessidade de autenticação. Alternativamente o servidor pode enviar uma mensagem de ServerKeyExchange se não possuir certificado ou se o seu certificado for utilizado apenas para assinatura digital. Se o servidor for autenticado, ele pode requisitar ao cliente um certificado, caso a suíte de criptografia requeira tal característica do cliente. Depois dessa fase o servidor envia uma mensagem de ServerHelloDone indicando que a fase de Hello da negociação acabou. O servidor então passa a esperar que o cliente responda. Se o servidor pediu um certificado do cliente, então ele ficará esperando até que o cliente envie o certificado. O cliente então envia uma mensagem de ClientKeyExchange e o conteúdo dessa mensagem dependerá do algoritmo de chave pública escolhido na fase de Hello. Caso o cliente tenha enviado um certificado com capacidade de assinatura, uma mensagem de digitally-signed certificate verify será enviada para verificar o certificado. Nesse ponto a mensagem ChangeCipherSpec será enviada pelo cliente e este copiará para a mensagem as informações pendentes sobre as Cipher Specs. Logo após essa mensagem o cliente envia uma mensagem Finished, já utilizando todos os parâmetros de segurança negociados. Em resposta o servidor manda uma mensagem de ChangeCipherSpec e logo após uma mensagem de Finished já com os parâmetros de segurança negociado sendo utilizados para enviar a mensagem. Agora os dois lados já podem começar a transmissão dos dados de forma segura.

            Para resumir uma sessão que já tem todos os parâmetros negociados, um processo mais simples é utilizado, o cliente envia uma mensagem ClientHello com o ID da sessão. O servidor então checa no seu cachê se possui os parâmetros daquela sessão. Se tiver e o servidor quiser resumir aquela sessão, então o servidor responde com uma mensagem ServerHello com o mesmo ID da sessão a ser resumida. Nesse momento ambos enviam uma mensagem de ChangeCipherSpec e procedem para o procedimento de encerramento do handshake com a mensagem Finished. Caso o servidor não encontre os parâmetros da sessão a ser resumida, todo o processo de handshake descrito acima terá de ser feito.

Fig. 4.3: Processo simplificado de handshake para resumir uma sessão já negociada