05/01/12
Funcionamento do TLS
Primeira Pgina
>
ltima Pgina
4. Funcionamento do TLS4.1 IntroduoO principal objetivo do
protocolo TLS garantir a privacidade e a integridade dos dados em
uma comunicao entre duas aplicaes. 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 confivel (por ex: TCP), provendo a segurana da conexo
que apresenta duas propriedades: A conexo privada. utilizada
criptografia simtrica para encriptao dos dados, por exemplo. As
chaves para esta encriptao simtrica so geradas unicamente para cada
conexo e so baseadas em um segredo negociado (ou negociao secreta)
por um outro protocolo, neste caso o protocolo Handshake. O
protocolo de Registro pode ser usado sem criptografia. A conexo
confivel. O transporte da mensagem inclui uma verificao da
integridade da mensagem, utilizando uma keyed-HMAC (Hashing Message
Authentication Code). Funes hash seguras so utilizadas para
computao da MAC. O protocolo de Registro pode operar sem uma MAC,
porm geralmente, s utilizado desta maneira, enquanto outro
protocolo est usando o protocolo de Registro como transporte para a
negociao dos parmetros de segurana. O protocolo de Registro usado
para o encapsulao de vrios protocolos de nveis acima, por exemplo,
o protocolo Handshake, que permite a autenticao entre cliente e
servidor e a negociao de algoritmos de encriptao e de chaves
criptogrficas antes da transmisso ou recepo do primeiro octeto de
dados por parte de um protocolo de aplicao. Os protocolos
Handshaking provem segurana da conexo que apresenta trs
propriedades: A identificao de uma das partes pode ser autenticada
atravs da criptografia assimtrica. Esta autenticao pode ser
opcional, mas geralmente exigida para pelo menos uma das partes. A
negociao de um segredo compartilhado segura. O segredo negociado
fica indisponvel para bisbilhoteiros, e para qualquer conexo
autenticada o segredo no pode ser obtido, mesmo por um atacante que
pode se colocar no meio da conexo. A negociao confivel. Nenhum
atacante pode modificar a comunicao da negociao sem ser detectado
pelas partes legtimas da comunicao. Uma vantagem do TLS a
independncia em relao aos protocolos de aplicao. Protocolos de nvel
acima podem comunicar com o TLS de forma transparente.
www.gta.ufrj.br/grad/06_1/ssl/func_tls.htm
1/5
05/01/12
Funcionamento do TLS
4.2 ObjetivosOs objetivos do protocolo TLS, em ordem de
prioridade, so: 1. Segurana com criptografia: TLS deve ser usado
para estabelecer uma conexo segura entre duas partes. 2.
Interoperabilidade: Programadores independentes devem conseguir
desenvolver aplicaes utilizando TLS que possam trocar parmetros
criptogrficos sem um conhecer o cdigo do outro. 3. Extensibilidade:
TLS busca o fornecimento de uma estrutura (framework), em que novos
mtodos de criptografia simtrica e assimtrica podem ser adicionados,
sem a necessidade da implementao de uma nova biblioteca de
segurana. 4. Eficincia Relativa: Operaes de criptografia,
principalmente de chave pblica, exigem um alto processamento. Sendo
assim, o protocolo TLS incorporou um mecanismo de armazenamento
para evitar que toda conexo ao ser estabelecida no precise
processar operaes de criptografia. Com isso, reduz-se tambm a
atividade da rede.
4.3 Protocolo de RegistroO TLS utiliza esta camada para
encapsular todas as mensagens dos demais protocolos das camadas
superiores, explicando a sua independncia com os protocolos de
aplicao, facilitando o desenvolvimento de aplicaes que necessitam
de conexes seguras. Enquanto os protocolos Handshaking realizam a
negociao de parmetros de segurana, o protocolo de Registro quem
realmente efetua as operaes necessrias para garantir a segurana da
conexo. O protocolo de Registro recebe as mensagens para serem
transmitidas, fragmenta os dados em blocos, opcionalmente realiza a
compresso dos dados, aplica o MAC, encripta e transmite o
resultado. Logicamente, com os dados recebidos, o protocolo de
Registro realiza a decriptao, verificao da integridade, realiza
descompresso, reagrupa os blocos e os entrega para as camadas
superiores.
4.4 Protocolos de HandshakingO TLS possui trs subprotocolos que
permitem s partes chegarem a um acordo sobre os parmetros de
segurana que sero utilizados na camada de registro para autenticao,
comunicao e para reportar condies de erro entre as partes. 4.4.1
Protocolo Handshake O protocolo de Handshake responsvel pelos
seguintes itens: Identificador da sesso: uma seqncia de bytes
escolhida pelo servidor para identificar uma sesso ativa ou uma
sesso reinicivel. Mtodo de compresso: qual o mtodo de compresso 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 criptogrficos 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 sesso pode ser utilizada para
iniciar novas conexes. Com os itens acima so criados os parmetros
de segurana para serem usados pela Camada de Registro para proteger
os dados. Muitas conexes podem ser retomadas usando a mesma sesso,
caso essa caracterstica seja suportada pela mesma. Isso evita que
todos os parmetros de segurana tenham que ser
www.gta.ufrj.br/grad/06_1/ssl/func_tls.htm
2/5
05/01/12
Funcionamento do TLS
novamente negociados. 4.4.2 Protocolo Change Cipher Spec O
protocolo Change Cipher Spec existe para sinalizar mudanas nas
estratgias de criptografia que estavam sendo utilizadas. Este
protocolo formado por apenas uma mensagem, a qual encriptada e
comprimida com os parmetros 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 alteraes nas estratgias de criptografia, pois existe a
possibilidade de que o primeiro a receber a mensagem de troca de
estratgia possa ainda estar computando uma mensagem que recebeu
anteriormente, j que os algoritmos de chave pblica demandam muito
processamento. Para resolver isso, deve ser esperado um tempo antes
de mandar essa mensagem para garantir que o outro lado no perder
informaes. 4.4.3 Protocolo de Alerta Um dos tipos de contedo
suportado pela camada de registros do TLS o contedo de alerta. As
mensagens de alerta transportam a importncia do alerta e a descrio
do alerta. Mensagens com importncia denominada fatal, resultam
imediatamente no encerramento da conexo. Nesse caso outras conexes
correspondendo mesma sesso podem continuar, mas o identificador da
sesso deve ser invalidado, prevenindo que essa sesso seja utilizada
posteriormente para estabelecer novas conexes. Assim como as outras
mensagens do TLS as mensagens de alerta tambm so encriptadas e
comprimidas de acordo com os parmetros de segurana que esto ativos
no momento em que a mensagem enviada. Tipos de mensagem de alerta:
1. Alertas de Encerramento So utilizados para informar s partes que
a conexo ser encerrada, evitando assim truncation attacks. Todos os
dados recebidos aps o recebimento de uma mensagem de encerramento
so 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 conexo. Clientes e servidores
devem esquecer quaisquer identificadores de sesses e chaves
secretas associados com uma conexo que falhou. Por conseguinte
qualquer conexo que tenha sido encerrada por um alerta fatal no
pode ser restabelecida. Exemplos de mensagem de erro so:
bad_certificate, certificate_expired, illegal_parameter, unknown
CA, insuffiecient security, entre outros. 4.4.4 Estabelecendo uma
conexo Os parmetros criptogrficos de uma sesso so 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 comeam a se comunicar eles tm que entrar em
acordo sobre qual verso ser utilizada, qual algoritmo criptogrfico
ser usado, opcionalmente autenticar um ao outro e usar criptografia
assimtrica para compartilhar um segredo a ser usado pela
criptografia simtrica, que responsvel 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 criptogrfico ser usado,
troca de valores aleatrios e checar se uma sesso est sendo
restabelecida. Troca dos parmetros criptogrficos necessrios para
permitir ao cliente e ao servidor chegarem a uma
www.gta.ufrj.br/grad/06_1/ssl/func_tls.htm
3/5
05/01/12
Funcionamento do TLS
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
parmetros de segurana negociados. Permitir que cliente e servidor
possam verificar se ambos esto usando os mesmos parmetros de
segurana e verificar se a negociao no foi interceptada por um
atacante. O processo de estabelecimento de uma conexo segura est
ilustrado na figura 4.2 abaixo.
Fig. 4.2: Processo completo de negociao As mensagens com * so
opcionais, ou seja, nem sempre so enviadas em todos os processos de
negociao. O processo de negociao mostrado acima pode ser explicado
da seguinte forma, o cliente envia uma mensagem de ClientHello para
o servidor, o servidor deve ento enviar de volta uma mensagem
ServerHello, caso contrrio um erro fatal ser caracterizado e a
conexo encerrada. As mensagens de Hello servem para estabelecer
quais as capacidades de segurana cada um dos lados possui. Essas
mensagens estabelecem os seguintes parmetros: verso do protocolo,
ID da sesso, Sute de Criptografia e mtodo de compresso.
Adicionalmente dois valores aleatrios so gerados e trocados,
ClientHello.random e ServerHello.random. Aps a troca das mensagens
de Hello o servidor poder enviar seu certificado, caso haja a
necessidade de autenticao. Alternativamente o servidor pode enviar
uma mensagem de ServerKeyExchange se no 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 sute de criptografia requeira tal caracterstica
do cliente. Depois dessa fase o servidor envia uma mensagem de
ServerHelloDone indicando que a fase de Hello da negociao acabou. O
servidor ento passa a esperar que o cliente responda. Se o servidor
pediu um certificado do cliente, ento ele ficar esperando at que o
cliente envie o certificado. O cliente ento envia uma mensagem de
ClientKeyExchange e o contedo dessa mensagem depender do algoritmo
de chave pblica 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 informaes pendentes
sobre as Cipher Specs. Logo aps essa mensagem o cliente envia uma
mensagem Finished, j utilizando todos os parmetros de segurana
negociados. Em resposta o servidor manda uma mensagem de
ChangeCipherSpec e logo aps uma mensagem de Finished j com os
parmetros de segurana negociado sendo utilizados para enviar a
mensagem. Agora os dois lados j podem comear a
www.gta.ufrj.br/grad/06_1/ssl/func_tls.htm
4/5
05/01/12
Funcionamento do TLS
transmisso dos dados de forma segura. Para resumir uma sesso que
j tem todos os parmetros negociados, um processo mais simples
utilizado, o cliente envia uma mensagem ClientHello com o ID da
sesso. O servidor ento checa no seu cach se possui os parmetros
daquela sesso. Se tiver e o servidor quiser resumir aquela sesso,
ento o servidor responde com uma mensagem ServerHello com o mesmo
ID da sesso 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 no encontre
os parmetros da sesso a ser resumida, todo o processo de handshake
descrito acima ter de ser feito.
Fig. 4.3: Processo simplificado de handshake para resumir uma
sesso j negociada
Primeira Pgina
>
ltima Pgina
www.gta.ufrj.br/grad/06_1/ssl/func_tls.htm
5/5
