SSL & TLS

SSL &TLS

Redes de Computadores I. GTA UFRJ

Autores

DRE: 108037434

Fernando Venancio Pinheiro

Gabriel Serafim Vieira

DRE: 110074167

Leonardo Gonçalves Da Silva

Já no ano 2000 a Dell vendia aproximadamente $18 milhões em equipamentos pela internet. Em 1999, 9 milhões de americanos já negociavam ações equivalentes a um terço de todo o mercado varejo de ações. 

Nesta mesma época, mais de 200 mil sites já aceitavam transações via e-commerce. Até hoje, as negociações realizadas na internet vêm crescendo de forma desenfreada. Até mesmo os mais desconfiados já realizam compras pela rede ou simplesmente acessam sua conta bancária através de portais dos grandes Bancos (Internet Banking). Pra se ter uma idéia, em 2010, só no Brasil

O faturamento através do e-commerce atingiu cerca de R$ 13 bilhões! [10]. 

Quase todos nós fazemos transações financeiras, pagamos contas e fazemos compras através da rede, trocando todo dia informações sensíveis através da internet. Estas informações sensíveis variam desde um simples e-mail pessoal até números de cartão de crédito.

Devido a esta quantidade absurda de dados sigilosos sendo compartilhada a todo o momento pela internet, a segurança se tornou um ponto cada vez mais crítico para os negócios, para as organizações e até para os cidadãos comuns. Para suprir esta necessidade existe um protocolo extremamente efetivo e amplamente utilizado. 

Este protocolo é o Secure Socket Layer, mais conhecido como SSL. 

O protocolo SSL juntamente com o seu sucessor, o Transport Layer Security (TLS), são o tema deste trabalho.

Abordaremos o surgimento do SSL, mostrando seu desenvolvimento, arquitetura e funcionamento e, então, mostraremos como foi derivado o TLS, uma solução gratuita para o protocolo da Netscape, explicando todos os seus protocolos.

SSL Tentativa de solução para segurança

Serviços de segurança específicos são necessariamente efetivos apenas contra riscos específicos; eles podem ser inapropriados para outras ameaças. Para entender o SSL, portanto, é necessário entender o ambiente para o qual ele foi desenvolvido.

Mesmo que o SSL seja um protocolo flexível que pode ser utilizado em muitas aplicações diferentes, a motivação original para seu desenvolvimento foi a internet. 

Os inventores de protocolos precisavam assegurar o comércio eletrônico e outras transações pela Web. Um ambiente de fato muito perigoso. Considere, por exemplo, o que acontece quando um usuário em Berlim executa uma compra online em um site de San Jose, California.

A Tabela 1 lista os sistemas através dos quais as mensagens do usuário terão que passar:

Servirá examinar o conteúdo das mensagens através da rota. É como se o usuário escrevesse o número do seu cartão de crédito em uma carta e a colocasse em uma garrafa. O usuário não tem controle sobre como esta mensagem atingirá o seu destino e qualquer um no caminho pode facilmente ler a sua carta. 

Tabela 1 – Caminho, através dos sistemas, de Berlim a San Jose. [9]

A Figura 1 mostra que a mensagem enviada pelo usuário contendo informações sensíveis, como número de cartão de crédito, pode percorrer um caminho complexo da Alemanha à Califórnia, atravessando diversos países, permeando muitas redes diferentes, através de instalações variadas. Algumas destas instalações podem pertencer a empresas privadas, muitas das quais não estão sujeitas a uma regulamentação ou a algum tipo de lei que garanta a privacidade das informações que elas transportam.

Nem o usuário, nem o servidor possuem controle a respeito do caminho que suas mensagens seguirão, também não podem controlar quem

O comércio eletrônico não pode estar à mercê de um ambiente tão inseguro. Informações sensíveis têm de ser mantidas confidenciais enquanto atravessam a rede.

Figura 1 – Caminho físico da Alemanha à Califórnia.

Espionagem não é a única ameaça para os usuários da Web. É teoricamente possível desviar mensagens para um site falso. Tal site falsificado pode prover informação maliciosa, coletar dados como o número de um cartão de crédito com impunidade, ou causar algum outro prejuízo. A internet precisa de um modo de garantir a identidade dos seus usuários.

O desafio final encarado pelos usuários da Web é a integridade das mensagens. Um usuário operando online no mercado financeiro certamente não vai gostar que suas instruções sejam alteradas (De forma intencional ou não) a tal ponto de que a mensagem "Venda quando o preço atingir R$200" seja recebida como "Venda quando o preço atingir R$20". Neste caso, a pequena falha representada por um 0 pode causar um estrago na fortuna de alguém.

SSL – Surgimento e desenvolvimento

De frente a esta situação crítica que é a massa de dados sensíveis sendo compartilhada, a segurança na internet, sem dúvidas, se tornou um fator crucial. Felizmente, engenheiros estiveram pensando a respeito deste ponto crítico desde o início da Web. 

A Netscape Communications já considerava riscos de segurança desde o desenvolvimento do seu primeiro navegador Web. Para garantir o sossego em relação às nossas preocupações, a Netscape desenvolveu o Secure Socket Layer protocol.

Abaixo, um diagrama mostrando a evolução do SSL em paralelo à internet:



Figura 2 - SSL foi desenvolvido juntamente com os primeiros navegadores Web. [9]

SSL é um protocolo que permite a transmissão de informações através da internet de forma criptografada. O SSL garante que a informação seja enviada, sem alterações e exclusivamente para o servidor para o qual pretende enviar. Os sites de compras online com freqüência utilizam esta tecnologia para proteger suas informações, como dados de cartão de crédito.

O protocolo SSL foi originalmente desenvolvido pela Netscape para garantir a segurança dos dados transportados através das camadas de aplicação HTTP, LDAP e POP3. O intuito inicial foi utilizar o protocolo TCP como a camada de comunicação para prover uma conexão fim-a-fim, segura e autenticada, confiável entre dois pontos na rede. 

Mesmo assim, o SSL pode ser utilizado para proteção de informação em trânsito em situações relacionadas a qualquer serviço de rede. É utilizado principalmente em servidores HTTP e aplicações do cliente. Hoje, praticamente todos os servidores HTTP suportam uma sessão SSL.

Figura 3 - SSL entre os protocolos de aplicações e a camada TCP/IP. [1]

A Netscape Communications desenvolveu as primeiras três versões do SSL com uma assistência significante da comunidade Web. Apesar do desenvolvimento do SSL ter sido "aberto" e a própria Netscape ter encorajado outros da indústria a participar, o protocolo tecnicamente pertence à Netscape (de fato, a Netscape recebeu a patente dos EUA). Entretanto, em 1996 o desenvolvimento do SSL se tornou responsabilidade de uma organização internacional de padrões – Internet Engineering Task Force (IETF). O IETF desenvolve muitos dos protocolos padrões para a internet, incluindo, por exemplo, TCP/IP. Para evitar qualquer imparcialidade em relação a alguma empresa em particular, o IETF renomeou SSL para Transport Layer Security (TLS).

Hoje em dia praticamente todos os navegadores e servidores Web suportam o SSL. Pode-se observar o prefixo "HTTPS:" para uma URL segurada pelo SSL, alguns navegadores também exibem um pequeno ícone para indicar segurança. Ou seja, o SSL funciona sem que o usuário se preocupe com o que está acontecendo, apenas tendo a certeza de que está executando o seu trabalho com confidencialidade, autenticação, segurança e integridade através da internet.

Os principais objetivos do SSL são:

1. Autenticar o cliente e o servidor entre si;  
2. Garantir a integridade dos dados: Durante uma transmissão, dados não podem ser alterados (seja de forma intencional ou não); 
3. Segurar a privacidade dos dados: As informações trocadas entre cliente e servidor devem ser protegidas de interceptação e só devem ser lidas apenas pelo destinatário. Este pré-requisito é necessário tanto para os dados associados ao protocolo propriamente dito, quanto para os dados do aplicativo que é enviado durante a sessão. SSL não é apenas um protocolo único, mas sim um conjunto de protocolos que podem ser divididos em duas camadas:  

O protocolo para garantir a segurança e integridade dos dados: Esta camada é composta pelo SSL Record Protocol;

Os protocolos que visam estabelecer uma conexão SSL: Três protocolos são utilizados nesta camada. O SSL Handshake Protocol, o SLL ChangeCipher SpecProtocol e o SSL Alert Protocol;

SSL – Arquitetura e funcionamento

O protocolo SSL define dois papéis diferentes para as partes na comunicação: Cliente e Servidor. Esta distinção é muito importante, porque o SSL exige que cada um dos sistemas se comporte de forma ímpar.

O Cliente é o sistema que inicia uma comunicação segura; O servidor responde ao pedido do cliente. No modo mais comum de aplicação do SSL, a navegação Web segura, o navegador (Firefox, iExplorer, Chrome, etc...) é o cliente e o site é o servidor. Estes dois papéis se aplicam a todas as aplicações que usam o SSL.

Para o SSL, propriamente dito, as distinções mais importantes entre cliente e servidor são suas ações durante a negociação dos parâmetros de segurança. 

Logo que o cliente inicia a comunicação, ele tem a responsabilidade de propor ao servidor um grupo de opções do SSL para utilizar na negociação. 

O servidor escolhe dentre as opções do cliente, decidindo qual dos sistemas utilizarão realmente. Apesar de a decisão final ser tomada pelo servidor, este tem que escolher entre as opções dadas pelo cliente.

Quando o cliente e o servidor se comunicam, eles o fazem trocando mensagens. 

Abaixo listaremos todas as possíveis mensagens em uma comunicação SSL:

1. Alerta – Informa à outra parte de uma possível brecha na segurança ou falha de comunicação.
2. ApplicationData – Informação real que as duas partes irão trocar entre si, que é criptografada, autenticada e/ou verificada por SSL.
3. Certificate – Uma mensagem que carrega o certificado da chave pública do remetente.
4. CertificateRequest – Uma solicitação do servidor para que o cliente forneça seu certificado da chave pública.
5. CertificateVerify – Uma mensagem do cliente que verifica que ele conhece a chave privada correspondente à sua chave pública certificada.
6. ChangeCIpherSpec – Um indicador para começar a utilizar serviços de segurança acordados.
7. ClientHello – Uma mensagem do cliente indicando os serviços de segurança que ele deseja e que ele é suporta.
8. ClientKeyExchange – Uma mensagem do cliente carregando as chaves criptográficas para as comunicações.
9. Finished – Uma indicação de que todas as negociações iniciais estão completas e uma comunicação segura foi estabelecida.
10. HelloRequest – Um pedido do servidor para que o cliente inicie (Ou reinicie) o processo de negociação.
11. ServerHello – Uma mensagem do servidor indicando os serviços de segurança que serão utilizados para a comunicação vigente.
12. ServerHelloDone – Uma indicação do servidor de que ele completou todos os seus pedidos para o cliente para estabelecer a comunicação.
13. ServerKeyExchange – Uma mensagem do servidor carregando as chaves criptográficas para a comunicação.

Estabelecendo uma comunicação

O processo de comunicação do SSL é ilustrado na Figura 4, logo abaixo:

Figura 4 – Comunicação com o SSL. [9]

1. Cliente envia a mensagem ClientHello propondo as opções de SSL.

2. O servidor responde com a mensagem ServerHello dizendo quais opções serão utilizadas naquela comunicação.

3. O Servidor envia sua chave pública.

4. O Servidor conclui sua parte da negociação.

5. O Cliente envia as informações da chave de sessão (Criptografada com a chave pública do servidor).

6. O cliente envia a mensagem ChangeCipherSpec para ativar as opções negociadas para as mensagens seguintes.

7. Cliente envia a mensagem Finished.

8. Servidor envia a mensagem ChangeCipherSpec para ativar as opções negociadas para as mensagens seguintes.

9. Servidor envia Finished.

TLS – Um sucessor


Como dito anteriormente, a partir de 1996 o TLS foi o nome adotado pela IETF para desenvolver um protocolo de segurança padronizado baseado no SSL 3.0.

Existem algumas pequenas diferenças entre SSL e TLS. Entretanto, o protocolo permanece substancialmente o mesmo – tanto é verdade que o protocolo TLS 1.0 é por vezes identificado como SSL 3.1. É muito comum encontrar aplicações que suportam ambos (SSL/TLS). Os dois protocolos não inter-operam (somente um deve ser escolhido no momento da negociação).

Em projetos relacionados a servidores, especialmente de opensource, o protocolo TLS está substituindo o SSL. Para os clientes, o protocolo SSL3 é praticamente um padrão (normalmente, o TLS é padrão, mas rotineiramente ele tem que se rebaixar ao SSL).

Quando se trata de aplicações web utilizando um navegador, na maioria das vezes o TLS funciona unilateralmente. Ou seja, somente o servidor é autenticado. É feito assim pela funcionalidade e pelo tipo de negócio de que se trata. Normalmente é o usuário que precisa saber da autenticidade do servidor para compras on-line. Mesmo assim, o TLS também suporta o modo bilateral de conexão, no qual os dois lados são autenticados e têm certeza de com quem estão "falando". Este modo é chamado de autenticação mútua.

TLS – Funcionamento

O início de uma comunicação TLS compreende basicamente três fases, que chamamos de Handshake Protocol:

1. Negociação dos algoritmos a serem utilizados
2. Troca de chaves (segredos) e autenticação
3. Encriptação simétrica e autenticação de mensagens

Na primeira fase, cliente e servidor decidem quais os algoritmos suportados por ambos que serão utilizados na comunicação (RSA, DAS, ECDSA). Na segunda fase ambos trocam chaves e, realizando a autenticação – são utilizados algoritmos de chave pública (RSA, Diffie-Hellman, etc). Na terceira fase as mensagens são autenticadas por códigos gerados por funções hash HMAC-MD5 ou HMAC-SHA. Daí em diante as mensagens são trocadas com integridade, segurança e autenticação depois de passarem pelo TLS Record Protocol.

Na maioria dos casos, a autenticação do servidor é feita através de uma Autoridade Certificadora (AC). Neste caso, o cliente utiliza uma chave pública da própria para validar a assinatura da AC no site do servidor. A AC deve estar na lista de AC's confiáveis para ter certeza de que o servidor é quem ele diz ser.

TLS – Protocolos


O TLS é dividido nos seguintes protocolos: Record Protocol, Handshake Protocol, Alert Protocol, e Change Cipher Spec.

Record Protocol:

O TLS se comunica através de pacotes, que encapsulam os dados que estão sendo trocados. O Record Protocol funciona de maneira a tratar essa comunicação na entrada e saída de dados da camada. Ele recebe os dados das camadas superiores, encapsula, encripta e/ou adiciona Message Authentication Codes (MACs) para garantir a segurança, integridade e autenticação das mensagens e as envia ao destinatário que deve fazer o processo inverso. Assim vemos que possui independência em relação aos protocolos de aplicação.

Handshake Protocol:

Toda comunicação começa através do Handshake Protocol. O cliente e o servidor negociam uma conexão segura através de uma série de passos, nos quais devem decidir os algoritmos a serem usados e gerar segredos, que são geralmente números aleatórios. 

Baseia-se nas seguintes etapas:

1. O cliente faz o pedido a um servidor que suporte o protocolo TLS por uma conexão segura e já envia uma lista com os algoritmos disponíveis para a encriptação e autenticação dos dados. 
2. O servidor recebe o pedido e escolhe o mais forte dentre os algoritmos da lista do cliente e que ele também possui e avisa o cliente desta decisão.  
3.  O servidor envia ao cliente sua identificação na forma de um certificado digital. Este certificado normalmente contém o nome do servidor, a Autoridade Certificadora para verificação e sua chave pública.

Assim feito, o cliente pode verificar com a AC sobre a autenticidade do servidor e continuar a comunicação.

Alert Protocol:

Em construção...

Change Cipher Spec:

Em construção...

Conclusão

Fonte: I. GTA UFRJ