protocolo ssl de rede

7/29/2019 Protocolo SSL de Rede

1/41

UNIO EDUCACIONAL MINAS

GERAIS S/C LTDAFACULDADE DE CINCIAS APLICADAS DE MINAS

Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000

CST EM REDES DE COMPUTADORES

PROTOCOLO SSL


2/41


3/41

SUMRIO

PROTOCOLO SSL................................................................................................................................................ .6

CAMADAS................................................................................................................................................................8PROCESSOS...............................................................................................................................................................9

PROTOCOLO CHANGE CIPHER SPEC.........................................................................................................11

PROTOCOLO ALERT........................................................................................................................................12

PROTOCOLO HANDSHAKE............................................................................................................................13

SEGURANA........................................................................................................................................................15

ALGORITMOS UTILIZADOS........................................................................................................................................15ATAQUES...............................................................................................................................................................16

ARQUITETURA...................................................................................................................................................19

SSL INTERFACE.................................................................................................................................................21

READPORT.............................................................................................................................................................21WRITEPORT...........................................................................................................................................................22RECORD.................................................................................................................................................................22SSL MANAGER......................................................................................................................................................22

RELAO CLIENTE/SERVIDOR....................................................................................................................23

DESCRIODAS MENSAGENSTROCADASENTRECLIENTE/SERVIDOR.................................................................................25

O PROTOCOLO OPENSSL................................................................................................................................28

O PROTOCOLO TLS..........................................................................................................................................29

HTTPSVS. SHTTP...............................................................................................................................................29


4/41

TROCA DE CHAVE E ASSINATURA USANDO RSA...................................................................................30

TROCADECHAVES DIFFIE-HELLMANEASSINATURAUSANDO RSA................................................................................30TROCADECHAVES DIFFIE-HELLMANEASSINATURAUSANDO DSA................................................................................31TROCADECHAVES DIFFIE-HELLMANANNIMO...........................................................................................................31

TROCA

DE

CHAVES

USANDO

RSA.............................................................................................................................33CERTIFICATE_VERIFY ................................................................................................................................34FINISHED..........................................................................................................................................................34

INFRA ESTRUTURA DE CHAVE PBLICA (PUBLIC KEY INFRASTRUCTURE- PKI)..................35

CERTIFICADO DIGITAL..................................................................................................................................36

PREOCUPAES CAUSADAS PELO PROTOCOLO SSL..........................................................................38

CONCLUSES.....................................................................................................................................................39


5/41

5


6/41

PROTOCOLO SSL

O protocolo SSL (Secure Sockets Layer) criado pela Netscape Corporation vem se

tornando sinnimo de segurana para aplicaes que utilizam a internet para

efetuarem negcios on-line na Web. O SSL foi concebido primordialmente pela

necessidade de se ter um mecanismo que possibilitasse o sigilo absoluto dos dadose a garantia de autenticidade dos mesmos nas transaes eletrnicas on-line. Desde

sua concepo, o protocolo SSL vem se tornando padro de fato a cada dia, porm

a implementao do protocolo SSL em sua forma pura; ou seja, utilizando somente

suas tcnicas de criptografias oferecidas por ele j no so suficientes para garantir

uma segurana tolervel nos negcios on-line (h um tpico neste trabalho que

cobre um estudo de caso de implementao SSL na sua forma pura). Sendo assim,

novos mecanismos foram surgindo para adicionar um maior nvel de segurana aoprotocolo SSL.

Este, foi projetado para rodar sobre protocolos de transporte confiveis, porm

estaremos considerando somente o uso do SSL sobre o protocolo TCP, por se tratar

do principal protocolo de transporte da Internet. Neste protocolo, clientes e

servidores podem se autenticar e ento trocar dados cifrados entre si. As principais

caractersticas do SSL so:

Segurana em conexes cliente/servidor: o SSL garante o sigilo dos dadostrocados entre as partes envolvidas na conexo atravs do uso de criptografia

6


7/41

simtrica. A fim de evitar que as mensagens, mesmo decifradas, sejam

modificadas e com isso um ataque de escuta ativa seja possvel, o SSL

adiciona todas as mensagens um MAC (Message Authentication Code).

Calculado a partir de funes de hash seguras, o MAC garante a integridade

das mensagens trocadas. Alm de sigilo e integridade, o SSL ainda prov a

autenticao das partes envolvidas a fim de garantir e verificar a identidade

das mesmas. Neste processo, o SSL utiliza criptografia assimtrica e

certificados digitais.

Independncia de protocolo: o SSL roda sobre qualquer protocolo de

transporte confivel. Porm, a maioria das implementaes so feitas para

redes TCP/IP.

Interoperabilidade: dado a sua especificao bem detalhada e o uso de

algoritmos criptogrficos conhecidos, diferentes implementaes do protocolo

tem a garantia de interagir entre si.

Extensibilidade: dado a necessidade, permitir que novos parmetros e

mtodos de criptografia (assimtrica ou simtrica) sejam incorporados ao

protocolo, sem que seja necessria a criao de um novo protocolo ou a

implementao inteira de uma nova biblioteca.

Eficincia: devido a demanda por recursos computacionais que este tipo de

operao requer, o protocolo dispe da opo de armazenamento em cache

de informaes referentes a sesso, diminuindo desta forma o esforo

computacional em sucessivas conexes.

Vantagens: O SSL preenche todos os critrios que o fazem aceitvel para o usonas transmisses das mais sensveis informaes, como dados pessoais e nmeros

do carto de crdito. A aplicao pode optar entre utilizar todos ou somente uma

parte desses critrios dependendo do tipo e natureza das transaes que esto

sendo efetuadas.

A criptografia a arte de empregar certas regras em mensagens ou informaes de

forma a esconder seu verdadeiro contedo. A mensagem ou informao codificada

pelo uso da criptografia, que pode ser transmitida por meios de comunicao

7


8/41

considerados inseguros, pois s o receptor, conhecedor das regras poder reverter

o processo e ler o documento original.

Com o SSL, uma conexo estabelecida onde todos os dados trafegam

criptografados pela rede, sem que haja o risco de serem interceptados e decifrados

por algum. Para garantir a integridade dos dados, necessrio um protocolo

seguro para orientar a conexo, como por exemplo, o TCP/IP. O uso do SSL se

disseminou por meio de sua implementao nos EURZVHUV da Netscape,

fornecendo aos usurios uma forma segura de acessar servidores ZHE, permitindo

inclusive a execuo de transaes comerciais. Sua verso mais recente a 3.0.

Seu funcionamento ocorre por meio do sistema de criptografia de chaves pblicas

e privadas desenvolvido por Rivest, Shamir e Adleman, o RSA. O SSL mais usadonos browsers, como Netscape, Internet Explorer entre outros, no caso o protocolo

HTTP, que mais usado por usurios com menos experincia e que necessitam de

maior segurana para acessar uma pgina de banco, por exemplo.

Camadas

O protocolo SSL dividido em duas camadas. A de mais baixo nvel, que interage

com o protocolo de transporte, a camada Record. Esta camada responsvel por

encapsular os dados das camadas superiores em pacotes compactados e cifrados e

repass-los para a camada de transporte. Entre as camadas superiores est a outra

camada do SSL, a camada de Handshake. Esta camada permite que a aplicao

servidora e a aplicao cliente autentiquem-se e negociem os algoritmos de

cifragem e as chaves criptogrficas antes que o protocolo de aplicao receba ou

envie seu primeiro byte.

8

SSL

APLICAO

HANDSHAKE

RECORD

TCP/IP


9/41

Figura 1- Camadas do protocolo SSL

A camada Record recebe dados no interpretados de camadas superiores em forma

de bloco de dados cujo tamanho variado. Estes blocos so encapsulados emregistros e, dependendo do seu tamanho, devem sofrer uma fragmentao. Os

dados contidos neste registro sofrem ainda uma compactao e, em seguida, so

cifrados usando os algoritmos e chaves definidos pelo processo de handshake. Os

protocolos internos da camada de Handshake e os processos executados na

camada Record.

Figura 2 - Protocolos Handshake e processos Record

Processos

- Processo de Fragmentao: neste processo, os dados originados das camadassuperiores, aplicao e Handshake, so fragmentados em blocos de, no mximo,

214 bytes. Estes blocos so empacotados gerando uma SSL PlainText. O pacote

SSL PlainText alm do bloco de dados, contm ainda a informao do tipo destes

dados, ou seja, que entidade os enviou (dados de aplicao ou de protocolos da

camada Handshake).

- Processo de Compactao: neste processo, os fragmentos resultantes do processo

de fragmentao so compactados de acordo com o mtodo de compactao

escolhido. Na verso atual do protocolo, nenhum algoritmo de compactao

9

HANDSHAKE CCS ALERT

FRAGMENTAO

COMPRESSO

ENCRIPTAO

HANDSHAKE

RECORD


10/41

especificado. Porm, todas as implementaes devem aceitar um tipo de

compactao, o CompressionMethod.null, a qual no realiza nenhuma modificao

sobre os dados. O resultado deste processo um pacote SSL Compressed . O

tamanho do bloco de dados contido no SSL Compressed, aps a compactao, no

pode exceder 214 + 1024 bytes. Este processo tambm responsvel pela

operao inversa, ou seja, a descompactao dos pacotes resultantes do processo

de decifragem. O processo de descompactao responsvel por assegurar que os

dados, aps descompactados, no causem nenhum estouro de buffer.

considerado erro toda vez que um bloco de dados apresente tamanho maior a 214

bytes aps a sua descompactao.

- Processo de Cifragem: este o principal processo da camada Record. O processo

de cifragem responsvel por proteger os dados enviados entre as partes, atravs

do uso de cifras e cdigos MAC Os algoritmos usados neste processo so

resultantes da fase de handshake a qual determina a cipher spec (parte da cipher

suite que indica o algoritmo simtrico e a funo de hash) que dever ser usada pela

camada Record. A integridade das mensagens trafegadas numa conexo SSL

obtida com o uso de MACs (Message Authentication Code) que so calculados a

partir de um conjunto de dados usando funes de hash seguras. Na Record, os

MACs tm uma caracterstica a mais, a presena de um segredo o qual garante que

o resultado do hash no poder ser forjado por outro que no aquele que conhece o

segredo. A forma em que os dados devero ser cifrados depender do tipo de

algoritmo simtrico escolhido, ou seja, cifra de bloco ou encadeada. Em ambos os

casos, o dado cifrado o bloco de dados compactado no processo anterior,

acrescentado do MAC. No caso de cifra de bloco, o pacote a ser enviado para a

rede conter tambm um padding, quando necessrio, a fim de alcanar o tamanho

do bloco. Este padding acrescentado e retirado respectivamente nos processos de

cifragem e decifragem. O resultado do processo de cifragem um pacote SSL

Cipher Text que dever ser enviado pela rede para o outro lado da comunicao.

A camada de Handshake a responsvel pelos processos de troca de chaves,

autenticao e estabelecimento de chave de sesso feitas no SSL. Nela, encontram-

se os protocolos Handshake, Change Cipher Spec (CCS) e Alert. Cada um destes

protocolos desempenha um papel bem definido no SSL, mesmo havendo uma

grande interao entre eles durante os processos descritos acima. Um conceito

10


11/41

importante para o entendimento desta camada o de sesso no SSL. Uma sesso

SSL composta por um conjunto de dados que so gerados aps um processo de

handshake completo. Uma sesso dada como sendo dependente do estado. O

protocolo Handshake o responsvel por manter a consistncia dos estados de

uma sesso tanto no cliente quanto no servidor. Uma mesma sesso SSL pode

incluir vrias conexes, ou seja, a partir dos mesmos dados que formam uma

sesso pode-se abrir mltiplas conexes SSL. Os dados que formam uma sesso

so os seguintes:

session ID: um valor arbitrrio escolhido pelo servidor para identificar esta

sesso;

peer certificate: usado para certificar uma organizao. Est no formato X.509

e dentre outras coisas encontra-se dentro dele a chave pblica da entidade

que est utilizando aquela aplicao;

compression method: algoritmo usado na compresso dos dados;

cipherspec: especifica que conjunto de algoritmos de cifragem e de hash

sero utilizados;

Mastersecret: um segredo de 48 bytes compartilhado pelo servidor e pelo

cliente;

IsResumable: flag utilizada para indicar se a sesso pode ou no ser

retomada ao iniciar uma nova conexo.

PROTOCOLO CHANGE CIPHER SPEC

Este protocolo formado por uma nica mensagem, a change_cipher_spec. Sua

funo sinalizar alguma modificao nas estratgias ou parmetros de segurana

utilizados. Quando uma das partes do protocolo recebe uma mensagem

change_cipher_spec durante o processo de Handshake, ela automaticamente troca

as informaes do estado corrente de leitura (estratgia atual) pelos dados do

estado pendente de leitura (estratgia recm negociada). J quando uma das partes

envia uma change_cipher_spec, ela automaticamente deve atualizar seu estado

corrente de escrita para o estado pendente de escrita. Qualquer mensagem enviada

11


12/41

ou recebida aps esta mensagem ser trabalhada utilizando a nova estratgia de

segurana, negociada no processo de handshake. Esta mensagem sempre

preceder a mensagem de FINISHED. Uma mensagem change_cipher_spec

inesperada ocasiona o envio de um alerta unexpected_message.

PROTOCOLO ALERT

O SSL possui um simples tratamento de erro. Para cada erro gerado enviada uma

mensagem de alerta para o outro lado da conexo. Dependendo do nvel do erro a

conexo abortada. As mensagens de alerta so tratadas como mensagens

normais, sendo assim, sofrem compactao e cifragem. Os nveis das mensagensde alerta so warnings e fatals. Os warnings so simples avisos que informam que

alguma coisa no normal aconteceu ou foi detectada. Estes tipos de alertas podem

gerar um fechamento da conexo dependendo da forma em que o SSL foi

implementado. Os alertas fatais sempre ocasionam o fechamento da conexo. Estes

alertas dizem respeito ao comprometimento de algum segredo ou deteco de

alguma falha durante a conexo. Todos os dados a respeito de uma sesso devem

ser apagados (sesso invalidada) quando um erro fatal enviado ou recebidodurante uma conexo. So mensagens de alertas suportadas pela verso atual do

protocolo so as seguintes:

close_notify: warning, sinaliza o fechamento de uma conexo SSL;

unexpected_message: fatal, indica o recebimento de uma mensagem fora de

ordem;

bad_record_mac: fatal, indica que a verificao do MAC da mensagem

recebida no coincidiu;

decompression_failure: fatal, indica que o processo de descompactao

resultou num bloco maior que 214 bytes;

handshake_failure: fatal, indica algum problema na negociao das

informaes de segurana;

no_certificate: indica que o cliente no possui nenhum certificado que

coincida com os tipos pedidos;

12


13/41

bad_certificate: indica que o certificado recebido possui uma assinatura no

vlida;

unsupported_certificate: indica recepo de certificado cujo o tipo no suportado;

certificate_revoked: indica que o certificado foi revogado por quem o assinou;

certificate_expired: indica que a data de validez do certificado expirou ou, de

que este ainda no esta vlido;

certificate_unknown: indica qualquer outro problema relacionado com falhas

no certificado;

illegal_parameter: fatal, indica que algum campo de alguma mensagem

trafegada durante o handshake est fora do seu intervalo ou incoerente com

outro campo.

PROTOCOLO HANDSHAKE

O Protocolo Handshake a principal parte do SSL. Ele constitudo por duas fases.

Na primeira, feita a escolha da chave entre o cliente e o servidor, a autenticao

do servidor e a troca da chave Master. J na segunda, feita a autenticao do

cliente (se requerida) e o fim do handshake. Aps o handshake estar completo, a

transferncia de dados entre aplicaes pode ser iniciada. As mensagens do

protocolo Handshake segue o formato abaixo, onde: Handshake-Type: indica o tipo

de mensagem de handshake sendo enviada; Tamanho: tamanho do corpo em bytes;

Corpo: so os dados da mensagem sendo enviada.

HANDSHAKE TYPE TAMANHO CORPO

Figura 3 Formato da mensagem do protocolo Handshake

O processo de handshake pode ser realizado de diferentes formas dependendo se

h autenticao ou no das partes envolvidas e/ou se uma sesso retomada. A

figura abaixo mostra uma possvel execuo do processo de handshake. As

mensagens trocadas esto descritas na figura 1.

13

CLIENTE

SE

RVIDOR


14/41

Figura 4 Execuo do processo handshake

Cliente envia um nmero aleatrio e uma lista de cifras e mtodos de compresso

que estaria apto a negociar com o servidor (mensagem CLIENT_HELLO).

Servidor retorna seu aleatrio e a cifra e mtodo selecionados (mensagem

SERVER_HELLO).

Caso o servidor deva se autenticar (condio j sabida a partir da cipher suite

negociada), este envia seu certificado, o qual conter sua chave pblica

(SERVER_CERTIFICATE). O tipo de certificado enviado depender da cipher suite

negociada.

Caso seja necessria a autenticao do cliente, o servidor envia um pedido de

certificado ao cliente (mensagem CERTIFICATE_REQUEST) e sinaliza ao cliente

que a fase de HELLO est finalizada (mensagem SERVER_HELLO_DONE).

Cliente ento responde ao servidor, enviando seu certificado (mensagem

CLIENT_CERTIFICATE).

Cabe, ao cliente, a gerao do segredo a ser utilizado futuramente como chave de

sesso. Sendo assim, O cliente gera tal segredo e o envia (cifrado com a chave

pblica retirada do certificado do servidor) ao servidor (mensagem

CLIENT_KEY_EXCHANGE).

Caso o certificado do cliente tenha capacidade de assinatura, o mesmo capaz de

verificar sua autenticidade. Neste caso, efetuada a autenticao do cliente atravs

da mensagem CERTIFICATE_VERIFY.

14


15/41

Ambos os lados possuem agora as chaves de sesso a serem utilizadas. Uma

ltima mensagem enviada (mensagem FINISHED - j decifrada com os segredos

negociados) por ambas as partes, checada (a fim de evitar ataques por

espelhamento) e o processo de handshake finalizado.

SEGURANA

Existem trs componentes principais para um site Web seguro:

1. Servidor: o melhor lugar da Internet para armazenar o Web Site.

2. Software Seguro: este o software instalado no servidor, que faz todo o trabalho

de criptografia.

3. Certificado Digital: como uma "identidade digital".

O SSL composto por quatro mecanismos de segurana:

Autenticao - Identifica a fonte dos dados;

Integridade - Garante que dados no foram indevidamente alterados;

Criptografia - Garante a privacidade dos dados;

Troca de chaves criptogrficas - Aumenta a segurana do mecanismo de

criptografia utilizado.

Algoritmos Utilizados

Existem quatro grupos que podem representar o conjunto de algoritmos

criptogrficos utilizados pelo protocolo SSL. So estes:

Algoritmos simtricos: estes algoritmos so utilizados no sigilo dos dados

trafegados durante uma sesso SSL. Na atual especificao do SSL so

usados os algoritmos RC4, DES, 3DES, RC2, IDEA e Fortezza (carto

PCMCIA que prov tanto cifragem como assinatura digital).

15


16/41

Algoritmos assimtricos e de derivao de chaves: algoritmos utilizados para

a troca de chaves e para o processo de assinatura digital. Neste grupo esto

o RSA, o DSA(somente assinatura) e o Diffie-Hellman (derivao de chaves).

Algoritmos de hash: usados para prover a integridade das mensagens

enviadas e no processo de criao dos segredos. So especificados o MD5 e

o SHA.

Algoritmos de compactao: na atual verso do SSL no h nenhuma

especificao para funes de compactao.

Estes algoritmos so escolhidos no protocolo atravs do uso das cipher suites. As

cipher suites so combinaes dos algoritmos listados acima e possuem a seguinte

regra geral: PROT_KE_SIGALG_WITH_SIMALG_MAC onde, PROT na atual

especificao o valor SSL; KE o algoritmo de troca de chaves; SIGALG o

algoritmo usado para as assinaturas digitais; SIMALG o algoritmo simtrico; e

MAC o algoritmo de hash usado nos MACs. Nem todas as cipher suites possuem

todas esses componentes. Por exemplo, a cipher suite

SSL_RSA_WITH_RC4_128_SHA no possui o componente SIGALG. Isto ocorre

porque o algoritmo RSA tanto usado para a troca de chaves como para o processo

de assinatura. Uma outra exceo a essa regra so as cipher suites de exportao,

as quais possuem alm dos componentes acima, a componente _EXPORT_ antes

do WITH, sinalizando que os algoritmos usados nesta cipher suite sofrem as

limitaes impostas pelo governo americano para algoritmos criptogrficos.

Ataques

Os protocolos de segurana precisam oferecer proteo a tipos e mtodos de

ataque. Mesmo com os algoritmos criptogrficos fazendo a proteo dos dados de

aplicao, o protocolo deve resistir a ataques maliciosos. O SSL oferece proteo

contra as seguintes classes de ataque:

1. Integridade: devido a presena de MACs nos pacotes Record, um invasor no

consegue alterar estes pacotes sem que sua ao seja detectada. Qualquer

modificao posterior aos pacotes ocasiona queda automtica da conexo. A

integridade dos dados mantida mesmo nos casos onde a cifragem no usada.

16


17/41

2. Autenticidade: o seqestro de sesso um ataque autenticidade dos dados,

pois envolve a quebra de uma sesso atravs da personificao das partes. O SSL

evita este tipo de ataque com o processo de autenticao de servidores e clientes.

3. Personificao: Apesar de verses antigas possibilitarem este tipo de ataque,

modificaes foram feitas no protocolo de modo a evit-lo. O SSL usa certificados

para a autenticao de servidores, o que impossibilita a personificao dos

mesmos.

Alm disso, a ltima mensagem trocada durante o processo de handshake

(FINISHED) executa uma verificao de todas as mensagens trocadas at o

momento, evitando que provveis modificaes ou ataques atravs do uso destasmensagens no passem despercebidas. Aqui esto relacionados os ataques que o

SSL no oferece adequada proteo:

1. Confidencialidade: em um estabelecimento de conexo entre dois hosts, um

atacante pode adquirir informaes teis apenas pelo fato de escutar o meio

(sniffer), sem precisar, realmente, analisar qualquer massa de dados. O SSL, por

trafegar pacotes cujos cabealhos no so cifrados, pode permitir este tipo de

ataque.

2. Disponibilidade: um atacante pode evitar que um servio seja prestado

consumindo os recursos de um servidor atravs do estabelecimento de falsas

conexes ou com a deteriorao do meio fsico.

O SSL possui algumas limitaes de segurana devido s suas caractersticas e

propsitos fundamentais:

1. A Proteo aos dados locais no fornecida pelo protocolo. O SSL somente

garante a segurana dos dados durante sua transmisso entre dois aplicativos.

2. No-repudiao: o SSL no prov um mecanismo que evite a no repudiao de

uma transao. Por esta razo, sistemas que necessitem da habilidade para auditar

ou provar a execuo de uma transao, devem empregar o uso de assinaturas

digitais nos dados de aplicativo.

17


18/41

Ataques documentados- Main in the middle(MITM)

Mesmo as conexes protegidas pelo protocolo SSL esto sujeitas este ataque.

Veja como seria este ataque passo a passo:

Browser solicita uma conexo SSL no servidor desejado, neste momento o

cracker intercepta esta solicitao e faz a mesma ao servidor web.

Servidor Web envia a chave pblica para o usurio que passa ater o cracker

como intermedirio, onde este ltimo envia uma chave criada por ele para o

cliente ou browser.

Neste momento o usurio deve prestar muita ateno nos alertas de segurana quepodem vir a aparecer, veja exemplo de mensagem Security Warning demonstrada

acima.

Mtodos de preveno:

Corporao adicionar outra camada de criptografia para informaes sensveis;

SSL duplamente autenticado (Ou seja, o servidor solicitando a autenticao do

usurio que est na outra ponta pedido para o mesmo um certificado digital).

18


19/41

Usurio Nunca aceitar conexes com problemas de certificao;Atualizar o seunavegador web com todas as atualizaes que forem disponibilizadas pelo seu

respectivo fornecedor, principalmente os que forem referentes segurana e

verificao da cadeia de certificao.

ARQUITETURA

SSL Interface, HandShake, Alert, CCS (Change Cipher Spec), Write Port, Read Port,

SSL Manager e Record so as oito entidades que compes a proposta de

arquitetura do SSL. Duas outras entidades externas interagem com o sistema: o

aplicativo e o protocolo TCP/IP. A arquitetura SSL representada pela figura 5 e

suas mensagem.

19

APLICATIVOS

SSLINTERFACE

WRITEPORT REDPORT

HANDSHAKE CCS ALERT

SSLMANEGER


20/41

Figura 5 Arquitetura SSL

1. comunicao do aplicativo com a biblioteca a partir de mtodos de interface

implementados nas classes finais de interface de cliente e servidor.2. pedidos de escrita de dados na rede feitos a interface que so repassados a

Write Port.

3. pedidos de leitura de dados da rede feitos a interface que so repassados a

Read Port.

4. sinaliza SSL Manager que o processo de Handshake deve ser iniciado.

5. enviada de SSL Manager para Write Port a fim de bloquear esta ltima

quando do incio do processo de Handshake e a fim de desbloque-la aotrmino deste.

6. mensagens de SSL Manager a Handshake para escrita e leitura de

mensagens de Handshake.

7. mensagens de SSL Manager a Change Cipher Spec para escrita e leitura de

mensagens de CCS.

8. mensagens de SSL Manager a Alert para escrita e leitura de mensagens de

alerta.9. enviada de SSL Manager para Read Port a fim de desbloquear esta ltima

quando do recebimento de dados de aplicativo pela rede (via Record).

10. pedidos de escrita de dados na rede feitos a Write Port que so repassados a

Record (caso Write Port no esteja bloqueada).

11. pedidos de escrita de mensagens na rede feitos a SSL Manager que so

repassados a Record.

12. pedidos de tratamento de mensagens lidas da rede feitos a SSL Manager.

13. pedidos de escrita na rede feitos a Record e que so repassados a TCP/IP.

Alm disso, esta mensagem enviada quando da leitura de dados da rede. A

20

CCSCCS

TCP/IP


21/41

threadde leitura (threadTCP) l a porta de conexo TCP/IP constantemente

(sendo bloqueada at que chegue alguma stream TCP), executa a

decifragem, descompresso e desfragmentao, e joga o resultado da leitura

numa porta de camada superior.

Seguindo a viso do modelo de camadas, o aplicativo trabalha em cima do SSL,

utilizando dos seus servios de segurana: cifragem e autenticao. O aplicativo

enxerga o SSL como uma caixa preta: todos os detalhes da arquitetura so

abstrados quando a biblioteca utilizada.

SSL INTERFACE

Esta entidade responsvel por prover a interface para o aplicativo. Toda a

comunicao entre aplicativo e a biblioteca feita atravs da entidade SSL Interface

(mensagem 1). Abertura de conexo e mudana de cifra tambm so providas nesta

entidade. Em ambos os casos, o processo de handshake do SSL deve ser

executado (logo aps a abertura de uma conexo TCP, no primeiro caso). Para isso,

uma solicitao deve ser enviada entidade SSL Manager (mensagem 4).

Toda vez que o aplicativo (cliente ou servidor) desejar criar um socket SSL, deve

instanciar um objeto que apresente a funcionalidade desta entidade. Este objeto

SSL Socket, uma subclasse de Socket (com caractersticas de um socketseguro, no

entanto), prover mecanismos (chamadas a mtodos) para a escrita e a leitura em

SSL Interface. Estas chamadas so blocantes. O bloqueio de escrita garantido

pelas chamadas de escrita em Write Port e o de leitura garantido por chamadas de

leitura em Read Port (mensagem 3).

ReadPort

Esta entidade responsvel por bufferizar os dados de aplicativo que chegam pela

rede (mensagens de aplicativo que so tratadas pela entidade Record) e que lhe so

repassadas atravs da entidade SSL Manager. Toda vez que o aplicativo pede por

um dado atravs de SSL Interface, ela faz uma chamada a ReadPort.read() que

deve se bloquear at que haja algum dado no buffer. Quando SSL Manager

escreve no buffer, atravs de ReadPort.add(), ReadPort se desbloqueia liberando a

21


22/41

leitura. Todo este processo garante uma leitura blocante de socket feita no aplicativo

tal como provido pelo socket TCP.

WritePort

Esta entidade ser utilizada como intermediria no processo de escrita de SSL

Interface para Record. Basicamente, sua funo controlar a escrita por SSL

Interface. Toda vez que o processo de handshake for iniciado, a entidade Write Port

dever bloquear qualquer tentativa de escrita feita por SSL Interface. Ao se iniciar

um processo de handshake, SSL Manager sinalizar Write Port (mensagem 5) que

tentativas de escrita feitas por SSL Interface devem ser bloqueadas (chamada de

wait()). Quando permitido, WritePort usa o servio de escrita provido por Recordpara enviar seus dados (mensagem 10).

Record

Esta entidade responsvel em fazer a comunicao com a camada de transporte

TCP e prover os servios de escrita e leitura para SSL Manager e Write Port. Record

controla outra entidade, a ReadTCP, responsvel por ficar escutando a rede para a

chegada de novas mensagens. Ao receber uma mensagem, ReadTCP a envia(mensagem 12) para SSL Manager, que se responsabilizar por repassar a

mensagem para a entidade que deve trat-la. O processamento de leitura na rede

em paralelo a outras aes sendo executadas por outras entidades do protocolo.

Todas as mensagens a serem enviadas atravs da rede sero encaminhadas para

esta entidade que far a fragmentao, compresso (opcional), e cifragem (de

acordo com as cifras definidas pelo handshake) das mesmas antes do envio

(valendo o tratamento oposto quando do recebimento das streams pela outra pontada rede). O servio de escrita no socket provido por Record (mensagem 13)

blocante, ou seja, uma chamada ao mtodo de Record responsvel por escrever no

sockets retornar o controle para a entidade solicitante do servio quando todos os

dados tiverem sido escritos no socket.

SSL Manager

Responsvel pelo gerenciamento do processo de handshake (junto s entidades

Handshake, Alert e Change Cipher Spec) e pelo controle do fluxo das mensagens

entre o aplicativo e Record. Para uma mensagem ser corretamente processada, SSL

22


23/41

Manager analisa seu content-type e a entrega para a respectiva entidade (atravs

de chamada de funo), esperando a resposta a ser devolvida e um valor de retorno

indicando se mais alguma entidade (incluindo a que foi invocada) ainda possui

mensagens a serem enviadas como resposta. Durante o processo de handshake,

SSLManager deve garantir que o aplicativo permanea bloqueado caso invoque (em

Write Port) uma chamada para escrita e que qualquer mensagem de aplicativo

recebida durante este processo gere um fatal_handshake_failure. Quando as

mensagens de aplicativo chegar e o handshake no estiverem ativos, estas sero

enviadas para ReadPort.

RELAO CLIENTE/SERVIDOR

Quando o browser ("cliente") conecta-se a uma pgina protegida por SSL, o servidor

do SSL envia uma solicitao para iniciar a sesso segura. Se o browser suporta

SSL, ele retorna uma resposta. Durante este "apertar de mos" (Handshake) inicial,

o servidor e o browser trocam informaes seguras. A resposta do browser define o

ID da sesso, os algoritmos de criptografia e os mtodos de compactao que

suporta. Nas informaes de segurana fornecidas pelo browser, o servidor faz sua

seleo e a comunica ao browser. O servidor e o browser, em seguida, trocam

certificados digitais utilizando a infra-estrutura de chaves publicas (PKI) e autoridade

certificadora (CA) detalhados a seguir. O servidor tambm especifica uma chave

pblica ("chave de sesso") apropriada para o algoritmo de criptografia

anteriormente selecionado. O browser pode, ento, usar a chave pblica para

criptografar informaes enviadas ao servidor, e o servidor pode usar sua chave

privada para descriptografar essas mensagens. Depois que o servidor e o browser

esto de acordo sobre a organizao da segurana, as informaes podem ser

transmitidas entre os dois, em um modo seguro.

Uma conexo SSL requer que todas as informaes enviadas entre o cliente e o

servidor sejam encriptadas pelo software do emissor e descriptografada pelo

software do receptor, portanto exigindo um alto nvel de confidencialidade.

23


24/41

Todo site que quiser usar SSL em conjunto com a infra-estrutura de chaves pblicas

(PKI) precisar de um certificado de autenticao "assinado" por uma entidade

certificadora (Centification Authoraty - CA), como a Verisign

(http://www.verisign.com/), por exemplo. Se no for de desejo ter um certificado

prprio ou ate mesmo uma PKI local prpria, possvel usar o certificado da

RapidSite, isso vai fazer com que as pginas faam referncia a

http://www.rapidsite.net ao invs de fazer referncia ao nome do domnio que est

sendo utilizado.

O termo sockets refere-se ao mtodo utilizado para troca de dados entre programas

cliente e um servidor em uma rede ou entre camadas de programas em um mesmo

computador.Como funciona o servidor compartilhado SSL: existe uma cpia do software SSL

rodando no servidor principal, acrescentado o domnio no arquivo de configurao

como um domnio adicional.

Como funciona o SSL para um servidor dedicado: o software SSL na verdade,

funciona em conjunto com um servidor Web que compartilha seu domnio. Isso

requer que seja gerada uma "chave" para o servidor. Esta uma chave geralmente

de 128 bits, que criptografada e assinada digitalmente pela certificadora.Quando dois hosts iniciam uma sesso utilizando SSL, as mensagens iniciais

utilizam um protocolo de Handshake que estabelece os algoritmos de criptografia e

chaves criptogrficas a serem utilizados.

O SSL mantm estados de segurana de acordo com sesses associadas a um

conjunto de endereos IP e nmeros das portas. Desta forma possvel, por

exemplo, que A e B se comuniquem com C, tendo cada par seus parmetros de

segurana, ou seja, A e C podem utilizar DES, enquanto B e C utilizam RC4.O SSL utiliza como protocolo de transporte o TCP, que providencia uma transmisso

e recepo confivel dos dados. Uma vez que o SSL reside no nvel de socket, ele

independente das aplicaes de mais alto nvel, sendo assim considerado um

protocolo de segurana independente do protocolo aplicacional. Como tal, o SSL

pode providenciar servios seguros para protocolo de alto nvel, como por exemplo,

TELNET, FTP e HTTP.

24


25/41

Descrio das Mensagens trocadas entre cliente/servidor

HELLO_REQUESTEsta mensagem enviada por um servidor a fim de sinalizar ao cliente que, assim

que for possvel, um processo de handshake pode ser iniciado. Uma vez enviada, o

servidor no poder enviar outra mensagem HELLO_REQUEST, at que o processo

de handshake seja executado.

Esta mensagem no possui campo algum.

CLIENT_HELLO

Esta mensagem enviada pelo cliente com o intuito de iniciar um processo dehandshake. Nesta mensagem o cliente informa ao servidor as ciphersuites e

mtodos de compresso suportados por ele e ordenados de acordo com sua

vontade ou preferncia. Atravs desta mensagem, o cliente pode ainda dar incio a

um processo de retomada de sesso enviando, para isso, o ID de uma sesso

cacheada. O formato desta mensagem mostrado pela figura 8.

VERSO NO

ALEATRIO

ID DA

SESSO

LISTA DE

CIFRAS

LISTA DE METODOS DE

COMPRESSO

Figura 8 - Formato da mensagem CLIENTE_HELLO

SERVER_HELLO

Nesta mensagem, o servidor envia a ciphersuite e mtodo de compresso

selecionados de acordo com suas listas de ciphersuites e mtodos de compresso.

A escolha de uma ciphersuite feita da seguinte forma: a primeira ciphersuite do

cliente que coincidir com alguma ciphersuite do servidor o selecionado (first-

choice-first). O mesmo processo feito para o mtodo de compresso. Caso

nenhuma ciphersuite coincida, o servidor enviar um alerta handshake_failure para o

cliente.

25


26/41

Quando o servidor recebe uma CLIENT_HELLO com o randmico diferente de

vazio, caso deseje, pode realizar uma retomada de sesso. Na tentativa de retomar

uma sesso, o servidor checa em seu cache a existncia de alguma sesso

cacheada cujo ID seja igual ao enviado pelo cliente. Caso a encontre e, se assim

desejar, ele enviar como resposta na SERVER_HELLO um ID com o mesmo valor

enviado pelo cliente. Porm, caso no encontre em cache ou no deseje realizar a

retomada de sesso, o servidor envia para o cliente uma SERVER_HELLO com o ID

diferente do enviado pelo cliente. O servidor pode ainda impedir que uma nova

sesso seja cacheada. Para isso, ele envia um ID vazio. O formato desta mensagem

mostrado pela figura 9.

VERSO NO

ALEATRIO

ID DA

SESSO

CIFRA

SELECIONADA

MTODO DE

COMPREENSO

SELECIONADO

Figura 9 - Formato da mensagem SERVER_HELLO

SERVER_CERTIFICATEO servidor usa esta mensagem para se autenticar e, dependendo do tipo de

certificado, enviar para o cliente dados pblicos (e confiveis) para a troca de

chaves. A SERVER_CERTIFICATE uma mensagem formada por uma lista de

certificados X.509.v3 onde o primeiro da lista o certificado do servidor e os demais

so certificados de CAs que assinam os certificados imediatamente anteriores a ele

na lista. Esta mensagem extremamente importante durante o processo dehandshake. Sem ela, o servidor dever enviar, em outra mensagem, dados pblicos

que possibilitem a troca de chaves. Neste caso, como no ser possvel assin-los,

um intruso poder penetrar na comunicao e espelhar a troca de mensagens entre

as partes envolvidas na comunicao (ataque por espelhamento). O formato da

mensagem mostrado na figura 10.

LISTA DE TIPOS DE CERTIFICADOSACEITOS

LISTA DE NOMES DE CAs ACEITOS

26


27/41

Figura 10 - Formato da mensagem SERVER_CERTIFICATE

SERVER_HELLO

Nesta mensagem, o servidor envia a ciphersuite e mtodo de compressoselecionados de acordo com suas listas de cipher suites e mtodos de compresso.

A escolha de uma cipher suite feita da seguinte forma: a primeira cipher suite do

cliente que coincidir com alguma cipher suite do servidor a selecionada (first-

choice-first). O mesmo processo feito para o mtodo de compresso. Caso

nenhuma cipher suite coincida, o servidor enviar um alerta handshake_failure para

o cliente.

Quando o servidor recebe uma CLIENT_HELLO com o randmico diferente devazio, caso deseje, pode realizar uma retomada de sesso. Na tentativa de retomar

uma sesso, o servidor checa em seu cache a existncia de alguma sesso

cacheada cujo ID seja igual ao enviado pelo cliente. Caso a encontre e, se assim

desejar, ele enviar como resposta na SERVER_HELLO um ID com o mesmo valor

enviado pelo cliente. Porm, caso no encontre em cache ou no deseje realizar a

retomada de sesso, o servidor envia para o cliente uma SERVER_HELLO com o ID

diferente do enviado pelo cliente. O servidor pode ainda impedir que uma novasesso seja cacheada. Para isso, ele envia um ID vazio. O formato desta mensagem

mostrado pela figura 11.

VERSO NO

ALEATRIO

ID DA

SESSO

CIFRA

SELECIONADA

MTODO DE

COMPREENSO

SELECIONADO

Figura 11 - Formato da mensagem SERVER_HELLO

SERVER_KEY_EXCHANGE

Esta mensagem carrega os dados pblicos do servidor os quais sero usados no

processo de troca de chaves. Ela enviada pelo servidor quando ele no possui um

certificado, possui um certificado somente para assinatura, ou possui um certificadocujo os dados pblicos usados para a troca de chave possuem um tamanho superior

27


28/41

ao estipulado pela cipher suite negociada. Esta mensagem no deve ser enviada

caso o certificado do servidor contenha parmetros pblicos Diffie-Hellman.

Existem dois tipos de certificados somente para assinatura: certificados DSS ecertificados RSA cujo campo KEYUSAGE possui a flag SignOnlysetada.

O contedo desta mensagem depender dos algoritmos de troca de chaves e

assinatura especificados na cipher suite selecionada. No caso de uma cipher suite

no annima, ou seja, uma cipher suite que possui um algoritmo para assinatura, os

valores pblicos enviados nesta mensagem so assinados.

De acordo com os algoritmos de troca de chaves e assinatura negociados, a

SERVER_KEY_EXCHANGE pode ter os seguintes formatos:

O PROTOCOLO OPENSSL

O projeto OpenSSL disponibiliza um tollkit em cdigo livre, que implementa o

protocolo SSL e vrios algoritmos e primitivas criptogrficas de uso comum,

incluindo algoritmos de troca de chaves, funes de hash, algoritmos simtricos e

assimtricos. O toolkit se apresenta na forma de duas bibliotecas e um conjunto de

programas que implementam as rotinas por elas disponibilizadas. Os mecanismos

do SSL esto implementados na libssl, e os outros algoritmos esto implementados

na libcrypto.

O OpenSSL uma implementao open source amplamente utilizada do protocolo

SSL verso 3 e TLS Verso 1, bem como uma biblioteca criptogrfica completa de

propsito geral. Os protocolos SSL e TLS so utilizados para prover uma conexosegura entre um cliente e um servidor para protocolos de alto nvel como o http.

Porm no OpenSSL existem vulnerabilidades que podem ser exploradas

remotamente. Os servidores esto sujeitos ao buffer overflow, durante o processo de

Handshake, que podem ser explorados por um cliente que utilize uma chave mal

formada durante o processo de Handshake em uma conexo com um servidor SSL;

somente as sesses que suportam o SSL V2 so afetadas por este problema.

H outras vulnerabilidades tambm para o SSL V3, onde um servidor malicioso

28


29/41

pode explorar isto enviando um session ID grande para o cliente durante o processo

de Handshake. Embora existam estas vulnerabilidades que afetam o OpenSSL,

outras implementaes do protocolo SSL que usam ou compartilham uma mesma

base de cdigo podem ser afetadas. Isto inclui implementaes que so derivadas

da biblioteca SSLeay.

O PROTOCOLO TLS

O TLS verso 1.0 e o SSL 3.0 so muito similares, portanto ambos interagem sem

nenhuma dificuldade. O cliente TLS que deseja negociar com o servidor SSL 3.0

deve enviar ao cliente uma mensagem de hello usando o formato do SSL 3.0

Record e uma estrutura de cliente-hello enviando {3,1} no campo de verso para

dizer que ele ir responder com uma mensagem hello SSL 3.0.

Uma diferena particular entre eles, a gerao de chaves, o que permite o TLS

ser usado para comunicaes seguras conforme as normas impostas pelo padro

FIPS 140 1. O TLS utiliza uma combinao de algoritmos MD5 e SHA1 para gerar

chaves simtricas, ao contrrio do SSL que s utiliza o MD5 para gerar chaves, o

que no aprovado pelo padro FIPS 140 1 (Federal Information Process

Standard).

O protocolo TLS pode ser aplicado com o protocolo HTTP para produzir o

protocolo hbrido HTTPs normalmente na porta 443. Se ele suportar o TLS, uma

mensagem Hello-TLS ira proceder. Similarmente um servidor TLS que deseja

comunicar-se com um cliente SSL 3.0 deve aceitar a mensagem Hello do cliente e

responder com uma mensagem Hello. Se um cliente SSL 3.0 envia uma mensagem

que contm no campo de verso o dado {3.0}, significa que o cliente no suporta o

TLS.

HTTPs vs. sHTTP

Existem duas grandes abordagens para a soluo do problema de segurana no

nvel dos protocolos da camada de aplicao na arquitetura Internet: o HTTPs e o

sHTTP.

29


30/41

HTTPs a utilizao do protocolo HTTP (HyperText Transfer Protocol) em

conjunto com o protocolo SSL (Secure Socket Layer), que um protocolo proposto

por um grupo liderado pela Netscape Communications, pela Verisign e pela Sun

desenvolvido e especificado para prover uma camada de segurana entre a camada

de transporte (TCP) e os protocolos de aplicao tais como HTTP, TELNET, FTP,

NNTP, SMTP, etc. Este protocolo prov encriptao de dados, autenticao de

servidor, integridade de mensagem e, opcionalmente, autenticao de cliente para

uma conexo TCP/IP.

O sHTTP (secure HTTP) uma extenso do protocolo http proposta pelo EIT no

comeo de 1994 que prov transaes seguras pela incorporao de criptografia,

mecanismos de autenticao no protocolo HTTP permitindo transaes seguras fim-a-fim entre cliente e servidor WWW.

SSL e sHTTP tem diferentes motivaes: as camadas de segurana SSL ficam sob

os protocolos de aplicao, como HTTP, NNTP e TELNET, enquanto que HTTPs

adiciona segurana baseada nas mensagens especificamente do protocolo HTTP no

nvel da aplicao. Estas duas aplicaes, longe de serem mutuamente exclusivas

podem coexistir perfeitamente de forma complementar com o protocolo HTTPs

atuando sobre a camada SSL.

TROCA DE CHAVE E ASSINATURA USANDO RSA

Valores pblicos RSA;

Assinatura dos valores pblicos. A assinatura feita da seguinte forma:

1. Calcula-se o hash MD5 a partir dos valores pblicos RSA mais os randmicos

enviados nas mensagens CLIENT_HELLO e SERVER_HELLO;

2. Calcula-se o hash SHA dos mesmos dados que alimentam o hash MD5, os

resultados dos dois hashs so assinados usando a chave-privada RSA do

servidor.

Troca de chaves Diffie-Hellman e assinatura usando RSA

Valores pblicos Diffie-Hellman;

30


31/41

Assinatura dos valores pblicos. A assinatura feita da mesma forma descrita

acima, salvo o fato de os valores pblicos serem Diffie-Hellman.

Troca de chaves Diffie-Hellman e assinatura usando DSA


Assinatura dos valores pblicos. A assinatura feita da seguinte forma:

calcula-se o hash SHA a partir dos valores pblicos Diffie-Hellman mais os

randmicos contidos nas mensagens CLIENT_HELLO e SERVER_HELLO;

os resultado do hash assinado usando a chave privada DSA do servidor.

Troca de chaves Diffie-Hellman annimo


NO feita a assinatura dos valores pblicos. Neste caso, o protocolo fica

suscetvel ao ataque de espelhamento, pois um intruso pode se infiltrar na

comunicao e alterar esta mensagem sem que nenhuma das outras partes

envolvidas tenham conhecimento.

Os parmetros Diffie-Hellman enviados nesta mensagem so tambm denominados

parmetros Diffie-Hellman Efmeros pelo fato de serem gerados no momento do

envio da mensagem (no necessariamente toda vez que uma

SERVER_KEY_EXCHANGE enviada). O uso deste tipo de parmetro acrescenta

uma segurana a mais ao protocolo: se uma chave for descoberta ou espelhada,

somente uma sesso ter sido atacada. Alm disso, um outro aspecto importante a

ser ressaltado, o fato de que o tempo de uso dos valores pblicos extremamente

reduzido, dificultando a quebra do valor privado atravs do ataque por cifra.

CERTIFICATE_REQUESTO servidor envia esta mensagem quando deseja que o cliente se autentique. Ela

composta de uma lista de tipos de certificado que o servidor suporta (que esteja de

acordo com a ciphersuite selecionada) e uma lista de nomes de CAs cujos

certificados self-signed o servidor tenha acesso, conforme representado na figura12.

31


32/41

Um servidor annimo no pode solicitar que um cliente se autentique. Caso um

cliente receba uma CERTIFICATE_REQUEST de um servidor annimo, ele deve

responder com um alerta handshake_failure. Segue abaixo o formato desta

mensagem:

LISTA DE TIPOS DE CERTIFICADOS

ACEITOS

LISTA DE NOMES DE CAs ACEITOS

Figura 12 - Formato da mensagem SERVER_CERTIFICATE

SERVER_HELLO_DONEEsta mensagem possui nenhum campo. O servidor a envia para sinalizar ao cliente

o fim da fase de Hello. O cliente, ao receber esta mensagem, d incio verificao

dos dados enviados pelo servidor durante a fase de Hello. O cliente verifica se o

servidor proveu um certificado aceitvel (se enviado) e se os demais parmetros de

Hello so aceitveis.

CLIENT_CERTIFICATE

Esta mensagem enviada pelo cliente, em resposta a CERTIFICATE_REQUEST,

com a funo de autentic-lo. O contudo desta mensagem uma lista de

certificados X.509v3 tal qual a enviada na mensagem SERVER_CERTIFICATE. O

tipo dos certificados enviados pelo cliente depender das opes impostas pelamensagem CERTIFICATE_REQUEST (tipo de certificado e nome de CA). Caso o

cliente no possua um certificado ou possua um que no atenda s opes, deve

enviar um alerta no_certificate. Certificados Diffie-Hellman enviados pelo cliente

devero possuir os mesmos parmetros Diffie-Hellman contidos no certificado do

servidor.

32


33/41

CLIENT_KEY_EXCHANGEO cliente envia esta mensagem para o servidor a fim de fornecer o dado necessrio

criao de um segredo compartilhado. Esta informao recebe o nome de Pr

Mster Secrete seu valor dependente do algoritmo de troca de chave especificado

na cipher suite escolhida. Segue agora uma explicao de como a Pr Mster

Secret gerada.

Troca de chaves usando RSA

Quando o RSA utilizado para a troca de chaves, a Pr Mster Secret um nmero

de 48 bytes gerados pelo cliente, formado pela verso do protocolo (2 bytes) e por

46 bytes randmicos. Estes 48 bytes so ento cifrados usando a chave pblica doservidor (envelope digital) e enviados de forma a garantir que somente os dois

tenham conhecimento do seu valor na figura 13:

MD5 (MENSAGENS ANTERIORES +

MASTER SECRET)

SH5 (MENSAGENS ANTERIORES +

MASTER SECRET)

Figura 13 Troca de chaves usando RSA

Derivao de chaves usando Diffie-HellmanNo processo de troca de chaves usando o Diffie-Hellman, o cliente envia para o

servidor o seu valor pblico e ambos executam o processo de derivao de chave. O

valor resultante deste processo a Pr Mster Secret. O cliente s envia seu valor

pblico nesta mensagem caso o certificado enviado por ele no o contenha.

Imediatamente aps o cliente enviar esta mensagem e o servidor receb-la, dar-se-

incio ao processo de gerao da Mster Secret. A Mster Secret um segredo

compartilhado pelas partes envolvidas no handshake e que, posteriormente, usadopara a gerao das chaves de sesso e segredos utilizados no clculo dos MACs.

Logo que a Mster Secret calculada, a Pr Mster Secretdeve ser destruda da

memria e o processo de gerao do KeyBlockdeve ser executado. O KeyBlock

um vetor de bytes resultante de uma seqncia de hashes seguros envolvendo a

Mster Secret. a partir do KeyBlock produzido que o SSL retira os dados que

devero ser usados como chaves de sesso, vetores de inicializao e segredos

para os MACs.

33


34/41

A quantidade de hashes que devero ser calculados, depender da quantidade de

material randmico necessrio para preencher todos os segredos utilizados pela

camada Record.

Em caso de cipher suites geradas em implementaes licenciadas para exportao,

os quatros ltimos valores so recalculados.

O segredo que utilizado por uma das partes na escrita utilizado pela outra na

leitura. Por exemplo o valor da client_write_key usado para cifrar dados no lado

cliente e para decifrar no lado servidor.

CERTIFICATE_VERIFY

Esta mensagem prov uma forma explicita de o servidor verificar o certificado

enviado pelo cliente. Seu contedo a assinatura digital de dois hashes cuja

entrada so todas as mensagens de handshake enviadas at o momento,

desconsiderando-se esta. O servidor, ao receb-la, executa a verificao da

assinatura, tal qual abordado na sesso de Assinaturas Digitais deste documento.

Em caso de erro na verificao da assinatura, o servidor envia um alerta de

handshake_failure.

Clientes que possuem certificados Diffie-Hellman no podem enviar esta mensagem,

pelo motivo bvio de o Diffie-Hellman no poder ser utilizado para assinaturas

digitais.

FINISHED

Esta a primeira mensagem no processo de handshake a ser enviada decifrada. Ela

enviada imediatamente aps a mensagem de CHANGE_CIPHER_SPEC, tanto

pelo cliente quanto pelo servidor, com a funo de validar os processos de troca dechaves e autenticao. Seu contedo so dois hashes (com segredo -

MasterSecret), de todas as mensagens de handshake enviadas at o momento,

excluindo-se esta na figura 14.

MD5 (MENSAGENS ANTERIORES +

MASTER SECRET)

SH5 (MENSAGENS ANTERIORES +

MASTER SECRET)

Figura 14 Troca de chaves usando RSA

34


35/41

A fim de prover uma forma de diferenciar uma mensagem FINISHED enviada pelo

cliente de outra enviada pelo servidor, ambos inserem um conjunto de bytes

denominado Sender, o qual assume valores diferentes para cliente e servidor, junto

dos dados de entrada do hash.

Caso uma mensagem FINISHED seja recebida antes de uma

CHANGE_CIPHER_SPEC, o receptor da mensagem deve enviar um alerta de

handshake_failure. Aps esta mensagem, a troca de mensagens de aplicao

atravs do canal de cifra negociada pelo SSL liberada.

INFRA ESTRUTURA DE CHAVE PBLICA (PUBLIC KEY

INFRASTRUCTURE- PKI)

A utilizao da PKI ocorreu devido ao fato de que era necessria uma estrutura

organizada que criasse regras e fortalecesse ainda mais os protocolos SSL e IPSec

utilizados para prover segurana, sendo que fica a critrio do implementador e

conforme as necessidades de negcios de cada empresa.

Uma PKI fornece e define regras tcnicas para instituies pblicas e privadas com

relao s transaes de troca de documentos transmitidos e obtidas

eletronicamente. Um dos mecanismos de validao do PKI se chama Certificado,

que uma espcie de selo eletrnico fornecido por Autoridades Certificadoras CA.

Com a utilizao do protocolo SSL e o PKI a empresa garante ao cliente final que o

site que ele esta acessando realmente o que ele quer acessar. Esse processo

garantido atravs de certificado que garante alem de autenticidade uma validao

jurdica que para os negcios on-line efetuado pela empresa.

AUTORIDADE CERTIFICADORA (CERTIFICATION

AUTHORITY)

A Autoridade Certificadora uma instituio publica ou privada com estrutura

hierrquica responsvel pela emisso de certificados digitais visando identificar

pessoas, usurios, sistemas, redes, equipamentos etc., para proporcionar umrelacionamento de confiana entre sesses de comunicao na rede. O papel

35


36/41

principal da CA determinar polticas e procedimentos que orientam o uso dos

certificados por todo o sistema. A Autoridade Certificadora tem varias outras

atribuies conforme lista resumida descrita abaixo.

Quando uma empresa que pratica negcios on-line e utiliza o protocolo SSL para

prover segurana quiser implementar o PKI ou fazer parte dela, dever procurar

pelas diversas CA cadastradas pela ICP-Brasil (PKI raiz do Brasil) para fazer a

requisio do certificado digital e tornar parte na infra-estrutura de PKI.

CERTIFICADO DIGITAL

Nos casos de transaes eletrnicas, tipo compras on-line, envio de documentos

eletrnicos, e-mail etc., o certificado digital fornecido assinado pela Autoridade

Certificadora (CA) que faz parte da Infra-estrutura de chaves publicas (PKI) e segue

um padro de certificado X.509, RFC 2459 junto com Normas da RSA PKCS etc.

Quando recebemos um certificado digital em uma transao, o browser se

encarrega de fazer a checagem na CA para saber se pode confiar ou no. Se tudo

correr bem o usurio nem vai notar que recebeu um certificado e que o mesmo foi

checado na CA para obter a certeza de autenticidade. No entanto, caso o browser

no conseguir autenticar o certificado digital recebido, uma outra mensagem

(Security Warning ver exemplo abaixo) ira surgir no monitor do usurio com a

opo de aceitar ou no o certificado digital recebido.

36


37/41

Para obter informaes com relao aos CA e certificados cadastrados no seu

browser s abrir o Browser (Iexplore), menu Ferramentas, menu Opes Internet,

menu Contedo, boto Certificado.

37


38/41

Exemplos de locais que utilizam um certificado digital:

Aplicaes bancrias

Acesso remoto de funcionrios de uma organizao

Vendas on-line Acesso remoto via VPN/IPsec: Exemplo: desenvolvimento de software,

vendedores, etc. Uma conexo VPN baseada em IPSec tambm pode utilizar

certificado digital para estabelecer a conexo segura entre dois usurios

finais.

PREOCUPAES CAUSADAS PELO PROTOCOLO SSL

Grande maioria da empresas est preocupada com o fato de que a utilizao do

protocolo SSL est aumentando muito e uma conexo protegida por SSL no

barrada por nenhum tipo de firewall devido ao fato de que este est criptografado.

E assim funcionrios da empresa podem estar levando contedo pornogrfico para

38


39/41

dentro da empresa, retirando informaes da empresa e tranmitindo-as p-ara o

ambiente externo

CONCLUSES

Segurana da informao assunto muito complexo e difcil de ser tratado. As

conexes entre cliente e servidor se tornam mais seguras quando fazem uso do

protocolo SSL que pode ser implementado em diferentes protocolos da camada de

aplicao como HTTPs, FTP, SHTTP, etc., sendo que sua implementao tambm

muito complexa, alm de possuir tambm algumas desvantagens devido ao fato de

que este trabalha com o mtodo de criptografia e no sofre nenhuma filtrao por

nenhum tipo de firewall, e sem este mtodo, este protocolo j no se torna to

seguro. Os protocolos SSL, OpenSSL, TLS, IPSec etc., so alguns dos protocolos

mais utilizados para proporcionar uma camada extra de segurana nas transaes

on-line para evitar crimes virtuais. Vrias empresas esto fazendo uso dos

Certificados Digitais justamente para uma melhor utilizao destes protocolos. E

mais uma vez foi possvel perceber que a medida que as prevenes com relao

segurana nas conexes aumentam, crimes contra as mesmas crescem quase que

na mesma proporo.

39


40/41

Refrncias Bibliogrficas

HTTP://WWW.STUDENTS.IC.UNICAMP.BR/~RA015051/SSL.HTM

HTTP://ORBITA.STARMEDIA.COM/~ADERBAL_PANELLI/SEGURANCA/SSL.HTM

HTTP://WP.NETSCAPE.COM/ENG/SSL3/DRAFT302.TXT

HTTP://WP.NETSCAPE.COM/ENG/SSL3/SSL-TOC.HTML

HTTP://WWW.CERTISIGN.COM.BR/SUPORT.JSP

HTTP://WWW.CIC.UNB.BR/DOCENTES/PEDRO/TRABS/SSL.PDF

HTTP://WWW.GTA.UFRJ.BR/GRAD/01_2/TLS/

HTTP://WWW.NGUERRA.COM.BR/ECOMMERCE/MENSAGENS/PG/SSL.HTM

HTTP://EQUIPE.NCE.UFRJ.BR/GONZALO/SSL/

HTTP://WWW.VIPCOM.COM.BR/INTERNA.ASP?ITEM=SSL

HTTP://WWW.GEOCITIES.COM/ANDREZAO_LRT/TOPICOS

HTTP://WWW.CIC.UNB.BR/DOCENTES/PEDRO/TRABS/HAMMURABI.HTM

HTTP://WWW.ICPBRASIL.GOV.BR

HTTP://WWW.REDES.UNB.BR/SECURITY/SSL3/PROTOCOLO.HTML

HTTP://WWW.ITI.GOV.BR

HTTP://WWW.OPENSSL.ORG

HTTP://WWW.GTA.UFRJ.BR/SEMINARIOS/SEMIN2000_1/SSL

40
http://www.vipcom.com.br/interna.asp?item=sslhttp://www.geocities.com/andrezao_lrt/topicoshttp://www.cic.unb.br/docentes/pedro/trabs/hammurabi.htmhttp://www.icpbrasil.gov.br/http://www.redes.unb.br/security/ssl3/protocolo.htmlhttp://www.iti.gov.br/http://www.openssl.org/http://www.vipcom.com.br/interna.asp?item=sslhttp://www.geocities.com/andrezao_lrt/topicoshttp://www.cic.unb.br/docentes/pedro/trabs/hammurabi.htmhttp://www.icpbrasil.gov.br/http://www.redes.unb.br/security/ssl3/protocolo.htmlhttp://www.iti.gov.br/http://www.openssl.org/


41/41

41

protocolo ssl de rede

Documents