Universidade Estadual de Campinas Instituto de Computao

Mestrado Profissional em Computao 2. Semestre / 2003

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

Segurana da Informao MP 202 Prof. Ricardo Dahab

BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBCludio Ap. Rocha RA: 022506 Edson Tessarini Pedroso RA: 022510 Eduardo Tarciso Soares Junior RA: 015051

2

1',&(

2EMHWLYR ,QWURGXomR 23URWRFROR66/ Prioridades do Protocolo SSL .................................................................................... 7 Funcionamento ............................................................................................................. 7 Segurana...................................................................................................................... 8 As Vantagens do SSL.................................................................................................. 9

2SURWRFROR2SHQ66/ 23URWRFROR7/6 +773VYVV+773 $OJRULWPRVXWLOL]DGRVSHOR66/ 3URWRFROR&KDQJH&LSKHU6SHF 3URWRFROR$OHUW 3URWRFROR66/+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

3URWRFROR66/5HFRUG ,QIUDHVWUXWXUDGH&KDYH3~EOLFD3XEOLF.H\,QIUDVWUXFWXUH3., $XWRULGDGH&HUWLILFDGRUD&HUWLILFDWLRQ$XWKRULW\&$ &HUWLILFDGR'LJLWDO Formato do Certificado Digital. ................................................................................. 26 Imagem de um certificado Digital............................................................................. 27

$SOLFDo}HVTXHXWLOL]DP&HUWLILFDGRV'LJLWDLV ([HPSORVGHHPSUHVDVTXHXWLOL]DPRSURWRFROR66/ $WDTXHVGRFXPHQWDGRV0DQLQWKHPLGGOH0,70 No caso de Man in the Middle em conexes SSL ................................................ 30 Mtodos de Preveno para o Man-in-the-middle ................................................ 31

Preveno por parte da corporao .................................................................... 31 Preveno por parte do Usurio .......................................................................... 31 3UHRFXSDo}HVFDXVDGDVSHORXVRGRSURWRFROR66/ )HUUDPHQWDVGHDX[LOLRSDUDDQiOLVHHHQWHQGLPHQWRGRSURWRFROR66/ &RQFOXVmR %LEOLRJUDILDVHUHIHUrQFLDV

3

2EMHWLYR

O principal objetivo deste trabalho introduzir os conceitos e mecanismos de segurana utilizados pelo protocolo SSL, o qual prov uma camada extra de segurana para aplicaes como, por exemplo, Web, que efetuam transaes on-line. O protocolo SSL tambm pode ser implementado de diversas maneiras, o nosso trabalho descreve como seria uma implantao SSL com certificado digital do host servidor utilizando a Infra-estrutura de Chaves Pblicas (PKI). Outras maneiras de implementar o protocolo SSL tambm so possveis; tais como, utilizar SecurityID, certificado digital do cliente (host cliente), SecurityCard, etc..., porm tais implementaes so apenas mencionados no nosso trabalho por no fazer parte do espoco principal.

4

,QWURGXomR

O protocolo SSL 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. Todos esses mecanismos implementados em conjunto com o protocolo SSL visam uma maior segurana para as organizaes, por outro lado, outras preocupaes comeam a surgir justamente pela sua utilizao, tais preocupaes sero esclarecidas resumidamente em um tpico a parte sobre esse assunto.

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.

Ao contrrio do que a maioria das pessoas pensam, a criptografia no uma inveno recente, e tampouco de uso restrito a computadores poderosos. Apesar de a data da inveno da criptografia no ser exatamente determinada, o seu uso era conhecido h sculos. O primeiro uso da criptografia de que se tem notcia ocorreu por volta de 1900 a.C., quando um egpcio usou hierglifos para codificar mensagens.

O SSL (6HFXUH 6RFNHWV /D\HU) o protocolo responsvel por estabelecer uma conexo segura entre o cliente e o servidor atravs de criptografia ou assinatura digital. Foi desenvolvido pela Netscape a fim de prover segurana de transmisso de dados entre computadores, o SSL foi proposto ao :RUOG:LGH:HE&RQVRUWLXP (W3C) e ao ,QWHUQHW(QJLQHHULQJ 7DVN )RUFH (IETF) como um padro de segurana para ZHE EURZVHUV e servidores ZHE.

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

5

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.

6

23URWRFROR66/

O SSL pode usar o mecanismo de criptografia de chave pblica RSA para implementar transmisso segura. A criptografia de chave pblica uma tcnica que usa um par de chaves assimtricas (chave pblica e chave privada) para criptografia e descriptografia. A chave pblica amplamente distribuda, mas a chave privada mantida pelo originador da mensagem, sem qualquer divulgao. Devido s chaves assimtricas, os dados criptografados usando a chave privada s podem ser descriptografados com o uso da chave pblica. De forma inversa, os dados criptografados usando a chave pblica s podem ser descriptografados com a utilizao da chave privada.

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" (KDQGVKDNH) 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.

Confidencialidade importante para ambas s partes para qualquer transao privada. Alm do mais, todos os dados enviados sobre uma conexo encriptada SSL protegida por um mecanismo para detectar automaticamente e verificar se os dados foram alterados em trnsito.

Todo site que quiser usar SSL em conjunto com a infra-estrutura de chaves publicas (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.

7

3ULRULGDGHVGR3URWRFROR66/

6HJXUDQoD FULSWRJUiILFD SSL deve ser usado para estabelecer uma conexo segura em duas partes.

,QWHURSHUDELOLGDGH Programadores independentes podem desenvolver aplicaes utilizando SSL que ento ser capaz de trocar parmetros criptogrficos sem o conhecimento de um outro cdigo.

(VFDODELOLGDGH SSL prov que novos mtodos de encriptao possam ser adicionados se necessrios. Isso se faz, para evitar a criao de um novo protocolo e o risco de ter que implementar uma nova biblioteca segura e com isso anular o risco de uma falha.

(ILFLrQFLDOperaes criptogrficas tendem a usar intensivamente a CPU e particularmente operadores de chave pblica. Por essa razo, o SSL tem incorporado um esquema de cach de sesso para reduzir o nmero de conexes que necessitam serem estabilizadas desde o comeo. Alm 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 Aplicao da arquitetura TCP/IP, posicionada entre esta e a camada de Transporte (vide figura 1). Dados especficos enviados por aplicativos que utilizam SSL so protegidos por tcnicas de criptografia e autenticao, garantindo a integridade e a privacidade dos mesmos. A estrutura do quadro transmitido pode ser observada na figura 2.

)LJXUD&DPDGD66/

8

)LJXUD)RUPDWRGHXPTXDGURFRP66/

Uma vez que este protocolo garante a integridade dos dados enviados, necessrio que seja utilizado um protocolo de transporte confivel orientado a conexo, como o TCP, a fim de garantir que no haja erros de transmisso.

O SSL fornece um servio de comunicao segura entre cliente e servidor, permitindo autenticao mtua 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 seleo dos algoritmos mais convenientes para cada situao, assim como a utilizao de novos algoritmos, a medida em que estes vo evoluindo. Estas escolhas so negociadas entre o cliente e o servidor durante o estabelecimento de uma sesso.

O termo VRFNHWV 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.

&RPRIXQFLRQDRVHUYLGRUFRPSDUWLOKDGR66/existe uma cpia do software SSL rodando no servidor principal, acrescentado o domnio no arquivo de configurao como um domnio adicional.

&RPR IXQFLRQD R 66/ SDUD XP VHUYLGRU GHGLFDGR 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.

6HJXUDQoD

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.

9

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.

Dados protegidos por SSL so sempre transmitidos em um formato que incorpora um FKHFNVXP criptogrfico, e um identificador de segurana. Quando dois KRVWV iniciam uma sesso utilizando SSL, as mensagens iniciais utilizam um protocolo de KDQGVKDNH 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.

$V9DQWDJHQVGR66/

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.

2SURWRFROR2SHQ66/

O projeto OpenSSL disponibiliza um WRRONLW 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

10

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 RSHQ VRXUFH 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 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 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 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 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.

23URWRFROR7/6

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 KHOOR 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 ira 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 ()HGHUDO,QIRUPDWLRQ3URFHVV6WDQGDUG).

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.

11

+773VYVV+773

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.

HTTPs a utilizao do protocolo HTTP (+\SHU7H[W 7UDQVIHU 3URWRFRO) em conjunto com o protocolo SSL (6HFXUH6RFNHWV/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 segurana entre a camada de transporte (TCP) e os protocolos de aplicao tais como HTTP, TELNET, FTP, NNTP, SMTP, etc. Este protocolo prov encriptao de dados, autenticao de servidor, integridade de mensagem e, opcionalmente, autenticao de cliente para uma conexo TCP/IP.

O sHTTP (secure HTTP) uma extenso do protocolo http proposta pelo EIT no comeo de 1994 que prov transaes seguras pela incorporao de criptografia, mecanismos de autenticao no protocolo HTTP permitindo transaes seguras fim-a-fim entre cliente e servidor WWW.

SSL e sHTTP tem diferentes motivaes: as camadas de segurana SSL ficam sob os protocolos de aplicao, como HTTP, NNTP e TELNET, enquanto que HTTPs adiciona segurana baseada nas mensagens especificamente do protocolo HTTP no nvel da aplicao. Estas duas aplicaes, longe de serem mutuamente exclusivas podem coexistir perfeitamente de forma complementar com o protocolo HTTPs atuando sobre a camada SSL.

$OJRULWPRVXWLOL]DGRVSHOR66/

Existem quatro grupos que podem representar o conjunto de algoritmos criptogrficos utilizados pelo protocolo SSL. So estes:

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

$OJRULWPRV DVVLPpWULFRV H GH GHULYDomRGH FKDYHValgoritmos utilizados para a troca de chaves e para o processo de assinatura digital. Neste grupo esto o RSA, o DAS (somente assinatura) e o Diffie-Hellman (derivao de chaves).

$OJRULWPRV GH KDVK usados para prover a integridade das mensagens enviadas e no processo de criao dos segredos. So especificados o MD5 e o SHA.

12

$OJRULWPRV GH FRPSDFWDomR na atual verso do SSL no h nenhuma especificao para funes de compactao.

Estes algoritmos so escolhidos no protocolo atravs do uso das ciphersuites. As ciphersuites so combinaes dos algoritmos listados acima e possui 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;

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 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 ciphersuites de exportao, as quais possuem alm dos componentes citados acima, tambm a componente _EXPORT_ antes do WITH, sinalizando que os algoritmos usados nesta ciphersuite sofrem as limitaes impostas pelo governo americano para algoritmos criptogrficos. 3URWRFROR&KDQJH&LSKHU6SHF

O Change CipherSpec um dos protocolos sobre os quais o SSL construdo, com o objetivo de sinalizar transaes entre estratgias de cifragem usadas na sesso.

O protocolo Change CipherSpec o mais simples dos trs protocolos especficos 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 propsito exclusivo desta mensagem fazer a cpia do estado pendente no estado atual, o qual atualiza o Cipher Suite a ser usado nesta conexo, ou seja, estabelece concordncia no Cipher Suite da sesso.

O Cipher Suite consiste em quais mtodos sero usados para troca de chaves (Key Exchanges), transferncia de dados e criao de cdigo de autenticao de mensagem (Message Authentication Code - MAC).

13

Este protocolo usado quando o handshake termina e a transferncia de dados est preste a comear. Tambm pode ser usado quando os pares querem trocar a especificao Cipher a ser usada, isto bom quando muito tempo se passou com o mesmo canal seguro aberto.

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

Em resumo, este protocolo sinaliza as transies nas estratgias de cifragem. Constitui-se de uma nica mensagem que pode ser transmitida tanto pelo cliente como pelo servidor para notificar que os prximos blocos utilizaro chaves de encriptao recm negociadas.

3URWRFROR$OHUWEste protocolo usado para comunicar entidade par os alertas relacionados ao

SSL. Assim como outras aplicaes que usam o SSL, mensagens so 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 seqncia de mensagens, erros de certificao ou encriptao.

Cada mensagem neste protocolo consiste de dois bytes. O primeiro assume o valor de ateno (1) ou fatal (2) para exprimir a severidade da mensagem. Se o nvel de severidade da mensagem fatal, o SSL termina a conexo imediatamente. Outras conexes na mesma sesso podem continuar, mas nenhuma nova conexo nesta sesso pode ser estabelecida.

O segundo byte contm um cdigo que indica o alerta especfico.

Abaixo esto listados os alertas que so sempre fatais pela especificao do SSL:

0HQVDJHPBLQHVSHUDGDXQH[SHFWHGBPHVVDJH uma mensagem imprpria foi recebida; 0$&BPDXBJUDYDGREDGBUHFRUGBPDF um MAC incorreto foi recebido; )DOKDBQDBGHVFRPSUHVVmR GHFRPSUHVVLRQBIDLOXUH a funo responsvel pela descompresso recebeu uma entrada imprpria. Por exemplo: o resultado da descompresso seria maior do que o tamanho mximo permitido;

14

)DOKDBQRBKDQGVKDNH KDQGVKDNHBIDLOXUH o remetente no capaz de negociar um conjunto aceitvel de parmetros de segurana fornecendo as opes disponveis;

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

Os tipos de alertas restantes so:

1RWLILFDomRBIHFKDPHQWR FORVHBQRWLI\ informa o recebedor da mensagem que o remetente no ir enviar mais nenhuma mensagem na conexo. Cada parte requisitada a enviar um alerta notificao_fechamento antes de fechar o lado de escrita de uma conexo;

1HQKXPBFHUWLILFDGR QRBFHUWLILFDWH pode ser enviado em resposta a uma requisio certificada se nenhum certificado apropriado est disponvel;

0DXBFHUWLILFDGR EDGBFHUWLILFDWH um certificado recebido est corrompido, por exemplo: contm uma assinatura que no reconhecida;

&HUWLILFDGRBQmRBVXSRUWDGR XQVXSSRUWHGBFHUWLILFDWH o tipo de certificado recebido no suportado;

&HUWLILFDGRBUHYRJDGR FHUWLILFDWHBUHYRNHG um certificado foi revogado por seu assinante;

&HUWLILFDGRBH[SLUDGRFHUWLILFDWHBH[SLUHG um certificado expirou; &HUWLILFDGRBGHVFRQKHFLGR FHUWLILFDWHBXQNQRZ alguma outra aplicao tornou o certificado inaceitvel.

O protocolo Alert usado quando algum par da comunicao quer fechar a conexo ou se um dos pares detectou algum erro na transferncia, na autorizao ou algo parecido.

3URWRFROR66/+DQGVKDNHO 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 parte, so feitos 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 seguem o formato da figura abaixo, onde:

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

15

7DPDQKR tamanho do corpo em bytes (3 bytes); &RUSR so os dados da mensagem sendo enviada (maior ou igual a 1 byte).

)RUPDWRGDPHQVDJHPGRSURWRFROR+DQGVKDNHO processo de handshake pode ser realizado de diferentes formas dependendo se

h autenticao ou no das partes envolvidas e/ou se uma sesso retomada. A figura que segue mostra uma possvel execuo do processo de handshake. As mensagens trocadas esto descritas na seqncia.

([HFXomRGRSURFHVVRKDQGVKDNH1) 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).

2) Servidor retorna seu nmero aleatrio e a cifra e mtodo selecionados (mensagem SERVER_HELLO).

3) Caso o servidor deva se autenticar (condio j sabida a partir da ciphersuite negociada), este envia seu certificado, o qual conter sua chave pblica (SERVER_CERTIFICATE). O tipo de certificado enviado depender da FLSKHUVXLWH negociada.

4) Caso seja necessria 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).

16

5) Cliente ento responde ao servidor, enviando seu certificado (mensagem CLIENT_CERTIFICATE).

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

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

8) 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, e assim, o processo de handshake finalizado.

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

)DVH(VWDEHOHFLPHQWRGDV&DSDFLGDGHVGH6HJXUDQoD )DVH$XWHQWLFDomRGRVHUYLGRUH7URFDGHFKDYH )DVH$XWHQWLFDomRGRFOLHQWHH7URFDGH&KDYH )DVH)LQDOL]DomR O objetivo da primeira fase iniciar uma conexo lgica e estabelecer as

capacidades de segurana que sero associadas a ela. Caracteriza-se pela troca de mensagens do tipo hello, client_hello e server_hello, com os seguintes parmetros:

9HUVLRQ: a mais alta verso SSL entendida pelo cliente; 5DQGRP: uma estrutura aleatria gerada pelo cliente. Esta estrutura deve ser diferente na mensagem do cliente e do servidor;

6HVVLRQ,': um identificador de sesso de tamanho varivel. Um nmero diferente de zero indica que o cliente deseja atualizar os parmetros de uma conexo existente ou criar uma conexo nova nesta sesso. Um valor zero indica que o cliente deseja estabelecer uma nova conexo em uma nova conexo;

&LSKHU6XLWHeste uma lista que contm as combinaes de algoritmos criptogrficos suportados pelo cliente, em ordem decrescente de preferncia. Cada elemento da lista define tanto um algoritmo de troca de chaves um CipherSpec;

0pWRGRGH&RPSUHVVmR: uma lista dos mtodos de compresso 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 ento um erro fatal ir acontecer e a conexo ir falhar. Estas mensagens, FOLHQWBKHOOR e VHUYHUBKHOOR, so usadas para se estabelecer capacidades de segurana maiores entre o cliente e o servidor.

As duas mensagens estabelecem os seguintes atributos: verso do protocolo, sessionID, CipherSuite e mtodo de compresso. Adicionalmente, dois valores randmicos so gerados e trocados: ClientHello.random e ServerHello.random. Aps 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 no ter um certificado ou se seu certificado somente para sinalizao. Se o servidor for autenticado, ele pode requisitar um certificado do cliente, se isto for conveniente ao CipherSuite selecionado.

Ento, 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, ento, 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 contedo desta mensagem ir depender no algoritmo de chave pblica selecionado entre as mensagens client_hello e server_hello. Se o cliente enviou um certificado com habilidade de sinalizao, 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 ento, envia imediatamente a mensagem finished, iniciando a quarta fase, sobre os novos algoritmos, chaves, e segredos. Em resposta, o servidor enviar sua prpria 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 comear a trocar dados da camada de aplicao.

Quando o cliente e o servidor decidem continuar uma sesso prvia ou duplicar uma sesso existente temos o seguinte fluxo de mensagens:

O cliente envia uma mensagem client_hello usando o SessionID da sesso a ser retomada. O servidor, ento, verifica sua cache de sesso por algo correspondente. Se encontrar, e o servidor est disposto a restabelecer a conexo sobre o estado especfico da sesso, 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 comear a trocar dados da camada de aplicao.

Dentre as trocas de mensagens explicadas acima so realizadas uma srie de aes, que so explicadas na seqncia.

0HQVDJHQVGH+HOOR

As Mensagens de Hello so usadas para trocar capacidades de segurana entre o cliente e o usurio.

+HOOR5HTXHVW

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.

&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 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 abaixo:

)RUPDWRGDPHQVDJHP&/,(17(B+(//26HUYHU+HOOR

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

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

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. 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 abaixo:

)RUPDWRGDPHQVDJHP6(59(5B+(//26HUYHU&HUWLILFDWH

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

6HUYHU.H\([FKDQJH

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 cujos dados pblicos usados para a troca de chave possuem um tamanho superior ao estipulado pela ciphersuite 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 especificadas na ciphersuite selecionada. No caso de uma ciphersuite no annima, ou seja, uma ciphersuite que possui um algoritmo para assinatura, os valores pblicos enviados nesta mensagem so assinados.

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

20

7URFDGHFKDYHHDVVLQDWXUDXVDQGR56$

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; 3. Os resultados dos dois hashs so assinados usando a chave-privada RSA do servidor.

7URFDGHFKDYHV'LIILH+HOOPDQHDVVLQDWXUDXVDQGR56$

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

7URFDGHFKDYHV'LIILH+HOOPDQDQ{QLPR

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

&HUWLILFDWH5HTXHVW

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

21

)RUPDWRGHPHQVDJHP&(57,),&$7(B5(48(676HUYHU+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 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.

&OLHQW&HUWLILFDWH

Esta mensagem enviada pelo cliente, em resposta a CERTIFICATE_REQUEST, com a funo de autentic-lo. O contedo 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.

&OLHQW.H\([FKDQJH

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 PreMasterSecret e seu valor dependente do algoritmo de troca de chave especificado na ciphersuite escolhida. Segue agora uma explicao de como a PreMasterSecret gerada.

7URFDGHFKDYHVXVDQGR56$Quando o RSA utilizado para a troca de chaves, a PreMasterSecret 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, veja figura:

7URFDGHFKDYHVXVDQGR56$

22

'HULYDomRGHFKDYHVXVDQGR'LIILH+HOOPDQNo 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 PreMasterSecret. 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 MasterSecret. A MasterSecret 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 MasterSecret calculada, a PreMasterSecret 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 MasterSecret. 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.

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

&HUWLILFDWH9HULI\

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.

)LQLVKHG

Esta a primeira mensagem no processo de handshake a ser enviada decifrada. Ela enviada imediatamente aps a mensagem de CHANGE_CIPHER_SPEC, tanto pelo

23

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, veja a figura:

)RUPDWRGDPHQVDJHP),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. Aps esta mensagem, a troca de mensagens de aplicao atravs do canal de cifra negociada pelo SSL liberada.

3URWRFROR66/5HFRUGA camada SSL Record encapsula vrios protocolos de alto nvel, e usa a definio

de estado corrente para, alm de outras coisas, selecionar os algoritmos de compresso e criptografia apropriados. O estado corrente determinado durante o processo de handshaking previamente descrito.

Ela age comprimindo os dados, usando o algoritmo de compresso selecionado no estado corrente. Todos os dados so 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 funo hash para assegurar a integridade dos dados.

Os processos descritos acima so reversveis na Camada Record, no outro lado do canal de comunicaes, onde os dados so decodificados, verificados, expandidos e reunidos antes de serem enviados para clientes em alto nvel.

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

A figura abaixo representa a interao do protocolo Record dentro da estrutura SSL.

24

(VWUXWXUD66/ ,QIUDHVWUXWXUDGH&KDYH3~EOLFD3XEOLF.H\,QIUDVWUXFWXUH3.,

Atualmente, quase que na maioria dos portais web na Internet que oferecem algum tipo de servio on-line ou produtos etc., esto de alguma forma utilizando a Infra-estrutura de Chave Pblica (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 segurana. Implementaes dos protocolos SSL e ate do IPSec geralmente utilizam o PKI para aumentar o grau de segurana nas transaes on-line, porm no h uma necessidade que os protocolos (SSL, IPSec) trabalhem em conjunto com o PKI. A implantao do PKI em conjunto com o SSL ou IPSec fica a critrio do implementador e conforme as necessidades de negcios de cada empresa.

Uma Infra-estrutura de Chave Pblica tem o objetivo de fornecer e definir regras tcnicas para instituies pblicas e privadas com relao s transaes de troca de documentos transmitidos e obtidos eletronicamente. Essas regras tcnicas sero utilizadas como mecanismos de validao jurdica com o propsito de garantir a autenticidade e integridade dos documentos em formatos eletrnicos. Um dos mecanismos de validao do PKI se chama Certificado, que uma espcie de selo eletrnico fornecido por Autoridades Certificadoras CA definido pela norma X.509v3 (RFC 2459) que a mais atual.

Empresas que praticam negcios on-line e que implementam o protocolo SSL em conjunto com o PKI, de tal forma proporcionam mais segurana ao cliente que acessa seu portal on-line. 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.

A norma ou formato X.509 que define o certificado teve sua primeira verso publicada em 1988, a segunda verso saiu em 1993 aps reviso da primeira verso. A terceira e ltima verso do X.509 foram publicadas em 1997 que resultou na norma X.509v3 e que define os certificados emitidos por CA atualmente.

25

2EV2SURWRFROR66/6HFXUH6RFNHW/D\HUSURSRUFLRQRXRSULPHLURFRQWDWRDR3.,$WXDOPHQWH R 3., HVWD VHQGR PXLWR GLVVHPLQDGD DWUDYpV GH LPSOHPHQWDo}HV 931VEDVHDGDVQRSURWRFROR,36HFHQHJyFLRVRQOLQHEDVHDGRVQRSURWRFRORKWWSKWWSV KWWSVVO

$XWRULGDGH&HUWLILFDGRUD&HUWLILFDWLRQ$XWKRULW\&$ 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 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.

Atribuies da Autoridade Certificadora: fonte - livro VPN, Lino Sarlo da Silva.

Manter a mais Rgida Segurana possvel para chave privada CA. Assegurar que seu prprio certificado seja amplamente distribudo. Emisso de Certificados. Revogao de Certificados. Emisso de Lista de Certificados Revogados. Publicao de Lista de Certificados Revogados. Disponibilizar a situao do certificado quando requerida. Gerencia de chaves criptogrficas. Publicao de suas regras operacionais Fiscalizao do cumprimento desta poltica pelos usurios.

Obs. 1R%UDVLOWHPRVR,&3%UDVLO,QIUDHVWUXWXUDGH&KDYH3XEOLFD%UDVLOHLUDLPSOHPHQWDGDV SRU LQVWLWXLo}HV S~EOLFDV H SULYDGDV EUDVLOHLUDV 6(5$6$ &$,;$6(5352 81,&(57 HWF $V $XWRULGDGHV &HUWLILFDGRUDV &$ TXH DLQGD QmR HVWmRYLQFXODGDV D ,&3%UDVLO SRGHP HPLWLU FHUWLILFDGRV GLJLWDLV SRUpP QmR WHUmRHPEDVDPHQWR QDV OHLV EUDVLOHLUDV 2 ,7, ,QVWLWXWR 1DFLRQDO GH 7HFQRORJLD GD,QIRUPDomRpD$XWRULGDGH&HUWLILFDGRUD5DL]GD,&3%UDVLOFRQIRUPH'HFUHWRGH

26

&HUWLILFDGR'LJLWDO

A certificao digital foi maneira encontrada para prover servios de identificao, autenticao e privacidade para transaes eletrnicas. Talvez ficaria mais fcil o entendimento se fizermos uma comparao com os mecanismos e servios tradicionais de identificao, autenticao e privacidade que estamos acostumados a utilizar. Por exemplo, em transaes fsicas do tipo autenticao de documentos, os desafios de identificao, autenticao e privacidade so resolvidos com marcas fsicas, tais como selos e assinaturas providas por uma entidade que confiamos (ex. cartrio). No entanto, nos casos de transaes eletrnicas, tipo compras on-line, envio de documentos eletrnicos, e-mail etc., o equivalente ao mecanismo tradicional seria o selo ou certificado digital que vem codificado na prpria informao e que 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.

Uma vez que o documento recebeu um certificado digital, sua alterao fica quase que impossvel de no ser detectada. Uma violao de um documento certificado digitalmente seria facilmente identificada atravs dos mecanismos e algoritmos de criptografia utilizados para prover as funcionalidades de identificao, autenticao e privacidade, mesmo que apenas 1 bit seja modificado no documento. Em resumo um certificado digital uma cadeia de bits que foi gerado atravs de algoritmos criptogrficos que teve como entrada as informaes que se desejava obter o certificado digital.

)RUPDWRGR&HUWLILFDGR'LJLWDO

'LDJUDPDVLPSOHVGHXPFHUWLILFDGRGLJLWDO;YQmRLQFOXLQGRDVH[WHQV}HVYVWDQGDUG,QIRUPDomREiVLFD )RUPDWRGRFHUWLILFDGR Verso 3 1GH6pULHGRFHUWLILFDGR 123456789 ,GHQWLILFDGRUGRDOJRULWPRGHDVVLQDWXUDGD(& RSA com MD5 (QGHUHoR;GRHPLVVRU C=PT, o=EC 3HUtRGRGHYDOLGDGH Start=01/08/96,

expiry=01/08/98

1RPH;GRXWLOL]DGRU c=PT,o=organizao,cn=Joo Silva + .....

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

([WHQV}HV9

Tipo Criticidade Valor Morada, bit off/no crtico, Rua das Codornizes 183 Tipo Criticidade Valor mbito, bit on/crtico, Vlido somente para Assinatura Digital

27

Tipo Criticidade Valor Nvel de acesso,bit off/no crtico, 1- geral Tipo Criticidade Valor ......

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

,PDJHPGHXPFHUWLILFDGR'LJLWDO

Esse um formato tpico de um certificado digital que recebemos diariamente quando efetuamos uma conexo http(ssl) segura. 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.

,PDJHPGHXP6HFXULW\:DUQLQJ Essa mensagem de Security Warning vai aparecer para o usurio somente nos casos em que o certificado digital recebido no pode ser autenticado pelas CAs j

28

cadastradas no browser do usurio. Podemos observar que essa mensagem de Security Warning da a opo de aceitar ou rejeitar o certificado (yes ou no) recebido. A regra no aceitar certificados que no seja autenticado pelos CA ja cadastrados no browser do usurio.

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.

$SOLFDo}HVTXHXWLOL]DP&HUWLILFDGRV'LJLWDLV

$SOLFDo}HV EDQFiULDVA grande maioria dos bancos utiliza certificados digitais para proporcionar maior segurana 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 tambm fornece a opo do cliente obter um certificado digital gratuito com validade de um ano. Quando o cliente tambm emite um certificado o nvel de segurana nas transaes aumenta ainda mais.

$FHVVRUHPRWRGHIXQFLRQiULRVGHXPDRUJDQL]DomRFuncionrios de uma determinada empresa (vendedores, consultores, diretores etc.) podem se logar remotamente utilizando mecanismos como SecurityID ou token que possibilita a certificao dos mesmos junto ao servidor acessado. Isso possibilita acesso a

29

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

9HQGDV2QOLQHA grande maioria dos portais web j utiliza certificados digitais para autenticarem seus servidores na hora de efetuarem transaes que envolvem envio de dados confidenciais do tipo Nr. de cartes de crditos. Podemos citar como exemplo o site da www.submarino.com.br que utiliza SSL com certificao digital dos seus servidores nas transaes que envolve envio de dados confidenciais.

$FHVVR UHPRWR YLD 931,36HF J esta se tornando uma realidade funcionrios de determinadas empresas e ramo de negcios trabalharem em casa via conexo VPN baseadas em 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.

Enfim, essas so apenas algumas das aplicaes que utilizam certificados digitais. Nos ltimos anos os certificados digitais vm ganhando fora no mercado virtual denominado Internet. Da mesma forma que as transaes on-line crescem na Internet os certificados digitais tambm vo ganhando seu espao. Certificao digital provavelmente foi maneira mais fcil encontrada pelas organizaes que praticam negcios on-line em aumentar o grau de segurana em suas transaes proporcionando ao usurio final uma sensao de sigilo absoluto.

([HPSORVGHHPSUHVDVTXHXWLOL]DPRSURWRFROR66/

A UPS uma grande transportadora expressa de documentos e encomendas, presente em 200 pases e territrios independentes em todo o mundo. Para permitir a entrega segura de documentos particulares atravs da Internet, a empresa lanou, o servio 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 no mais de um dia para o outro. Isso permite decises comerciais melhores e mais rpidas. Os clientes comerciais, agora, podem ter certeza de que os documentos eletrnicos enviados pela UPS sero entregues ao destinatrio pretendido, intactos e inalterados.

A Verisign Incorporation, fez um acordo para disponibilizar seu servio Payflow para os comerciantes on-line da American Express Company. O acordo com a empresa de carto de crdito permitir que os comerciantes autorizem e efetuem transaes

30

diretamente com ela, em tempo real, sem ter que pagar a tarifa por transao. O Payflow o nico servio de pagamento que no cobra juros e est disponvel para os comerciantes on-line. A capacidade do Payflow, para processar transaes em tempo real, permite que a autorizao seja mais rpida que a dos processadores que enviam o pagamento para a American Express, em lotes, de poucos em poucos minutos.

$WDTXHVGRFXPHQWDGRV0DQLQWKHPLGGOH0,70

1RFDVRGH0DQLQWKH0LGGOHHPFRQH[}HV66/

Mesmo as conexes protegidas pelo protocolo SSL esto sujeitas a ataques Man in the Middle. Vamos descrever passo a passo como seria possvel o ataque Man in the Middle em conexes SSL.

%URZVHU Solicita uma conexo SSL no servidor desejado &UDFNHU (intercepta a solicitao de conexo SSL) E Solicita uma conexo SSL ao 6HUYLGRU:HE

6HUYLGRU:HE Envia a chave pblica para o usurio , que passa a ter o Cracker como intermedirio &UDFNHU(intermedirio da conexo) Envia outra chave (gerada por ele) para o &OLHQWHRX%URZVHU

&OLHQWH

&OLHQWH,QWHUQHW3URYLGHU

'16

(PSUHVDp5HVSRQViYHOSHOD6HJXUDQoD

)LUHZDOO6073SUR[\ )LUHZDOO

,QWHUQHW5HGH3XEOLFD

&OLHQWHp5HVSRQViYHOSHOD6HJXUDQoD

!

UHDGHDWXDomR0,70&UDFNHU

2FUDFNHUXWLOL]DQGRDWpFQLFD0,70DWWDFNGHVYLDRWUDIHJRGRFOLHQWHHSDVVDDID]HUSDUWHGDFRQYHUVDVHPGHL[DUQHQKXPUDVWURGHLQWUXVmR

31

No caso de uma conexo SSL, o servidor web envia para o cliente a sua chave pblica, 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 usurio deve prestar muita ateno nos alertas de segurana que podem vir a aparecer, veja exemplo de mensagem Security Warning demonstrada acima.

Quando efetuada uma conexo SSL, alguns itens so verificados pelo Browser (Cliente) quando o mesmo recebe a chave pblica 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 questo IRL HPLWLGR SRU XPD $XWRULGDGH&HUWLILFDGRUDGH&RQILDQoD etc.

Caso algum destes itens tenha algum problema, o navegador web (browser) ir apresentar para o usurio um alerta de segurana onde no mesmo ser descrito o problema e com a opo do usurio aceitar ou no a conexo SSL. recomendado que a mesma no seja aceita e que este usurio entre em contato com a respectiva empresa.

Obs. Browsers de verses antigas no verificavam o URL contido no certificado para confrontar com o URL desejado, o que ocasionava uma facilidade para o mtodo de ataque man-in-the-middle. As verses mais recentes dos browsers j fazem esse tipo de verificao apontando os problemas no formato de (Security Warning) para o usurio tomar a deciso.

0pWRGRVGH3UHYHQomRSDUDR0DQLQWKHPLGGOH

3UHYHQomRSRUSDUWHGDFRUSRUDomR Adio de uma outra camada de criptografia para as 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).

3UHYHQomRSRUSDUWHGR8VXiULR Nunca aceitar conexes com problemas de certificao (Ou seja, verificar atentamente os alertas de segurana que o browser pode reportar). 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.

32

3UHRFXSDo}HVFDXVDGDVSHORXVRGRSURWRFROR66/

Recentemente as empresas comearam a ficar preocupadas com o crescente trfego de conexes SSL em suas redes. Isso se deve ao fato de que uma conexo protegida pelo protocolo SSL no sofre qualquer tipo de filtragem pelo firewall ou roteador na entrada ou na sada de uma rede, isso ocorre devido ao contedo estar criptografado. A preocupao com relao a isso est no sentido de que tais transaes SSL podem estar trazendo para dentro da rede vrus, trojans, contedo pornogrfico ou at mesmo documentos sigilosos da empresa podem estar sendo enviados para fora em formato criptografado.

S para despertar interesse nos aficcionados por segurana, em Agosto/2003 uma empresa lanou um produto que faz a filtragem de conexes criptografadas SSL, ou seja, a famosa tcnica Man-in-the-middle virou produto comercial com alguns detalhes mais sofisticados. Aqueles que esto interessados em aprender mais sobre o assunto, visitem a pgina do fabricante do produto Webwasher (www.webwasher.com). O produto nem bem foi lanado e j comea a causar polmica devido a quebra de sigilo que o mesmo proporcionar.

)HUUDPHQWDV GH DX[LOLR SDUD DQiOLVH H HQWHQGLPHQWR GRSURWRFROR66/

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 trs informaes bem detalhadas dos processos efetuados pelo SSL em suas implementaes. Mas para aqueles que ainda acham necessrio uma ferramenta de auxilio para o entendimento dos mecanismos do protocolo SSL, no sero desapontados. Aps 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 trfego SSL em detalhes. Esse seria uma verso do TCPdump para o SSL.

NewPKI - http://www.newpki.org/ ou http://www.freeicp.org/

Ferramenta para linux que proporciona uma instalao 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 tambm por SSLSniff.

SSLScanner www.webwasher.com

Ferramenta comercial que filtra conexes 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 polmica com relao a quebra de sigilo.

Em resumo essas so apenas algumas ferramentas fundamentais para analisar e entender o funcionamento do protocolo SSL em detalhes. As ferramentas Crypto, SSLdump e Squid merecem uma ateno especial.

&RQFOXVmR

Percebemos que a troca de informaes sigilosas atravs das transaes on-line (ex. Internet Banking, compras on-line etc.) sem dvida j fazem parte do nosso dia-a-dia. Esse o mundo virtual dos negcios conhecido como e-business que cresce quase que na mesma proporo que os crimes virtuais.

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. No entanto, esses protocolos implementados puramente; ou seja, simplesmente sem utilizar chaves pblicas e privadas (PKI) j no esto oferecendo um grau aceitvel de segurana. Neste caso empresas que efetuam transaes sigilosas on-line j esto utilizando Certificao Digital atravs de PKI (chaves pblicas e privadas), CA etc., bem como solues integradas com PKI como SmartCard, SecurityID, Token que podem serem implementados conforme necessidade e grau de segurana que se quer alcanar.

Podemos assim concluir que simplesmente uma implantao pura de um protocolo para prover sigilo no resolveria a questo de segurana, e sim acrescentaria uma camada extra de segurana para evitar o crime virtual. No entanto, uma implantao com varias camada extras de segurana como chaves pblica (PKI), SmarCard, dentre outros, aumentaria significativamente o grau de confiabilidade; porm, no estaria 100% segura visto que teoricamente no existe soluo que prov 100% de segurana.

34

%LEOLRJUDILDVHUHIHUrQFLDV

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

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.