UNIO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CINCIAS APLICADAS DE MINAS

Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000 CST EM REDES DE COMPUTADORES

PROTOCOLO SSL

SUMRIO

PROTOCOLO SSL.................................................................................................................................................6 CAMADAS................................................................................................................................................................8 PROCESSOS...............................................................................................................................................................9 PROTOCOLO CHANGE CIPHER SPEC.........................................................................................................11 PROTOCOLO ALERT........................................................................................................................................12 PROTOCOLO HANDSHAKE............................................................................................................................13 SEGURANA........................................................................................................................................................15 ALGORITMOS UTILIZADOS........................................................................................................................................15 ATAQUES...............................................................................................................................................................16 ARQUITETURA...................................................................................................................................................19 SSL INTERFACE.................................................................................................................................................21 READPORT.............................................................................................................................................................21 WRITEPORT...........................................................................................................................................................22 RECORD.................................................................................................................................................................22 SSL MANAGER......................................................................................................................................................22 RELAO CLIENTE/SERVIDOR....................................................................................................................23 DESCRIO DAS MENSAGENS TROCADAS ENTRE CLIENTE/SERVIDOR.................................................................................25 O PROTOCOLO OPENSSL................................................................................................................................28 O PROTOCOLO TLS..........................................................................................................................................29 HTTPS VS. SHTTP...............................................................................................................................................29

TROCA DE CHAVE E ASSINATURA USANDO RSA...................................................................................30 TROCA DE CHAVES DIFFIE-HELLMAN E ASSINATURA USANDO RSA................................................................................30 TROCA DE CHAVES DIFFIE-HELLMAN E ASSINATURA USANDO DSA................................................................................31 TROCA DE CHAVES DIFFIE-HELLMAN ANNIMO...........................................................................................................31 TROCA DE CHAVES USANDO RSA.............................................................................................................................33 CERTIFICATE_VERIFY ................................................................................................................................34 FINISHED..........................................................................................................................................................34 INFRA ESTRUTURA DE CHAVE PBLICA (PUBLIC KEY INFRASTRUCTURE- PKI)..................35 CERTIFICADO DIGITAL..................................................................................................................................36 PREOCUPAES CAUSADAS PELO PROTOCOLO SSL..........................................................................38 CONCLUSES.....................................................................................................................................................39

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 dados e 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 ao protocolo 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 dados trocados entre as partes envolvidas na conexo atravs do uso de criptografia

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 uso nas 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

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 usado nos 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.

APLICAO HANDSHAKE RECORD TCP/IP

SSL

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 em registros 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.

HANDSHAKE

CCS

ALERT

HANDSHAKE

FRAGMENTAO COMPRESSO ENCRIPTAO Figura 2 - Protocolos Handshake e processos Record

RECORD

Processos
- Processo de Fragmentao: neste processo, os dados originados das camadas superiores, 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

10

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, encontramse 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

11

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

12

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 mensagens de 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 recebido durante 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;

13

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

S h autenticao ou no das partes envolvidas e/ou se uma sesso retomada. A C L mensagens trocadas esto descritas na figura 1. I E N T E E figura abaixo mostra uma possvel execuo do processo de handshake. As R V I D O R

14

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.

15

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).

16

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.

17

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 destas mensagens 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.

18

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 que podem 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).

19

Usurio Nunca aceitar conexes com problemas de certificao; Atualizar o seu navegador 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.

APLICATIVOS 1

SSLINTERFACE

WRITEPORT

REDPORT

HANDSHAKE 5 6

CCS 7 SSLMANEGER

ALERT 8 9

20

10

11 CCS

12

13 TCP/IP

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 ao trmino 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

21

thread de leitura (thread TCP) 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 socket seguro, 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

22

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 Record para 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 ponta da 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 socket s 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

23

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.

24

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.

25

Descrio das Mensagens trocadas entre cliente/servidor

HELLO_REQUEST
Esta 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 de handshake. 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 LISTA

DE LISTA DE METODOS DE COMPRESSO

SESSO CIFRAS

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 (firstchoice-first). O mesmo processo feito para o mtodo de compresso. Caso nenhuma ciphersuite coincida, o servidor enviar um alerta handshake_failure para o cliente.

26

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 CIFRA

MTODO COMPREENSO SELECIONADO

DE

SESSO SELECIONADA

Figura 9 - Formato da mensagem SERVER_HELLO

SERVER_CERTIFICATE
O 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 de handshake. 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 CERTIFICADOS LISTA DE NOMES DE CAs ACEITOS ACEITOS

27

Figura 10 - Formato da mensagem SERVER_CERTIFICATE

SERVER_HELLO
Nesta mensagem, o servidor envia a ciphersuite e mtodo de compresso selecionados 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 (firstchoice-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 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 11.

VERSO NO ALEATRIO

ID

DA CIFRA

MTODO COMPREENSO SELECIONADO

DE

SESSO SELECIONADA

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 certificado cujo os dados pblicos usados para a troca de chave possuem um tamanho superior

28

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 e certificados RSA cujo campo KEYUSAGE possui a flag SignOnly setada. 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 conexo segura 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

29

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.

30

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 fima-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;

31

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

Valores pblicos Diffie-Hellman; 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

Valores pblicos Diffie-Hellman; 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_REQUEST
O 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 figura 12.

32

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 LISTA DE NOMES DE CAs ACEITOS ACEITOS Figura 12 - Formato da mensagem SERVER_CERTIFICATE

SERVER_HELLO_DONE
Esta 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 pela mensagem 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.

33

CLIENT_KEY_EXCHANGE
O 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 Secret e 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 do servidor (envelope digital) e enviados de forma a garantir que somente os dois tenham conhecimento do seu valor na figura 13: MD5 (MENSAGENS ANTERIORES + SH5 (MENSAGENS ANTERIORES + MASTER SECRET) MASTER SECRET)

Figura 13 Troca de chaves usando RSA

Derivao de chaves usando Diffie-Hellman

No 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, usado para a gerao das chaves de sesso e segredos utilizados no clculo dos MACs. Logo que a Mster Secret calculada, a Pr Mster Secret deve ser destruda da memria e o processo de gerao do KeyBlock deve 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.

34

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 de chaves 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 + SH5 (MENSAGENS ANTERIORES + MASTER SECRET) MASTER SECRET)

Figura 14 Troca de chaves usando RSA

35

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 um relacionamento de confiana entre sesses de comunicao na rede. O papel

36

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.

37

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.

38

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

39

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.

40

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

41