Expandir/Contrair
Clique nos títulos para ler o conteúdo
Desde o final dos anos 90 algumas grandes empresas já faziam vendas de produtos pela internet, o que ficou conhecido como e-commerce. Até hoje, as negociações realizadas através da internet vêm crescendo de forma desenfreada. Até mesmo os mais desconfiados já realizam compras pela rede ou ao menos acessam suas contas bancárias 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 realizamos transações financeiras, pagamos contas ou 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, funcionamento e protocolos e, então, mostraremos como foi derivado o TLS, uma solução gratuita para o protocolo da Netscape, explicitando algumas diferenças entre este e seu predecessor.
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:
Tabela 1 – Caminho, através dos sistemas, de Berlim a San Jose. [9]
A Figura 1, logo abaixo, 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 irá 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.
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.
Porém, espionagem não é a única ameaça para os usuários da Web. Há também o risco de se 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.
Ainda temos o desafio final encarado pelos usuários da Web, que é 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.
Encarando 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 os seus dados estão sendo compartilhados com confidencialidade, autenticação, segurança e integridade através da internet.
Os principais objetivos do SSL são:
Enfim, o SSL não é apenas um protocolo único, mas sim um conjunto de protocolos que podem ser divididos em duas camadas:
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 a 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, 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 que dizem respeito aos algoritmos de criptografia e funções hash a serem utilizados durante toda a comunicação. O servidor verifica a melhor (mais segura) opção de algoritmos e funções hash entre ele e o cliente e então decide o que será utilizado.
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:
Estabelecendo uma comunicação
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:
Na primeira fase, cliente e servidor decidem quais os algoritmos suportados por ambos que serão utilizados na comunicação (RSA, DAS, ECDSA). O cliente faz o pedido a um servidor que suporte o protocolo SSL por uma conexão segura e já envia uma lista com os algoritmos disponíveis para a encriptação e autenticação dos dados.
Na segunda fase o servidor recebe o pedido e escolhe o mais forte dentre os algoritmos da lista do cliente e que ele também possui e o avisa desta decisão. Ambos trocam chaves e realizam a autenticação – são utilizados algoritmos de chave pública (RSA, Diffie-Hellman, etc). Para sua autenticação, o servidor envia 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.
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 SSL 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 AC para validar sua assinatura 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.
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.
Protocolos
O SSL, como dito anteriormente, é dividido nos seguintes protocolos: Record Protocol, Handshake Protocol, Alert Protocol, e Change Cipher Spec. Como o Handshake Protocol já foi bem discutido no item anterior, seguem os restantes:
Record Protocol:
O SSL 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.
Alert Protocol:
O Alert Protocol foi desenvolvido para a troca de mensagens que dizem respeito ao funcionamento e transmissão de dados na conexão. Cada mensagem deste protocolo é composta por dois bytes, o primeiro para indicar seu caráter – que pode ser dos tipos "warning" ou "fatal". Quando algum dos lados da comunicação recebe um alerta de caráter fatal, a transmissão de dados é interrompida imediatamente. O segundo byte da mensagem carrega o código definido referente ao alerta ou erro ocorrido.
Change Cipher Spec:
É o mais simples de todos, pois consiste em somente uma mensagem. Esta mensagem significa que a sessão será passada para um estágio fixo e que a partir deste momento toda comunicação será criptografada de acordo com as negociações no Hello Protocol. Esta mensagem deve ser enviada tanto pelo cliente quanto pelo servidor. Após a troca das mensagens, a sessão é considerada aberta e todas as mensagens de dados ou qualquer outro protocolo serão transferidas utilizando o Record Protocol.
Como dito previamente, 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.
As diferenças entre o SSL e o TLS são muito pequenas e técnicas, porém eles possuem normas diferentes. O TLS tem a capacidade de trabalhar em portas diferentes e usa algoritmos de criptografia mais fortes como o keyed-Hashing for Message Authentication Code (HMAC) enquanto o SSL apenas Message Authentication Code (MAC). Além do que, a versão 1.0 do TLS não interopera com a versão 3.0 do SSL.
O TLS pode ser utilizado por uma autoridade intermediária, não sendo sempre necessário recorrer à raiz de uma Autoridade de Certificação.
O protocolo TLS foi criado como o sucessor do SSL. É mais freqüentemente usado como uma configuração nos programas de e-mail, mas assim como o SSL, o TLS pode ter um papel em qualquer transação cliente-servidor.
A internet se tornou um meio de comunicação essencial na vida de todos os cidadãos. Através dela podemos compartilhar mensagens, vídeos, músicas, notícias, idéias e opiniões, ou seja, dados em geral que podem ou não ter algum valor associado, que não seja necessariamente monetário. Além de todos esses dados, podemos realizar operações financeiras e comerciais, casos em que o valor monetário está explícito.
Todos estes dados, que podem representar muito dinheiro, necessitam de alguma garantia, para que nós possamos trabalhar com tranqüilidade, sem preocupações com fraudes, falsificadores ou qualquer atuador malicioso que possa interceptá-los. Devido a esta necessidade iminente, engenheiros envolvidos diretamente com o problema desenvolveram um protocolo para resolvê-lo, garantindo aos usuários da internet confiabilidade, integridade, autenticidade e segurança. O SSL/TSL se mostrou um protocolo robusto, confiável e amplamente utilizado na rede mundial de computadores, sendo aprovado pelos seus usuários e fornecedores de serviços.
Este trabalho apresentou uma breve história do surgimento do SSL a partir da necessidade de se garantir segurança na rede, como foi o seu desenvolvimento, a sua arquitetura e funcionamento e suas aplicações. Também abordamos o seu sucessor, o TSL, seu desenvolvimento, arquitetura e aplicações.
Depois de estudado este trabalho, o leitor teve a oportunidade de conhecer os protocolos de segurança mais utilizados na rede mundial de computadores, e também pôde compreender como é o funcionamento de um protocolo de segurança.