Universidade Estadual de Campinas Instituto de …rdahab/cursos/mp202/Welcome...Universidade Estadual de Campinas Instituto de Computação Mestrado Profissional em Computação 2º

Universidade Estadual de Campinas Instituto de Computação

Mestrado Profissional em Computação 2º. Semestre / 2003

O Protocolo 6ecure 6ockets /ayer (66/)

Segurança da Informação – MP 202

Prof. Ricardo Dahab

BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB�Cláudio Ap. Rocha RA: 022506 Edson Tessarini Pedroso RA: 022510 Eduardo Tarciso Soares Junior RA: 015051

2

Ë1',&(� 2EMHWLYR�� ,QWURGXomR�� 2�3URWRFROR�66/��

Prioridades do Protocolo SSL .................................................................................... 7 Funcionamento ............................................................................................................. 7 Segurança...................................................................................................................... 8 As Vantagens do SSL.................................................................................................. 9

2�SURWRFROR�2SHQ66/�� 2�3URWRFROR�7/6�� +773V�YV��V+773 �� $OJRULWPRV�XWLOL]DGRV�SHOR�66/ �� 3URWRFROR�&KDQJH�&LSKHU6SHF �� 3URWRFROR�$OHUW �� 3URWRFROR�66/�+DQGVKDNH �� Mensagens de Hello .................................................................................................. 18 Hello Request.............................................................................................................. 18 Client Hello .................................................................................................................. 18 Server Hello ................................................................................................................. 18 Server Certificate ........................................................................................................ 19 Server Key Exchange ................................................................................................ 19 Certificate Request ..................................................................................................... 20 Server Hello Done ...................................................................................................... 21 Client Certificate.......................................................................................................... 21 Client Key Exchange.................................................................................................. 21 Certificate Verify.......................................................................................................... 22 Finished........................................................................................................................ 22

3URWRFROR�66/�5HFRUG �� ,QIUD�HVWUXWXUD�GH�&KDYH�3~EOLFD��3XEOLF�.H\�,QIUDVWUXFWXUH��3.,�� $XWRULGDGH�&HUWLILFDGRUD��&HUWLILFDWLRQ�$XWKRULW\�±�&$�� &HUWLILFDGR�'LJLWDO� �� Formato do Certificado Digital. ................................................................................. 26 Imagem de um certificado Digital............................................................................. 27

$SOLFDo}HV�TXH�XWLOL]DP�&HUWLILFDGRV�'LJLWDLV� �� ([HPSORV�GH�HPSUHVDV�TXH�XWLOL]DP�R�SURWRFROR�66/ �� $WDTXHV�GRFXPHQWDGRV�±�0DQ�LQ�WKH�PLGGOH��0,70� �� No caso de Man in the Middle em conexões SSL ................................................ 30 Métodos de Prevenção para o Man-in-the-middle ................................................ 31

Prevenção por parte da corporação .................................................................... 31 Prevenção por parte do Usuário .......................................................................... 31 3UHRFXSDo}HV�FDXVDGDV�SHOR�XVR�GR�SURWRFROR�66/�� )HUUDPHQWDV�GH�DX[LOLR�SDUD�DQiOLVH�H�HQWHQGLPHQWR�GR�SURWRFROR�66/ �� &RQFOXVmR�� %LEOLRJUDILDV�H�UHIHUrQFLDV ��

3

2EMHWLYR� O principal objetivo deste trabalho é introduzir os conceitos e mecanismos de segurança utilizados pelo protocolo SSL, o qual provê uma camada extra de segurança para aplicações como, por exemplo, Web, que efetuam transações on-line. O protocolo SSL também pode ser implementado de diversas maneiras, o nosso trabalho descreve como seria uma implantação SSL com certificado digital do host servidor utilizando a Infra-estrutura de Chaves Públicas (PKI). Outras maneiras de implementar o protocolo SSL também são possíveis; tais como, utilizar SecurityID, certificado digital do cliente (host cliente), SecurityCard, etc..., porém tais implementações são apenas mencionados no nosso trabalho por não fazer parte do espoco principal.

4

,QWURGXomR� O protocolo SSL vem se tornando sinônimo de segurança para aplicações que utilizam a internet para efetuarem negócios 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 transações eletrônicas on-line. Desde sua concepção, o protocolo SSL vem se tornando padrão de fato a cada dia, porém a implementação do protocolo SSL em sua forma pura; ou seja, utilizando somente suas técnicas de criptografias oferecidas por ele já não são suficientes para garantir uma segurança tolerável nos negócios on-line (há um tópico neste trabalho que cobre um estudo de caso de implementação SSL na sua forma pura). Sendo assim, novos mecanismos foram surgindo para adicionar um maior nível de segurança ao protocolo SSL. Todos esses mecanismos implementados em conjunto com o protocolo SSL visam uma maior segurança para as organizações, por outro lado, outras preocupações começam a surgir justamente pela sua utilização, tais preocupações serão esclarecidas resumidamente em um tópico a parte sobre esse assunto.

A criptografia é a arte de empregar certas regras em mensagens ou informações de

forma a esconder seu verdadeiro conteúdo. A mensagem ou informação codificada pelo uso da criptografia, que pode ser transmitida por meios de comunicação considerados inseguros, pois só o receptor, conhecedor das regras poderá reverter o processo e ler o documento original.

Ao contrário do que a maioria das pessoas pensam, a criptografia não é uma invenção recente, e tampouco de uso restrito a computadores poderosos. Apesar de a data da invenção da criptografia não ser exatamente determinada, o seu uso era conhecido há séculos. O primeiro uso da criptografia de que se tem notícia ocorreu por volta de 1900 a.C., quando um egípcio usou hieróglifos para codificar mensagens.

O SSL (6HFXUH� 6RFNHWV� /D\HU) é o protocolo responsável por estabelecer uma conexão segura entre o cliente e o servidor através de criptografia ou assinatura digital. Foi desenvolvido pela Netscape a fim de prover segurança de transmissão de dados entre computadores, o SSL foi proposto ao :RUOG�:LGH�:HE�&RQVRUWLXP (W3C) e ao ,QWHUQHW�(QJLQHHULQJ� 7DVN� )RUFH (IETF) como um padrão de segurança para ZHE� EURZVHUV e servidores ZHE.

Com o SSL, uma conexão é estabelecida onde todos os dados trafegam criptografados pela rede, sem que haja o risco de serem interceptados e decifrados por alguém. Para garantir a integridade dos dados, é necessário um protocolo seguro para orientar a conexão, como por exemplo, o TCP/IP. O uso do SSL se disseminou por meio de sua implementação nos EURZVHUV da Netscape, fornecendo aos usuários uma forma segura de acessar servidores ZHE, permitindo inclusive a execução de transações comerciais. Sua versão mais recente é a 3.0.

Seu funcionamento ocorre por meio do sistema de criptografia de chaves públicas e privadas desenvolvido por Rivest, Shamir e Adleman, o RSA. O SSL é mais usado nos

5

browsers, como Netscape, Internet Explorer entre outros, no caso o protocolo HTTP, que é mais usado por usuários com menos experiência e que necessitam de maior segurança para acessar uma página de banco, por exemplo.

6

2�3URWRFROR�66/�

O SSL pode usar o mecanismo de criptografia de chave pública RSA para implementar transmissão segura. A criptografia de chave pública é uma técnica que usa um par de chaves assimétricas (chave pública e chave privada) para criptografia e descriptografia. A chave pública é amplamente distribuída, mas a chave privada é mantida pelo originador da mensagem, sem qualquer divulgação. Devido às chaves assimétricas, os dados criptografados usando a chave privada só podem ser descriptografados com o uso da chave pública. De forma inversa, os dados criptografados usando a chave pública só podem ser descriptografados com a utilização da chave privada.

Quando o browser ("cliente") conecta-se a uma página protegida por SSL, o servidor do SSL envia uma solicitação para iniciar a sessão segura. Se o browser suporta SSL, ele retorna uma resposta. Durante este "apertar de mãos" (KDQGVKDNH) inicial, o servidor e o browser trocam informações seguras. A resposta do browser define o ID da sessão, os algoritmos de criptografia e os métodos de compactação que suporta. Nas informações de segurança fornecidas pelo browser, o servidor faz sua seleção 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 também especifica uma chave pública ("chave de sessão") apropriada para o algoritmo de criptografia anteriormente selecionado. O browser pode, então, usar a chave pública para criptografar informações enviadas ao servidor, e o servidor pode usar sua chave privada para descriptografar essas mensagens. Depois que o servidor e o browser estão de acordo sobre a organização da segurança, as informações podem ser transmitidas entre os dois, em um modo seguro.

Uma conexão SSL requer que todas as informações enviadas entre o cliente e o servidor sejam encriptadas pelo software do emissor e descriptografada pelo software do receptor, portanto exigindo um alto nível de confidencialidade.

Confidencialidade é importante para ambas às partes para qualquer transação privada. Além do mais, todos os dados enviados sobre uma conexão encriptada SSL é protegida por um mecanismo para detectar automaticamente e verificar se os dados foram alterados em trânsito.

Todo site que quiser usar SSL em conjunto com a infra-estrutura de chaves publicas (PKI) precisará de um certificado de autenticação "assinado" por uma entidade certificadora (Centification Authoraty - CA), como a Verisign (http://www.verisign.com/), por exemplo. Se não for de desejo ter um certificado próprio ou ate mesmo uma PKI local própria, é possível usar o certificado da RapidSite, isso vai fazer com que as páginas façam referência a http://www.rapidsite.net ao invés de fazer referência ao nome do domínio que está sendo utilizado.

7

3ULRULGDGHV�GR�3URWRFROR�66/�

• 6HJXUDQoD� FULSWRJUiILFD� �� SSL deve ser usado para estabelecer uma conexão segura em duas partes.

• ,QWHURSHUDELOLGDGH� �� Programadores independentes podem desenvolver aplicações utilizando SSL que então será capaz de trocar parâmetros criptográficos sem o conhecimento de um outro código.

• (VFDODELOLGDGH – SSL provê que novos métodos de encriptação possam ser adicionados se necessários. Isso se faz, para evitar a criação de um novo protocolo e o risco de ter que implementar uma nova biblioteca segura e com isso anular o risco de uma falha.

• (ILFLrQFLD��Operações criptográficas tendem a usar intensivamente a CPU e particularmente operadores de chave pública. Por essa razão, o SSL tem incorporado um esquema de cachê de sessão para reduzir o número de conexões que necessitam serem estabilizadas desde o começo. Além do mais, um cuidado muito especial tem sido tomado para reduzir a atividade da rede.

)XQFLRQDPHQWR�

É implementado de modo a atuar como uma subcamada da camada de Aplicação da arquitetura TCP/IP, posicionada entre esta e a camada de Transporte (vide figura 1). Dados específicos enviados por aplicativos que utilizam SSL são protegidos por técnicas de criptografia e autenticação, garantindo a integridade e a privacidade dos mesmos. A estrutura do quadro transmitido pode ser observada na figura 2.

)LJXUD��±�&DPDGD�66/�

8

)LJXUD��)RUPDWR�GH�XP�TXDGUR�FRP�66/�

Uma vez que este protocolo garante a integridade dos dados enviados, é necessário que seja utilizado um protocolo de transporte confiável orientado a conexão, como o TCP, a fim de garantir que não haja erros de transmissão.

O SSL fornece um serviço de comunicação segura entre cliente e servidor, permitindo autenticação mútua e garantindo integridade dos dados pelo uso de assinaturas digitais, e privacidade pelo uso de criptografia. O protocolo foi projetado de modo a suportar diversos algoritmos de criptografia e assinatura digital, permitindo a seleção dos algoritmos mais convenientes para cada situação, assim como a utilização de novos algoritmos, a medida em que estes vão evoluindo. Estas escolhas são negociadas entre o cliente e o servidor durante o estabelecimento de uma sessão.

O termo VRFNHWV refere-se ao método utilizado para troca de dados entre programas cliente e um servidor em uma rede ou entre camadas de programas em um mesmo computador.

&RPR�IXQFLRQD�R�VHUYLGRU�FRPSDUWLOKDGR�66/��existe uma cópia do software SSL rodando no servidor principal, é acrescentado o domínio no arquivo de configuração como um domínio adicional.

&RPR� IXQFLRQD� R� 66/� SDUD� XP� VHUYLGRU� GHGLFDGR� o software SSL na verdade, funciona em conjunto com um servidor Web que compartilha seu domínio. Isso requer que seja gerada uma "chave" para o servidor. Esta é uma chave geralmente de 128 bits, que é criptografada e assinada digitalmente pela certificadora.

6HJXUDQoD�

Existem três 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.

9

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

O SSL é composto por quatro mecanismos de segurança:

• Autenticação - Identifica a fonte dos dados;

• Integridade - Garante que dados não foram indevidamente alterados;

• Criptografia - Garante a privacidade dos dados;

• Troca de chaves criptográficas - Aumenta a segurança do mecanismo de criptografia utilizado.

Dados protegidos por SSL são sempre transmitidos em um formato que incorpora

um FKHFNVXP criptográfico, e um identificador de segurança. Quando dois KRVWV iniciam uma sessão utilizando SSL, as mensagens iniciais utilizam um protocolo de KDQGVKDNH que estabelece os algoritmos de criptografia e chaves criptográficas a serem utilizados.

O SSL mantém estados de segurança de acordo com sessões associadas a um

conjunto de endereços IP e números das portas. Desta forma é possível, por exemplo, que A e B se comuniquem com C, tendo cada par seus parâmetros de segurança, 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 transmissão e recepção confiável dos dados. Uma vez que o SSL reside no nível de socket, ele é independente das aplicações de mais alto nível, sendo assim considerado um protocolo de segurança independente do protocolo aplicacional. Como tal, o SSL pode providenciar serviços seguros para protocolo de alto nível, como por exemplo, TELNET, FTP e HTTP.

$V�9DQWDJHQV�GR�66/�

O SSL preenche todos os critérios que o fazem aceitável para o uso nas transmissões das mais sensíveis informações, como dados pessoais e números do cartão de crédito. A aplicação pode optar entre utilizar todos ou somente uma parte desses critérios dependendo do tipo e natureza das transações que estão sendo efetuadas. 2�SURWRFROR�2SHQ66/�

O projeto OpenSSL disponibiliza um WRRONLW em código livre, que implementa o protocolo SSL e vários algoritmos e primitivas criptográficas de uso comum, incluindo algoritmos de troca de chaves, funções de hash, algoritmos simétricos e assimétricos. O toolkit se apresenta na forma de duas bibliotecas e um conjunto de programas que

10

implementam as rotinas por elas disponibilizadas. Os mecanismos do SSL estão implementados na libssl, e os outros algoritmos estão implementados na libcrypto.

O OpenSSL é uma implementação “RSHQ� VRXUFH” amplamente utilizada do

protocolo SSL versão 3 e TLS Versão 1, bem como uma biblioteca criptográfica completa de propósito geral. Os protocolos SSL e TLS são utilizados para prover uma conexão segura entre um cliente e um servidor para protocolos de alto nível como o http.

Porém no OpenSSL existem vulnerabilidades que podem ser exploradas remotamente. Os servidores estão sujeitos ao buffer RYHUIORZ, durante o processo de KDQGVKDNH, que podem ser explorados por um cliente que utilize uma chave mal formada durante o processo de KDQGVKDNH em uma conexão com um servidor SSL; somente as sessões que suportam o SSL V2 são afetadas por este problema.

Há outras vulnerabilidades também para o SSL V3, onde um servidor malicioso pode explorar isto enviando um VHVVLRQ ID grande para o cliente durante o processo de KDQGVKDNH. Embora existam estas vulnerabilidades que afetam o OpenSSL, outras implementações do protocolo SSL que usam ou compartilham uma mesma base de código podem ser afetadas. Isto inclui implementações que são derivadas da biblioteca SSLeay. 2�3URWRFROR�7/6�

O TLS versão 1.0 e o SSL 3.0 são 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 “KHOOR” usando o formato do “SSL 3.0 Record” e uma estrutura de cliente-hello enviando {3,1} no campo de versão para dizer que ele ira responder com uma mensagem hello SSL 3.0.

Uma diferença particular entre eles, é a geração de chaves, o que permite o TLS ser usado para comunicações seguras conforme as normas impostas pelo padrão FIPS 140 – 1. O TLS utiliza uma combinação de algoritmos MD5 e SHA1 para gerar chaves simétricas, ao contrário do SSL que só utiliza o MD5 para gerar chaves, o que não é aprovado pelo padrão FIPS 140 –1 ()HGHUDO�,QIRUPDWLRQ�3URFHVV�6WDQGDUG).

O protocolo TLS pode ser aplicado com o protocolo HTTP para produzir o protocolo híbrido 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 contêm no campo de versão o dado {3.0}, significa que o cliente não suporta o TLS.

11

+773V�YV��V+773�

Existem duas grandes abordagens para a solução do problema de segurança no nível dos protocolos da camada de aplicação na arquitetura Internet: o HTTPs e o sHTTP.

HTTPs é a utilização do protocolo HTTP (+\SHU7H[W� 7UDQVIHU� 3URWRFRO) em conjunto com o protocolo SSL (6HFXUH�6RFNHWV�/D\HU), que é um protocolo proposto por um grupo liderado pela Netscape Communications, pela Verisign e pela Sun desenvolvido e especificado para prover uma camada de segurança entre a camada de transporte (TCP) e os protocolos de aplicação tais como HTTP, TELNET, FTP, NNTP, SMTP, etc. Este protocolo provê encriptação de dados, autenticação de servidor, integridade de mensagem e, opcionalmente, autenticação de cliente para uma conexão TCP/IP.

O sHTTP (secure HTTP) é uma extensão do protocolo http proposta pelo EIT no começo de 1994 que provê transações seguras pela incorporação de criptografia, mecanismos de autenticação no protocolo HTTP permitindo transações seguras fim-a-fim entre cliente e servidor WWW.

SSL e sHTTP tem diferentes motivações: as camadas de segurança SSL ficam sob os protocolos de aplicação, como HTTP, NNTP e TELNET, enquanto que HTTPs adiciona segurança baseada nas mensagens especificamente do protocolo HTTP no nível da aplicação. Estas duas aplicações, longe de serem mutuamente exclusivas podem coexistir perfeitamente de forma complementar com o protocolo HTTPs atuando sobre a camada SSL. $OJRULWPRV�XWLOL]DGRV�SHOR�66/�

Existem quatro grupos que podem representar o conjunto de algoritmos criptográficos utilizados pelo protocolo SSL. São estes:

• $OJRULWPRV�VLPpWULFRV� estes algoritmos são utilizados no sigilo dos dados trafegados durante uma sessão SSL. Na atual especificação do SSL são usados os algoritmos RC4, DES, 3DES, RC2, IDEA e Fortezza (cartão PCMCIA que provê tanto cifragem como assinatura digital).

• $OJRULWPRV� DVVLPpWULFRV� H� GH� GHULYDomR�GH� FKDYHV��algoritmos utilizados para a troca de chaves e para o processo de assinatura digital. Neste grupo estão o RSA, o DAS (somente assinatura) e o Diffie-Hellman (derivação de chaves).

• $OJRULWPRV� GH� KDVK� usados para prover a integridade das mensagens enviadas e no processo de criação dos segredos. São especificados o MD5 e o SHA.

12

• $OJRULWPRV� GH� FRPSDFWDomR� na atual versão do SSL não há nenhuma especificação para funções de compactação.

Estes algoritmos são escolhidos no protocolo através do uso das ciphersuites. As

ciphersuites são combinações dos algoritmos listados acima e possui a seguinte regra geral:

PROT_KE_SIGALG_WITH_SIMALG_MAC onde, PROT é na atual especificação o valor SSL; KE é o algoritmo de troca de chaves;

SIGALG é o algoritmo usado para as assinaturas digitais; SIMALG é o algoritmo simétrico;

MAC é o algoritmo de hash usado nos MACs. Nem todas as ciphersuites possuem todas esses componentes.

Por exemplo, a ciphersuite SSL_RSA_WITH_RC4_128_SHA não 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 exceção a essa regra são as ciphersuites de exportação, as quais possuem além dos componentes citados acima, também a componente _EXPORT_ antes do WITH, sinalizando que os algoritmos usados nesta ciphersuite sofrem as limitações impostas pelo governo americano para algoritmos criptográficos. � 3URWRFROR�&KDQJH�&LSKHU6SHF�

O Change CipherSpec é um dos protocolos sobre os quais o SSL é construído, com o objetivo de sinalizar transações entre estratégias de cifragem usadas na sessão.

O protocolo Change CipherSpec é o mais simples dos três protocolos específicos SSL que usa o protocolo Record SSL. Este protocolo consiste de uma única mensagem que consiste de um único byte com o valor 1.

O propósito exclusivo desta mensagem é fazer a cópia do estado pendente no estado atual, o qual atualiza o Cipher Suite a ser usado nesta conexão, ou seja, estabelece concordância no Cipher Suite da sessão.

O Cipher Suite consiste em quais métodos serão usados para troca de chaves (Key Exchanges), transferência de dados e criação de código de autenticação de mensagem (Message Authentication Code - MAC).

13

Este protocolo é usado quando o handshake termina e a transferência de dados está preste a começar. Também pode ser usado quando os pares querem trocar a especificação Cipher a ser usada, isto é bom quando muito tempo se passou com o mesmo canal seguro aberto.

Os dados SSL &RPSUHVVHGV são protegidos com a cifra e algoritmo de MAC definidos na CipherSpec da sessão (o MAC é calculado antes da cifragem). O resultado é um bloco do tipo SSL &LSKHUWH[W.

Em resumo, este protocolo sinaliza as transições nas estratégias de cifragem. Constitui-se de uma única mensagem que pode ser transmitida tanto pelo cliente como pelo servidor para notificar que os próximos blocos utilizarão chaves de encriptação recém negociadas.

3URWRFROR�$OHUW�Este protocolo é usado para comunicar à entidade par os alertas relacionados ao

SSL. Assim como outras aplicações que usam o SSL, mensagens são comprimidas e criptografadas, como especificado no estado atual.

O protocolo Alert acompanha os erros na Record Layer, fazendo troca de mensagens para sinalizar problemas com a seqüência de mensagens, erros de certificação ou encriptação.

Cada mensagem neste protocolo consiste de dois bytes. O primeiro assume o valor de atenção (1) ou fatal (2) para exprimir a severidade da mensagem. Se o nível de severidade da mensagem é fatal, o SSL termina a conexão imediatamente. Outras conexões na mesma sessão podem continuar, mas nenhuma nova conexão nesta sessão pode ser estabelecida.

O segundo byte contém um código que indica o alerta específico.

Abaixo estão listados os alertas que são sempre fatais pela especificação do SSL:

0HQVDJHPBLQHVSHUDGD��XQH[SHFWHGBPHVVDJH�� uma mensagem imprópria foi recebida;

0$&BPDXBJUDYDGR��EDGBUHFRUGBPDF�� um MAC incorreto foi recebido;

)DOKDBQDBGHVFRPSUHVVmR� �GHFRPSUHVVLRQBIDLOXUH�� a função responsável pela descompressão recebeu uma entrada imprópria. Por exemplo: o resultado da descompressão seria maior do que o tamanho máximo permitido;

14

)DOKDBQRBKDQGVKDNH� �KDQGVKDNHBIDLOXUH�� o remetente não é capaz de negociar um conjunto aceitável de parâmetros de segurança fornecendo as opções disponíveis;

3DUkPHWURBLOHJDO� �LOOHJDOBSDUDPHWHU�� um campo na mensagem de handshake estava fora de alcance ou inconsistente aos outros campos.

Os tipos de alertas restantes são:

1RWLILFDomRBIHFKDPHQWR� �FORVHBQRWLI\�� informa o recebedor da mensagem que o remetente não irá enviar mais nenhuma mensagem na conexão. Cada parte é requisitada a enviar um alerta notificação_fechamento antes de fechar o lado de escrita de uma conexão;

1HQKXPBFHUWLILFDGR� �QRBFHUWLILFDWH�� pode ser enviado em resposta a uma requisição certificada se nenhum certificado apropriado está disponível;

0DXBFHUWLILFDGR� �EDGBFHUWLILFDWH�� um certificado recebido está corrompido, por exemplo: contém uma assinatura que não é reconhecida;

&HUWLILFDGRBQmRBVXSRUWDGR� �XQVXSSRUWHGBFHUWLILFDWH�� o tipo de certificado recebido não é suportado;

&HUWLILFDGRBUHYRJDGR� �FHUWLILFDWHBUHYRNHG�� um certificado foi revogado por seu assinante;

&HUWLILFDGRBH[SLUDGR��FHUWLILFDWHBH[SLUHG�� um certificado expirou;

&HUWLILFDGRBGHVFRQKHFLGR� �FHUWLILFDWHBXQNQRZ�� alguma outra aplicação tornou o certificado inaceitável.

O protocolo Alert é usado quando algum par da comunicação quer fechar a conexão ou se um dos pares detectou algum erro na transferência, na autorização ou algo parecido.

�3URWRFROR�66/�+DQGVKDNH�O Protocolo Handshake é a principal parte do SSL. Ele é constituído por duas

fases. Na primeira, é feita a escolha da chave entre o cliente e o servidor, a autenticação do servidor e a troca da chave Master. Já na segunda parte, são feitos a autenticação do cliente (se requerida) e o fim do handshake. Após o handshake estar completo, a transferência de dados entre aplicações pode ser iniciada. As mensagens do protocolo Handshake seguem o formato da figura abaixo, onde:

+DQGVKDNH�7\SH� indica o tipo de mensagem de handshake sendo enviada (1 byte);

15

7DPDQKR� tamanho do corpo em bytes (3 bytes);

&RUSR� são os dados da mensagem sendo enviada (maior ou igual a 1 byte).

)RUPDWR�GD�PHQVDJHP�GR�SURWRFROR�+DQGVKDNH�O processo de handshake pode ser realizado de diferentes formas dependendo se

há autenticação ou não das partes envolvidas e/ou se uma sessão é retomada. A figura que segue mostra uma possível execução do processo de handshake. As mensagens trocadas estão descritas na seqüência.

([HFXomR�GR�SURFHVVR�KDQGVKDNH�1) Cliente envia um número aleatório e uma lista de cifras e métodos de compressão que estaria apto a negociar com o servidor (mensagem CLIENT_HELLO).

2) Servidor retorna seu número aleatório e a cifra e método selecionados (mensagem SERVER_HELLO).

3) Caso o servidor deva se autenticar (condição já sabida a partir da ciphersuite negociada), este envia seu certificado, o qual conterá sua chave pública (SERVER_CERTIFICATE). O tipo de certificado enviado dependerá da FLSKHUVXLWH negociada.

4) Caso seja necessária à autenticação 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).

16

5) Cliente então responde ao servidor, enviando seu certificado (mensagem CLIENT_CERTIFICATE).

6) Cabe, ao cliente, a geração do segredo a ser utilizado futuramente como chave de sessão. Sendo assim, O cliente gera tal segredo e o envia (cifrado com a chave pública retirada do certificado do servidor) ao servidor (mensagem CLIENT_KEY_EXCHANGE).

7) Caso o certificado do cliente tenha capacidade de assinatura, o mesmo é capaz de verificar sua autenticidade. Neste caso, é efetuada a autenticação do cliente através da mensagem CERTIFICATE_VERIFY.

8) Ambos os lados possuem agora as chaves de sessão a serem utilizadas. Uma última mensagem é enviada (mensagem FINISHED - já decifrada com os segredos negociados) por ambas as partes, e assim, o processo de handshake é finalizado.

Para melhor entendimento, estas trocas podem ser interpretadas tendo quatro fases:

• )DVH��(VWDEHOHFLPHQWR�GDV�&DSDFLGDGHV�GH�6HJXUDQoD� • )DVH��$XWHQWLFDomR�GR�VHUYLGRU�H�7URFD�GH�FKDYH� • )DVH��$XWHQWLFDomR�GR�FOLHQWH�H�7URFD�GH�&KDYH� • )DVH��)LQDOL]DomR� O objetivo da primeira fase é iniciar uma conexão lógica e estabelecer as

capacidades de segurança que serão associadas a ela. Caracteriza-se pela troca de mensagens do tipo hello, client_hello e server_hello, com os seguintes parâmetros:

9HUVLRQ: a mais alta versão SSL entendida pelo cliente;

5DQGRP: uma estrutura aleatória gerada pelo cliente. Esta estrutura deve ser diferente na mensagem do cliente e do servidor;

6HVVLRQ,': um identificador de sessão de tamanho variável. Um número diferente de zero indica que o cliente deseja atualizar os parâmetros de uma conexão existente ou criar uma conexão nova nesta sessão. Um valor zero indica que o cliente deseja estabelecer uma nova conexão em uma nova conexão;

&LSKHU6XLWH��este é uma lista que contém as combinações de algoritmos criptográficos suportados pelo cliente, em ordem decrescente de preferência. Cada elemento da lista define tanto um algoritmo de troca de chaves um CipherSpec;

0pWRGR�GH�&RPSUHVVmR: é uma lista dos métodos de compressão que o cliente suporta.

17

Podemos explicar as trocas de mensagens nas fases da seguinte forma: o cliente envia uma mensagem FOLHQWBKHOOR para a qual o servidor deve responder com uma mensagem VHUYHUBKHOOR, ou então um erro fatal irá acontecer e a conexão irá falhar. Estas mensagens, FOLHQWBKHOOR� e VHUYHUBKHOOR, são usadas para se estabelecer capacidades de segurança maiores entre o cliente e o servidor.

As duas mensagens estabelecem os seguintes atributos: versão do protocolo, sessionID, CipherSuite e método de compressão. Adicionalmente, dois valores randômicos são gerados e trocados: ClientHello.random e ServerHello.random. Após estas mensagens de hello, o servidor enviará seu certificado, se este tiver que ser autenticado. Podemos ter uma mensagem server_key_exchange sendo enviada, iniciando a segunda fase, se for requisitada. Isto pode acontecer, por exemplo, nos casos do servidor não ter um certificado ou se seu certificado é somente para sinalização. Se o servidor for autenticado, ele pode requisitar um certificado do cliente, se isto for conveniente ao CipherSuite selecionado.

Então, o servidor enviará a mensagem server_hello_done, indicando que a fase das mensagens do tipo hello, primeira fase, do handshake está completa. O servidor irá, então, esperar pela resposta do cliente. Se o servidor tiver enviado uma mensagem certificate_request, o cliente deve enviar uma mensagem certificate ou um alerta no_certificate.

A mensagem client_key_exchange é enviada agora, iniciando a terceira fase, e o conteúdo desta mensagem irá depender no algoritmo de chave pública selecionado entre as mensagens client_hello e server_hello. Se o cliente enviou um certificado com habilidade de sinalização, uma mensagem sinalizada digitalmente certificate_verify é enviada para verificar o certificado explicitamente.

Neste momento, uma mensagem change_cipher_spec é enviada pelo cliente, e este copia o CipherSpec pendente no CipherSpec corrente. O cliente então, envia imediatamente a mensagem finished, iniciando a quarta fase, sobre os novos algoritmos, chaves, e segredos. Em resposta, o servidor enviará sua própria mensagem change_cipher_spec, transfere o CipherSpec pendente para o atual, e envia sua mensagem finished sobre o novo CipherSpec. Terminamos assim, o handshake, e o cliente e o servidor podem começar a trocar dados da camada de aplicação.

Quando o cliente e o servidor decidem continuar uma sessão prévia ou duplicar uma sessão existente temos o seguinte fluxo de mensagens:

• O cliente envia uma mensagem client_hello usando o SessionID da sessão a ser retomada. O servidor, então, verifica sua cache de sessão por algo correspondente. Se encontrar, e o servidor está disposto a restabelecer a conexão sobre o estado específico da sessão, ele enviará uma mensagem server_hello com o mesmo valor SessionID. • O cliente e o servidor devem enviar mensagens change_cipher_spec e seguir diretamente para as mensagens finished. Assim que o restabelecimento

18

estiver completo, o cliente e o servidor podem começar a trocar dados da camada de aplicação.

Dentre as trocas de mensagens explicadas acima são realizadas uma série de ações, que são explicadas na seqüência.

0HQVDJHQV�GH�+HOOR�

As Mensagens de Hello são usadas para trocar capacidades de segurança entre o cliente e o usuário.

+HOOR�5HTXHVW�

Esta mensagem é enviada por um servidor a fim de sinalizar ao cliente que, assim que for possível, um processo de handshake pode ser iniciado. Uma vez enviada, o servidor não poderá enviar outra mensagem HELLO_REQUEST, até que o processo de handshake seja executado.

Esta mensagem não possui campo algum.

&OLHQW�+HOOR�

Esta mensagem é enviada pelo cliente com o intuito de iniciar um processo de handshake. Nesta mensagem o cliente informa ao servidor as ciphersuites e métodos de compressão suportados por ele e ordenados de acordo com sua vontade ou preferência. Através desta mensagem, o cliente pode ainda dar início a um processo de retomada de sessão enviando, para isso, o ID de uma sessão cacheada. O formato desta mensagem é mostrado pela figura abaixo:

)RUPDWR�GD�PHQVDJHP�&/,(17(B+(//2�6HUYHU�+HOOR�

Nesta mensagem, o servidor envia a ciphersuite e método de compressão selecionada de acordo com suas listas de ciphersuites e métodos de compressão. A escolha de uma ciphersuite é feita da seguinte forma: a primeira ciphersuite do cliente que coincidir com alguma ciphersuite do servidor é a selecionada (“ first-choice-first” ). O mesmo processo é feito para o método de compressão. Caso nenhuma ciphersuite coincida, o servidor enviará um alerta handshake_failure para o cliente.

Quando o servidor recebe uma CLIENT_HELLO com o randômico diferente de vazio, caso deseje, pode realizar uma retomada de sessão. Na tentativa de retomar uma sessão, o servidor checa em seu cache a existência de alguma sessão cacheada cujo ID

19

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. Porém, caso não encontre em cache ou não deseje realizar a retomada de sessão, 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 sessão seja cacheada. Para isso, ele envia um ID vazio. O formato desta mensagem é mostrado abaixo:

)RUPDWR�GD�PHQVDJHP�6(59(5B+(//2��6HUYHU�&HUWLILFDWH�

O servidor usa esta mensagem para se autenticar e, dependendo do tipo de certificado, enviar para o cliente dados públicos (e confiáveis) 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 são 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 públicos que possibilitem a troca de chaves. Neste caso, como não será possível assiná-los, um intruso poderá penetrar na comunicação e espelhar a troca de mensagens entre as partes envolvidas na comunicação (ataque por espelhamento).

6HUYHU�.H\�([FKDQJH�

Esta mensagem carrega os dados públicos do servidor os quais serão usados no processo de troca de chaves. Ela é enviada pelo servidor quando ele não possui um certificado, possui um certificado somente para assinatura, ou possui um certificado cujos dados públicos usados para a troca de chave possuem um tamanho superior ao estipulado pela ciphersuite negociada. Esta mensagem não deve ser enviada caso o certificado do servidor contenha parâmetros públicos Diffie-Hellman.

Existem dois tipos de certificados somente para assinatura: certificados DSS e certificados RSA cujo campo KEYUSAGE possui a flag SignOnly setada.

O conteúdo desta mensagem dependerá dos algoritmos de troca de chaves e assinatura especificadas na ciphersuite selecionada. No caso de uma ciphersuite não anônima, ou seja, uma ciphersuite que possui um algoritmo para assinatura, os valores públicos enviados nesta mensagem são assinados.

De acordo com os algoritmos de troca de chaves e assinaturas negociadas, a SERVER_KEY_EXCHANGE pode ter os seguintes formatos:

20

7URFD�GH�FKDYH�H�DVVLQDWXUD�XVDQGR�56$�

• Valores públicos RSA; • Assinatura dos valores públicos. A assinatura é feita da seguinte forma:

1. Calcula-se o hash MD5 a partir dos valores públicos RSA mais os randômicos enviados nas mensagens CLIENT_HELLO e SERVER_HELLO; 2. Calcula-se o hash SHA dos mesmos dados que alimentam o hash MD5; 3. Os resultados dos dois hashs são assinados usando a chave-privada RSA do servidor.

7URFD�GH�FKDYHV�'LIILH�+HOOPDQ�H�DVVLQDWXUD�XVDQGR�56$�

• Valores públicos Diffie-Hellman; • Assinatura dos valores públicos. A assinatura é feita da mesma forma descrita acima, salvo o fato de os valores públicos serem Diffie-Hellman.

7URFD�GH�FKDYHV�'LIILH�+HOOPDQ�DQ{QLPR�

• Valores públicos Diffie-Hellman; • NÃO é feita a assinatura dos valores públicos. Neste caso, o protocolo fica suscetível ao ataque de espelhamento, pois um intruso pode se infiltrar na comunicação e alterar esta mensagem sem que nenhuma das outras partes envolvidas tenha conhecimento.

Os parâmetros Diffie-Hellman enviados nesta mensagem são também denominados parâmetros Diffie-Hellman Efêmeros pelo fato de serem gerados no momento do envio da mensagem (não necessariamente toda vez que uma SERVER_KEY_EXCHANGE é enviada). O uso deste tipo de parâmetro acrescenta uma segurança a mais ao protocolo: se uma chave for descoberta ou espelhada, somente uma sessão terá sido atacada. Além disso, um outro aspecto importante a ser ressaltado, é o fato de que o tempo de uso dos valores públicos é extremamente reduzido, dificultando a quebra do valor privado através do ataque por cifra.

&HUWLILFDWH�5HTXHVW�

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.

Um servidor anônimo não pode solicitar que um cliente se autentique. Caso um cliente receba uma CERTIFICATE_REQUEST de um servidor anônimo, ele deve responder com um alerta handshake_failure. Segue abaixo o formato desta mensagem.

21

)RUPDWR�GH�PHQVDJHP�&(57,),&$7(B5(48(67�6HUYHU�+HOOR�'RQH�

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á início à verificação dos dados enviados pelo servidor durante a fase de Hello. O cliente verifica se o servidor proveu um certificado aceitável (se enviado) e se os demais parâmetros de Hello são aceitáveis.

&OLHQW�&HUWLILFDWH�

Esta mensagem é enviada pelo cliente, em resposta a CERTIFICATE_REQUEST, com a função de autenticá-lo. O conteúdo 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 opções impostas pela mensagem CERTIFICATE_REQUEST (tipo de certificado e nome de CA). Caso o cliente não possua um certificado ou possua um que não atenda às opções, deve enviar um alerta no_certificate. Certificados Diffie-Hellman enviados pelo cliente deverão possuir os mesmos parâmetros Diffie-Hellman contidos no certificado do servidor.

&OLHQW�.H\�([FKDQJH�

O cliente envia esta mensagem para o servidor a fim de fornecer o dado necessário à criação de um segredo compartilhado. Esta informação recebe o nome de PreMasterSecret e seu valor é dependente do algoritmo de troca de chave especificado na ciphersuite escolhida. Segue agora uma explicação de como a PreMasterSecret é gerada.

7URFD�GH�FKDYHV�XVDQGR�56$�Quando o RSA é utilizado para a troca de chaves, a PreMasterSecret é um número

de 48 bytes gerados pelo cliente, formado pela versão do protocolo (2 bytes) e por 46 bytes randômicos. Estes 48 bytes são então cifrados usando a chave pública do servidor (envelope digital) e enviados de forma a garantir que somente os dois tenham conhecimento do seu valor, veja figura:

7URFD�GH�FKDYHV�XVDQGR�56$��

22

'HULYDomR�GH�FKDYHV�XVDQGR�'LIILH�+HOOPDQ�No processo de troca de chaves usando o Diffie-Hellman, o cliente envia para o

servidor o seu valor público e ambos executam o processo de derivação de chave. O valor resultante deste processo é a PreMasterSecret. O cliente só envia seu valor público nesta mensagem caso o certificado enviado por ele não o contenha.

Imediatamente após o cliente enviar esta mensagem e o servidor recebê-la, dar-se-á início ao processo de geração da MasterSecret. A MasterSecret é um segredo compartilhado pelas partes envolvidas no handshake e que, posteriormente, é usado para a geração das chaves de sessão e segredos utilizados no cálculo dos MACs.

Logo que a MasterSecret é calculada, a PreMasterSecret deve ser destruída da memória e o processo de geração do KeyBlock deve ser executado. O KeyBlock é um vetor de bytes resultante de uma seqüência de hashes seguros envolvendo a MasterSecret. É a partir do KeyBlock produzido que o SSL retira os dados que deverão ser usados como chaves de sessão, vetores de inicialização e segredos para os MACs.

A quantidade de hashes que deverão ser calculados dependerá da quantidade de material randômico necessário para preencher todos os segredos utilizados pela camada Record.

Em caso de ciphersuites geradas em implementações licenciadas para exportação, os quatros últimos valores são 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.

&HUWLILFDWH�9HULI\�

Esta mensagem provê uma forma explicita de o servidor verificar o certificado enviado pelo cliente. Seu conteúdo é a assinatura digital de dois hashes cuja entrada são todas as mensagens de handshake enviadas até o momento, desconsiderando-se esta. O servidor, ao recebê-la, executa a verificação da assinatura, tal qual abordado na sessão de Assinaturas Digitais deste documento. Em caso de erro na verificação da assinatura, o servidor envia um alerta de handshake_failure.

Clientes que possuem certificados Diffie-Hellman não podem enviar esta mensagem, pelo motivo óbvio de o Diffie-Hellman não poder ser utilizado para assinaturas digitais.

)LQLVKHG�

Esta é a primeira mensagem no processo de handshake a ser enviada decifrada. Ela é enviada imediatamente após a mensagem de CHANGE_CIPHER_SPEC, tanto pelo

23

cliente quanto pelo servidor, com a função de validar os processos de troca de chaves e autenticação. Seu conteúdo são dois hashes (com segredo - MasterSecret), de todas as mensagens de handshake enviadas até o momento, excluindo-se esta, veja a figura:

)RUPDWR�GD�PHQVDJHP�),1,6+('�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. Após esta mensagem, a troca de mensagens de aplicação através do canal de cifra negociada pelo SSL é liberada.

�3URWRFROR�66/�5HFRUG�A camada SSL Record encapsula vários protocolos de alto nível, e usa a definição

de estado corrente para, além de outras coisas, selecionar os algoritmos de compressão e criptografia apropriados. O estado corrente é determinado durante o processo de handshaking previamente descrito.

Ela age comprimindo os dados, usando o algoritmo de compressão selecionado no estado corrente. Todos os dados são protegidos usando os algoritmos de criptografia e MAC definidos no CipherSpec corrente, que é parte do estado corrente. O algoritmo MAC utiliza um Message Authentication Code e uma função hash para assegurar a integridade dos dados.

Os processos descritos acima são reversíveis na Camada Record, no outro lado do canal de comunicações, onde os dados são decodificados, verificados, expandidos e reunidos antes de serem enviados para clientes em alto nível.

Para encerrar uma sessão, uma das partes envia uma mensagem comunicando esse fato (Close Notify). Caso o cliente queira estabelecer nova sessão com o servidor, pode fornecer seu identificador de sessão em sua mensagem de início, dando assim continuidade a sessão estabelecida anteriormente.

A figura abaixo representa a interação do protocolo Record dentro da estrutura SSL.

24

(VWUXWXUD�66/� ,QIUD�HVWUXWXUD�GH�&KDYH�3~EOLFD��3XEOLF�.H\�,QIUDVWUXFWXUH��3.,�� Atualmente, quase que na maioria dos portais web na Internet que oferecem algum tipo de serviço on-line ou produtos etc., estão de alguma forma utilizando a Infra-estrutura de Chave Pública (PKI). Isso ocorreu pela necessidade de se criar um mecanismo ou estrutura organizada que criasse regras e fortalecesse ainda mais os protocolos SSL e IPSec utilizados para prover segurança. Implementações dos protocolos SSL e ate do IPSec geralmente utilizam o PKI para aumentar o grau de segurança nas transações on-line, porém não há uma necessidade que os protocolos (SSL, IPSec) trabalhem em conjunto com o PKI. A implantação do PKI em conjunto com o SSL ou IPSec fica a critério do implementador e conforme as necessidades de negócios de cada empresa. ��

Uma Infra-estrutura de Chave Pública tem o objetivo de fornecer e definir regras técnicas para instituições públicas e privadas com relação às transações de troca de documentos transmitidos e obtidos eletronicamente. Essas regras técnicas serão utilizadas como mecanismos de validação jurídica com o propósito de garantir a autenticidade e integridade dos documentos em formatos eletrônicos. Um dos mecanismos de validação do PKI se chama Certificado, que é uma espécie de selo eletrônico fornecido por Autoridades Certificadoras – CA definido pela norma X.509v3 (RFC 2459) que a mais atual.

Empresas que praticam negócios on-line e que implementam o protocolo SSL em

conjunto com o PKI, de tal forma proporcionam mais segurança ao cliente que acessa seu portal on-line. Com a utilização 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 através de certificado que garante alem de autenticidade uma validação jurídica que para os negócios on-line efetuado pela empresa. � A norma ou formato X.509 que define o certificado teve sua primeira versão publicada em 1988, a segunda versão saiu em 1993 após revisão da primeira versão. A terceira e última versão do X.509 foram publicadas em 1997 que resultou na norma X.509v3 e que define os certificados emitidos por CA atualmente.

25

2EV��2�SURWRFROR�66/��6HFXUH�6RFNHW�/D\HU��SURSRUFLRQRX�R�SULPHLUR�FRQWDWR�DR�3.,��$WXDOPHQWH� R� 3.,� HVWD� VHQGR� PXLWR� GLVVHPLQDGD� DWUDYpV� GH� LPSOHPHQWDo}HV� 931V�EDVHDGDV�QR�SURWRFROR�,36HF�H�QHJyFLRV�RQ�OLQH�EDVHDGRV�QR�SURWRFROR�KWWS��KWWSV� ��KWWS��VVO�� $XWRULGDGH�&HUWLILFDGRUD��&HUWLILFDWLRQ�$XWKRULW\�±�&$�� A Autoridade Certificadora é uma instituição publica ou privada com estrutura hierárquica responsável pela emissão de certificados digitais visando identificar pessoas, usuários, sistemas, redes, equipamentos etc., para proporcionar um relacionamento de confiança entre sessões de comunicação na rede. O papel principal da CA é determinar políticas e procedimentos que orientam o uso dos certificados por todo o sistema. A Autoridade Certificadora tem varias outras atribuições conforme lista resumida descrita abaixo. Quando uma empresa que pratica negócios on-line e utiliza o protocolo SSL para prover segurança quiser implementar o PKI ou fazer parte dela, deverá procurar pelas diversas CA cadastradas pela ICP-Brasil (PKI raiz do Brasil) para fazer a requisição do certificado digital e tornar parte na infra-estrutura de PKI.

Atribuições da Autoridade Certificadora: – fonte - livro VPN, Lino Sarlo da Silva.

• Manter a mais Rígida Segurança possível para chave privada CA. • Assegurar que seu próprio certificado seja amplamente distribuído. • Emissão de Certificados. • Revogação de Certificados. • Emissão de Lista de Certificados Revogados. • Publicação de Lista de Certificados Revogados. • Disponibilizar a situação do certificado quando requerida. • Gerencia de chaves criptográficas. • Publicação de suas regras operacionais • Fiscalização do cumprimento desta política pelos usuários.

Obs. 1R�%UDVLO�WHPRV�R�,&3�%UDVLO��,QIUD�HVWUXWXUD�GH�&KDYH�3XEOLFD�%UDVLOHLUD��LPSOHPHQWDGDV� SRU� LQVWLWXLo}HV� S~EOLFDV� H� SULYDGDV� EUDVLOHLUDV� �6(5$6$�� &$,;$��6(5352�� 81,&(57� HWF�� $V� $XWRULGDGHV� &HUWLILFDGRUDV� �&$�� TXH� DLQGD� QmR� HVWmR�YLQFXODGDV� D� ,&3�%UDVLO� SRGHP� HPLWLU� FHUWLILFDGRV� GLJLWDLV�� SRUpP� QmR� WHUmR�HPEDVDPHQWR� QDV� OHLV� EUDVLOHLUDV�� 2� ,7,� �,QVWLWXWR� 1DFLRQDO� GH� 7HFQRORJLD� GD�,QIRUPDomR��p�D�$XWRULGDGH�&HUWLILFDGRUD�5DL]�GD�,&3�%UDVLO�FRQIRUPH�'HFUHWR��GH��

26

&HUWLILFDGR�'LJLWDO�� A certificação digital foi à maneira encontrada para prover serviços de identificação, autenticação e privacidade para transações eletrônicas. Talvez ficaria mais fácil o entendimento se fizermos uma comparação com os mecanismos e serviços tradicionais de identificação, autenticação e privacidade que estamos acostumados a utilizar. Por exemplo, em transações físicas do tipo autenticação de documentos, os desafios de identificação, autenticação e privacidade são resolvidos com marcas físicas, tais como selos e assinaturas providas por uma entidade que confiamos (ex. cartório). No entanto, nos casos de transações eletrônicas, tipo compras on-line, envio de documentos eletrônicos, e-mail etc., o equivalente ao mecanismo tradicional seria o “ selo ou certificado” digital que vem codificado na própria informação e que é fornecido “ assinado” pela Autoridade Certificadora (CA) que faz parte da Infra-estrutura de chaves publicas (PKI) e segue um padrão de certificado X.509, RFC 2459 junto com Normas da RSA PKCS etc. Uma vez que o documento recebeu um certificado digital, sua alteração fica quase que impossível de não ser detectada. Uma violação de um documento certificado digitalmente seria facilmente identificada através dos mecanismos e algoritmos de criptografia utilizados para prover as funcionalidades de identificação, autenticação e privacidade, mesmo que apenas 1 bit seja modificado no documento. Em resumo um certificado digital é uma cadeia de bits que foi gerado através de algoritmos criptográficos que teve como entrada as informações que se desejava obter o certificado digital.

)RUPDWR�GR�&HUWLILFDGR�'LJLWDO��

'LDJUDPD�VLPSOHV�GH�XP�FHUWLILFDGR�GLJLWDO�;��Y��QmR�LQFOXLQGR�DV�H[WHQV}HV�Y��VWDQGDUG��,QIRUPDomR�EiVLFD�� )RUPDWR�GR�FHUWLILFDGR Versão 3 1��GH�6pULH�GR�FHUWLILFDGR 123456789 ,GHQWLILFDGRU�GR�DOJRULWPR�GH�DVVLQDWXUD�GD�(& RSA com MD5 (QGHUHoR�;��GR�HPLVVRU C=PT, o=EC 3HUtRGR�GH�YDOLGDGH Start=01/08/96,

expiry=01/08/98

1RPH�;��GR�XWLOL]DGRU c=PT,o=organização,cn=João Silva + .....

&KDYH� S~EOLFD� GR� XWLOL]DGRU� H� PpWRGR�FULSWRJUiILFR�XWLOL]DGR C.P.U. + RSA com MD5

([WHQV}HV�9�

Tipo Criticidade Valor Morada, bit off/não crítico, Rua das Codornizes 183 Tipo Criticidade Valor âmbito, bit on/crítico, Válido somente para Assinatura Digital

27

Tipo Criticidade Valor Nível de acesso,bit off/não crítico, 1- geral Tipo Criticidade Valor ......

Dados retirado do http://www.multicert/pergunta2.htm (11.10.03)

,PDJHP�GH�XP�FHUWLILFDGR�'LJLWDO�� Esse é um formato típico de um certificado digital que recebemos diariamente quando efetuamos uma conexão http(ssl) segura. Quando recebemos um certificado digital em uma transação, o browser se encarrega de fazer a checagem na CA para saber se pode confiar ou não. Se tudo correr bem o usuário 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 não conseguir autenticar o certificado digital recebido, uma outra mensagem (Security Warning – ver exemplo abaixo) ira surgir no monitor do usuário com a opção de aceitar ou não o certificado digital recebido.

,PDJHP�GH�XP�6HFXULW\�:DUQLQJ�� Essa mensagem de Security Warning vai aparecer para o usuário somente nos casos em que o certificado digital recebido não pode ser autenticado pelas CAs já

28

cadastradas no browser do usuário. Podemos observar que essa mensagem de Security Warning da a opção de aceitar ou rejeitar o certificado (yes ou no) recebido. A regra é não aceitar certificados que não seja autenticado pelos CA ja cadastrados no browser do usuário. Para obter informações com relação aos CA e certificados cadastrados no seu browser é só abrir o Browser (Iexplore), menu Ferramentas, menu Opções Internet, menu Conteúdo, botão Certificado.

�$SOLFDo}HV�TXH�XWLOL]DP�&HUWLILFDGRV�'LJLWDLV��

• $SOLFDo}HV� EDQFiULDV��A grande maioria dos bancos utiliza certificados digitais para proporcionar maior segurança ao cliente. Um exemplo disso é o Banco do Brasil, que alem de enviar o certificado digital assegurando que o cliente esta conectando no servidor desejado, ele também fornece a opção do cliente obter um certificado digital gratuito com validade de um ano. Quando o cliente também emite um certificado o nível de segurança nas transações aumenta ainda mais.

• $FHVVR�UHPRWR�GH�IXQFLRQiULRV�GH�XPD�RUJDQL]DomR��Funcionários de uma determinada empresa (vendedores, consultores, diretores etc.) podem se logar remotamente utilizando mecanismos como SecurityID ou token que possibilita a certificação dos mesmos junto ao servidor acessado. Isso possibilita acesso a

29

Intranet/Extranet, base de dados, treinamento on-line com total confidencialidade e segurança etc.

• 9HQGDV�2Q�OLQH��A grande maioria dos portais web já utiliza certificados digitais para autenticarem seus servidores na hora de efetuarem transações que envolvem envio de dados confidenciais do tipo Nr. de cartões de créditos. Podemos citar como exemplo o site da www.submarino.com.br que utiliza SSL com certificação digital dos seus servidores nas transações que envolve envio de dados confidenciais.

• $FHVVR� UHPRWR� YLD� 931�,36HF�� Já esta se tornando uma realidade funcionários de determinadas empresas e ramo de negócios trabalharem em casa via conexão VPN baseadas em IPSec. Exemplo: desenvolvimento de software, vendedores, etc. Uma conexão VPN baseada em IPSec também pode utilizar certificado digital para estabelecer a conexão segura entre dois usuários finais.

Enfim, essas são apenas algumas das aplicações que utilizam certificados digitais.

Nos últimos anos os certificados digitais vêm ganhando força no mercado virtual denominado Internet. Da mesma forma que as transações on-line crescem na Internet os certificados digitais também vão ganhando seu espaço. Certificação digital provavelmente foi à maneira mais fácil encontrada pelas organizações que praticam negócios on-line em aumentar o grau de segurança em suas transações proporcionando ao usuário final uma sensação de sigilo absoluto. ([HPSORV�GH�HPSUHVDV�TXH�XWLOL]DP�R�SURWRFROR�66/�

A UPS é uma grande transportadora expressa de documentos e encomendas,

presente em 200 países e territórios independentes em todo o mundo. Para permitir a entrega segura de documentos particulares através da Internet, a empresa lançou, o serviço Dossier On-line. O Dossier se integra ao VeriSign OnSite para permitir aos clientes enviar e receber documentos protegidos por certificados digitais on-line. Atualmente, os documentos chegam em minutos ou horas e não mais de um dia para o outro. Isso permite decisões comerciais melhores e mais rápidas. Os clientes comerciais, agora, podem ter certeza de que os documentos eletrônicos enviados pela UPS serão entregues ao destinatário pretendido, intactos e inalterados.

A Verisign Incorporation, fez um acordo para disponibilizar seu serviço Payflow

para os comerciantes on-line da American Express Company. O acordo com a empresa de cartão de crédito permitirá que os comerciantes autorizem e efetuem transações

30

diretamente com ela, em tempo real, sem ter que pagar a tarifa por transação. O Payflow é o único serviço de pagamento que não cobra juros e está disponível para os comerciantes on-line. A capacidade do Payflow, para processar transações em tempo real, permite que a autorização seja mais rápida que a dos processadores que enviam o pagamento para a American Express, em lotes, de poucos em poucos minutos. $WDTXHV�GRFXPHQWDGRV�±�0DQ�LQ�WKH�PLGGOH��0,70��

�

1R�FDVR�GH�0DQ�LQ�WKH�0LGGOH�HP�FRQH[}HV�66/�

Mesmo as conexões protegidas pelo protocolo SSL estão sujeitas a ataques Man in the Middle. Vamos descrever passo a passo como seria possível o ataque Man in the Middle em conexões SSL. %URZVHU � Solicita uma conexão SSL no servidor desejado �� &UDFNHU� (intercepta a solicitação de conexão SSL)�� E Solicita uma conexão SSL ao 6HUYLGRU�:HE� 6HUYLGRU�:HE � Envia a chave pública para o “ usuário” , que passa a ter o Cracker como intermediário ��&UDFNHU�(intermediário da conexão)�� Envia outra chave (gerada por ele) para o &OLHQWH�RX�%URZVHU�

&OLHQWH��

&OLHQWH��,QWHUQHW�3URYLGHU�

'16�

(PSUHVD�p�5HVSRQViYHO�SHOD�6HJXUDQoD�

)LUHZDOO�6073�SUR[\� )LUHZDOO�

�

��

��

��

,QWHUQHW�5HGH�3XEOLFD��

&OLHQWH�p�5HVSRQViYHO�SHOD�6HJXUDQoD�

�� ! � � ��

ÈUHD�GH�DWXDomR�0,70�³&UDFNHU´�

2�FUDFNHU�XWLOL]DQGR�D�WpFQLFD�0,70�DWWDFN��GHVYLD�R�WUDIHJR�GR�FOLHQWH�H�SDVVD�D�ID]HU�SDUWH��GD�FRQYHUVD�VHP�GHL[DU�QHQKXP�UDVWUR�GH�LQWUXVmR��

31

No caso de uma conexão SSL, o servidor web envia para o cliente a sua chave pública, a mesma é interceptada por um cracker que envia uma outra chave (gerada por ele) para o cliente se fazendo passar pelo servidor.

Neste momento o usuário deve prestar muita atenção nos alertas de segurança que podem vir a aparecer, veja exemplo de mensagem Security Warning demonstrada acima.

Quando é efetuada uma conexão SSL, alguns itens são verificados pelo Browser (Cliente) quando o mesmo recebe a chave pública junto com o certificado de um servidor, itens como:

o 'DWD� GH� 9DOLGDGH� GR� &HUWLILFDGR� 'LJLWDO, o &RPPRQ� 1DPH� �+RVW� ��'RPtQLR� que foi registrado no certificado. o Se for o mesmo da 85/ que está sendo acessada. o Se o Certificado digital em questão IRL� HPLWLGR� SRU� XPD� $XWRULGDGH�&HUWLILFDGRUD�GH�&RQILDQoD� etc.

Caso algum destes itens tenha algum problema, o navegador web (browser) irá

apresentar para o usuário um alerta de segurança onde no mesmo será descrito o problema e com a opção do usuário aceitar ou não a conexão SSL. É recomendado que a mesma não seja aceita e que este usuário entre em contato com a respectiva empresa.

Obs. Browsers de versões antigas não verificavam o URL contido no certificado para confrontar com o URL desejado, o que ocasionava uma facilidade para o método de ataque man-in-the-middle. As versões mais recentes dos browsers já fazem esse tipo de verificação apontando os problemas no formato de (Security Warning) para o usuário tomar a decisão.

0pWRGRV�GH�3UHYHQomR�SDUD�R�0DQ�LQ�WKH�PLGGOH�

3UHYHQomR�SRU�SDUWH�GD�FRUSRUDomR��• Adição de uma outra camada de criptografia para as informações sensíveis. • SSL duplamente autenticado (Ou seja, o servidor solicitando a autenticação do usuário que está na outra ponta pedido para o mesmo um certificado digital).

3UHYHQomR�SRU�SDUWH�GR�8VXiULR�• Nunca aceitar conexões com problemas de certificação (Ou seja, verificar atentamente os alertas de segurança que o browser pode reportar). • Atualizar o seu navegador web com todas as atualizações que forem disponibilizadas pelo seu respectivo fornecedor, principalmente os que forem referentes à segurança e verificação da cadeia de certificação.

32

3UHRFXSDo}HV�FDXVDGDV�SHOR�XVR�GR�SURWRFROR�66/�

Recentemente as empresas começaram a ficar preocupadas com o crescente tráfego de conexões SSL em suas redes. Isso se deve ao fato de que uma conexão protegida pelo protocolo SSL não sofre qualquer tipo de filtragem pelo firewall ou roteador na entrada ou na saída de uma rede, isso ocorre devido ao conteúdo estar criptografado. A preocupação com relação a isso está no sentido de que tais transações SSL podem estar trazendo para dentro da rede vírus, trojans, conteúdo pornográfico ou até mesmo documentos sigilosos da empresa podem estar sendo enviados para fora em formato criptografado.

Só para despertar interesse nos aficcionados por segurança, em Agosto/2003 uma empresa lançou um produto que faz a filtragem de conexões criptografadas SSL, ou seja, a famosa técnica Man-in-the-middle virou produto comercial com alguns detalhes mais sofisticados. Aqueles que estão interessados em aprender mais sobre o assunto, visitem a página do fabricante do produto “ Webwasher” (www.webwasher.com). O produto nem bem foi lançado e já começa a causar polêmica devido a quebra de sigilo que o mesmo proporcionará.

)HUUDPHQWDV� GH� DX[LOLR� SDUD� DQiOLVH� H� HQWHQGLPHQWR� GR�SURWRFROR�66/�

Quando descrevemos um protocolo como o SSL, temos a dificuldade de explicar e exemplificar seus mecanismos de funcionamento devido ao grau elevado de sua complexibilidade. No entanto, o texto acima trás informações bem detalhadas dos processos efetuados pelo SSL em suas implementações. Mas para aqueles que ainda acham necessário uma ferramenta de auxilio para o entendimento dos mecanismos do protocolo SSL, não serão desapontados. Após uma minuciosa pesquisa na internet encontramos varias ferramentas de auxilio conforme segue: Cryptool - http://www.cryptool.com/

Ferramenta para windows que mostra em detalhes quase todos os algoritmos de criptografia utilizados pelo protocolo SSL. SSLdump – http://www.rtfm.com/ssldump/ Ferramenta feita para linux com o objetivo de analisar o tráfego SSL em detalhes. Esse seria uma versão do TCPdump para o SSL. NewPKI - http://www.newpki.org/ ou http://www.freeicp.org/ Ferramenta para linux que proporciona uma instalação de servidor de PKI local.

33

Squid - http://www.squid-cache.org/ Ferramenta para linux que funciona como servidor de SSH e SSL. Dsniff - http://www.monkey.org/~dugsong/dsniff/ Ferramenta que proporciona mecanismo de ataque Man-in-the-middle (MITM). Procurar também por SSLSniff. SSLScanner – www.webwasher.com Ferramenta comercial que filtra conexões SSL em uma determinada empresa. Essa ferramenta apenas implementou o ataque MITM em uma de suas ferramentas (software e hardware). Essa ferramenta é recente (Ago/03) e já esta causando polêmica com relação a quebra de sigilo. Em resumo essas são apenas algumas ferramentas fundamentais para analisar e entender o funcionamento do protocolo SSL em detalhes. As ferramentas Crypto, SSLdump e Squid merecem uma atenção especial. &RQFOXVmR� Percebemos que a troca de informações sigilosas através das transações on-line (ex. Internet Banking, compras on-line etc.) sem dúvida já fazem parte do nosso dia-a-dia. Esse é o mundo virtual dos negócios conhecido como e-business que cresce quase que na mesma proporção que os crimes virtuais. Os protocolos SSL, OpenSSL, TLS, IPSec etc., são alguns dos protocolos mais utilizados para proporcionar uma camada extra de segurança nas transações on-line para evitar crimes virtuais. No entanto, esses protocolos implementados puramente; ou seja, simplesmente sem utilizar chaves públicas e privadas (PKI) já não estão oferecendo um grau aceitável de segurança. Neste caso empresas que efetuam transações sigilosas on-line já estão utilizando Certificação Digital através de PKI (chaves públicas e privadas), CA etc., bem como soluções integradas com PKI como SmartCard, SecurityID, Token que podem serem implementados conforme necessidade e grau de segurança que se quer alcançar. Podemos assim concluir que simplesmente uma implantação pura de um protocolo para prover sigilo não resolveria a questão de segurança, e sim acrescentaria uma camada extra de segurança para evitar o crime virtual. No entanto, uma implantação com varias camada extras de segurança como chaves pública (PKI), SmarCard, dentre outros, aumentaria significativamente o grau de confiabilidade; porém, não estaria 100% segura visto que teoricamente não existe solução que provê 100% de segurança.

34

%LEOLRJUDILDV�H�UHIHUrQFLDV� Livros.

• Lino Sarlo da Silva, Virtual Private Network (VPN). Novatec, 2002. • James F. Kurose e Keith W. Ross, Redes de Computadores e a Internet – Uma Nova Abordagem, Addison Wesley, 2002. • Tanenbaum, Andrew; Redes de Computadores - Terceira Edição.

Links.

• http://www.netscape.com/security/techbriefs/ssl.html, novembro de 2003. • www.rsa.com - RSA Laboratories. 3.&6�, novembro de 2003. • http://www.certsign.com.br, novembro de 2003. • http://www.verisign.com, novembro de 2003. • http://www.openssl.org, novembro de 2003. • http://ospkibook.sourceforge.net, novembro de 2003. • http://www.newpki.org, novembro de 2003. • http://www.iti.gov.br, novembro de 2003. • http://www.icpbrasil.gov.br, novembro de 2003. • http://www.rapidsite.net, novembro de 2003. • http://www.instantssl.com, novembro de 2003. • http://www.redes.unb.br/security/ssl3/protocolo.html, novembro de 2003. • http://www.geocities.com/andrezao_lrt/topicos, novembro de 2003. • http://www.gta.ufrj.br/seminarios/semin2000_1/ssl, novembro de 2003. • http://www.gta.ufrj.br/grad/00_2/ssl/ssl.htm, novembro de 2003. • http://info.iqm.unicamp.br/manuais/apache/mod/mod_ssl/ssl_reference.html, novembro de 2003. • http://www.cic.unb.br/docentes/pedro/trabs/hammurabi.htm, novembro de 2003.

Documents

Universidade Estadual de Campinas Instituto de …rdahab/cursos/mp202/Welcome...Universidade Estadual de Campinas Instituto de Computação Mestrado Profissional em Computação 2º