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

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

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 

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.

,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

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.

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.

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/

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

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

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.

10

+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 GHULYDomR GH FKDYHV algoritmos 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.

11


$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
especificao o valor SSL; KE o algoritmo de troca de chaves;

na

atual

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

12

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$OHUW

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

13

)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/+DQGVKDNH

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

fases. Na primeira, feita a escolha da chave entre o cliente e o servidor, a autenticao
do servidor e a troca da chave Master. J na segunda 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);

14

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

&RUSR so os dados da mensagem sendo enviada (maior ou igual a 1 byte).

)RUPDWRGDPHQVDJHPGRSURWRFROR+DQGVKDNH
O processo de handshake pode ser realizado de diferentes formas dependendo se
h autenticao ou no das partes envolvidas e/ou se uma sesso retomada. A figura que
segue mostra uma possvel execuo do processo de handshake. As mensagens trocadas
esto descritas na seqncia.

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

15

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

Para melhor entendimento, estas trocas podem ser interpretadas tendo quatro

)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;
&LSKHU6XLWH este 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.

16

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

17

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+(//2
6HUYHU+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

18

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+(//2

6HUYHU&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:

19

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

20

)RUPDWRGHPHQVDJHP&(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 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$


21

'HULYDomRGHFKDYHVXVDQGR'LIILH+HOOPDQ
No processo de troca de chaves usando o Diffie-Hellman, o cliente envia para o
servidor o seu valor pblico e ambos executam o processo de derivao de chave. O valor
resultante deste processo a 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

22

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/5HFRUG

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

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

23

(VWUXWXUD66/

,QIUDHVWUXWXUDGH&KDYH3~EOLFD3XEOLF.H\,QIUDVWUXFWXUH
3.,

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

2EV 2 SURWRFROR 66/ 6HFXUH6RFNHW/D\HUSURSRUFLRQRX RSULPHLUR FRQWDWRDR 3.,

$WXDOPHQWH R 3., HVWD VHQGR PXLWR GLVVHPLQDGD DWUDYpV GH LPSOHPHQWDo}HV 931V
EDVHDGDVQRSURWRFROR,36HFHQHJyFLRVRQOLQHEDVHDGRVQRSURWRFRORKWWSKWWSV KWWS
VVO

$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%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pD$XWRULGDGH&HUWLILFDGRUD5DL]GD,&3%UDVLOFRQIRUPH'HFUHWRGH


25

&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}HVY
VWDQGDUG,QIRUPDomREiVLFD
)RUPDWRGRFHUWLILFDGR
1GH6pULHGRFHUWLILFDGR
,GHQWLILFDGRUGRDOJRULWPRGHDVVLQDWXUDGD(&
(QGHUHoR;GRHPLVVRU
3HUtRGRGHYDOLGDGH
1RPH;GRXWLOL]DGRU

Verso 3
123456789
RSA com MD5
C=PT, o=EC
Start=01/08/96,
expiry=01/08/98
c=PT,o=organizao,cn=Joo Silva +
.....

&KDYH S~EOLFD GR XWLOL]DGRU H PpWRGR

C.P.U. + RSA com MD5
FULSWRJUiILFRXWLOL]DGR
([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
26

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
27

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 EDQFiULDV A 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

28

Intranet/Extranet, base de dados, treinamento on-line com total confidencialidade

e segurana etc.

9HQGDV 2QOLQH A 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
29

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



(PSUHVDp
5HVSRQViYHOSHOD6HJXUDQoD

&OLHQWHp
5HVSRQViYHOSHOD6HJXUDQoD
UHDGHDWXDomR0,70
&UDFNHU

          

'16

   
&OLHQWH

&OLHQWH

,QWHUQHW
5HGH3XEOLFD


    !   




  

   

,QWHUQHW
3URYLGHU
2FUDFNHUXWLOL]DQGRDWpFQLFD
0,70DWWDFNGHVYLDRWUDIHJRGR
FOLHQWHHSDVVDDID]HUSDUWH
GDFRQYHUVDVHPGHL[DUQHQKXP
UDVWURGHLQWUXVmR

)LUHZDOO
6073SUR[\

)LUHZDOO





  

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

30

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.

31

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 GR

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

32

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

33

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

ml, novembro de 2003.

http://www.cic.unb.br/docentes/pedro/trabs/hammurabi.htm, novembro de
2003.

34