Transações Seguras via Web

Gorgonio Araújo <gorgonio@pop-ba.rnp.br>

Rede Nacional de Ensino e Pesquisa (RNP)

Introdução
O Arcabouço
O Secure Sockets Layer
Certificações: os cartórios eletrônicos
O Apache com SSL
Conclusão
Referências

Neste artigo, é abordado o uso da SSL (Secure Sockets Layer) como solução para possibilitar o oferecimento de serviços à base de transações seguras via Web. Desta forma, faz-se uma introdução às técnicas de criptografia, descreve-se superficialmente a SSL e exemplifica-se a instalação de um servidor Web seguro, utilizando o Apache-SSL para tal.

Introdução

Quando, ao final da década de 80, Tim Berners-Lee propôs a criação, no CERN, de um sistema de informações baseado em hipertexto, não se imaginava o sucesso que a Web atingiria, nem tampouco havia maiores preocupações com segurança do serviço ([Berners89]).

Garota prodígio, a Web rapidamente atingiu a adolecência e agora busca assumir maiores responsabilidades, como tornar-se o meio para realização de comércio eletrônico, permitir o acesso a informações privilegiadas e possibilitar a operação remota de serviços que exigem uma certa segurança. Na sua forma original, ela não é indicada para ser utilizada para compras remotas ou home banking, pois baseia-se numa pilha de protocolos ( HTTP / TCP / IP ) onde, em nenhum momento, há uma preocupação com autenticidade ou privacidade dos dados. Problema sério, especialmente numa rede pública nos moldes da Internet, tinha que ser resolvido de alguma forma. Assim, muitas soluções foram e estão sendo apresentadas como, dentre outras, o SSL , a TLS , a IPsec , a SET .

A SSL foi uma solução apresentada pela Netscape que tornou-se um padrão de fato, sendo incorporado nos mais populares browsers e servidores Web e, atualmente, encontra-se em processo de padronização pela IETF , com o nome de TLS. Estas duas soluções apresentam-se como uma camada intermediária entre a de transporte e a de aplicação.

Uma outra solução para o problema de segurança é esperado com a implementação do IPsec, que, de forma análoga à SSL, porém numa camada inferior, implementa um canal seguro a nível de IP. O IPsec é parte integrande da próxima versão do IP ([Santos97]).

Como uma solução específica para transações comerciais a Visa e a MasterCard, em conjunto com outros eminentes parceiros, propõem a SET. O protocolo SET busca proteger e garantir a realização do comércio eletrônico, dando uma solução inteligente especificamente para o tráfego de cifras e autorizações de crédito/débito bancários.

Este artigo é voltado para o leitor não especialista em segurança eletrônica e interessado numa visão geral da tecnologia. Na seção "Arcabouço," apresenta-se uma introdução às técnicas básicas de criptografia. A seção "A Secure Sockets Layer" é dedicada à introdução da SSL. Na seção "Certificações, os Cartórios Eletrônicos" discutem-se aspectos sobre a criação e certificação de chaves SSL. Em "O Apache com SSL" ilustra-se o uso da solução com um servidor Web. Esta seção é voltada para o administrador de sistemas UNIX, experiente na instalação e configuração do Apache, interessado no processo de instalação de um servidor Web seguro. Finalmente, apresentam-se as "Conclusões" deste artigo.

O Arcabouço

O problema aqui enquadra-se em um modelo simples onde temos um transmissor enviando uma mensagem para um receptor através de uma canal supostamente inseguro. Para garantir que a mensagem é transmitida com segurança, ela é cifrada antes de chegar no canal, transmitida e então decifrada no receptor. A técnica de cifragem e decifragem é chamada de criptografia. A figura abaixo ilustra o funcionamento desta técnica. Antes de se entender como a criptografia funciona, é feita a definição do que ela nos oferece, isto é, do que significa segurança.

O conceito de segurança é muito mais amplo do que o adotado aqui. Neste contexto, seguraça significa privacidade, integridade e autenticidade do emissor. Privacidade é a garantia de que a mensagem não será entendida por um intruso que, de alguma forma, consiga lê-la no canal. Integridade é a garantia de que a mensagem não foi modificada por um eventual intruso ativo durante a transmissão. E, finalmente, autenticidade do emissor é a garantia de que o emissor da mensagem é realmente quem diz ser.

Como a criptografia funciona? A idéia, bastante simples, já é utilizada mesmo por crianças. Quando uma dessas diz para a sua irmãzinha "va-pa-mos-pos rou-pou-bar-par ba-pa-las-pas da-pa bol-pol-sa-pa de-pe mi-pi-nha-pha mãe-pãe?" na língua do "pê", ela está codificando uma frase utilizando um código supostamente conhecido apenas pelo emissor e o receptor. O destinatário aplica o código invertido para obter a mensagem original. Do simplificado código infantil, até os mais eficientes e sofisticados códigos atuais de criptografia, todos utilizam alguma forma de substituição ou transposição de caracteres ou grupos de caracteres.

A título de ilustração do uso da substitução, vamos cifrar a frase

o tesouro esta enterrado ao pe da jaqueira

chave: a b c d e f g h i j k l m n o p q r s t u v w x y z
       z y x w v u t s r q p o n m l k j i h g f e d c b a

substituindo "a" por "z", "b" por "y" e assim sucessivamente, o resultado seria:

l gvhlfil vhgz vmgviizwl zl kv wz qzjfvriia

Para decifrar a mensagem o destinatário precisará apenas saber qual foi a chave utilizada. Note que, neste simples exemplo, com apenas 26 caracteres utilizados temos uma imensa quantidade de chaves possíveis, dificultando a tarefa de quem tentar quebrar o código, através da descoberta da chave utilizada, pelo método da advinhação (tentativa e erro).

Um técnica mais elaborada é a transposição. Ilustra-se aqui a cifragem da mesma frase anterior utilizando transposição. A título de exemplo, será utilizada como chave a própria palavra "chave", que não tem nenhuma letra repetida. Alinhamos a frase original de tal forma a abrigar em cada linha a mesma quantidade de caracteres da palavra anterior. Assim teremos:

chave
-----
o tes
ouro 
esta 
enter
rado 
ao pe
da ja
queir
a

Envia-se, então, a mensagem coluna a coluna, iniciando pela coluna a, depois, c, depois e, h e por fim v (ordem alfabética). O resultado seria:

trttd  e ooeeradqas  r ear  usnaoau eoaeopji

No destino, sabendo qual a chave, o receptor apenas deverá fazer o processo inverso e buscar o seu tesouro. É interessante imaginar como adivinhar qual a frase original sem saber qual a chave.

Os algoritmos criptográficos utilizam, em geral, uma série de combinações de substituições e transposições, e sua eficiência é tão maior quando mais difícil for decifrá-lo sem o conhecimento da chave. Outro fator que dificulta a quebra de um código cifrado é o tamanho da chave. Para chaves de 128 bits por exemplo, temos 2¹²⁸ combinações possíveis. O que torna a busca exaustiva pela chave correta demasiadamente longa, mesmo para os mais rápidos computadores modernos.

Os algoritmos de criptografia são classificados em simétricos e assimétricos. Os algoritmos simétricos, ou convencionais, utilizam uma única chave para cifrar e decifrar as mensagens. O seu ponto forte é o desempenho, pois, em geral, eles são mais rápidos do que os simétricos. O seu maior problema reside no envio da chave. Como o receptor poderia receber a chave se o canal que se dispõe não é seguro? Para resolver este problema utilizam-se os agoritimos assimétricos, ou de chave pública, onde emissor e receptor possui um par de chaves cada um. Uma chave pública e outra privada.

Nestes algoritmos, sempre que uma mensagem é cifrada com uma das chaves, ela só é decifrada com a outra. Assim, se a minha chave privada for utilizada para cifrar uma mensagem, esta só poderá ser decifrada com a minha chave pública. Porém, ao utilizar apenas uma chave para cifrar e, sabendo que a chave que decifra é pública, esta não é uma boa solução. Uma boa saída é utilizar uma combinação de chaves. Para cifrar a mensagem utiliza-se a chave pública do destinatário e a privada do remetente, para decifrá-la utiliza-se a chave privada do destinatário e a pública do remetente. Desta forma, garante-se a privacidade, já que apenas o destinatário consegue decifrar a mensagem, posto que apenas ele conhece a sua chave privada. Garante-se também a autenticidade do remetente, uma vez que apenas ele que conhece a sua chave privada poderia cifrar uma mensagem que seria decifrada com sua chave pública. Estes algoritmos possuem dois problemas, eles são mais lentos do que os algoritmos convencionais e criam uma nova questão: como fazer a distribuição confiável de chaves públicas?

Será visto, na próxima seção, como, na prática, utilizam-se os algoritmos de criptografia, visando unir as vantagens de cada tipo. Na seção "Certificações, os Cartórios Eletrônicos," será visto como se processa a distribuição de chaves para o caso da SSL.

Nascida da necessidade de se enviar mensagens de forma segura durante as guerras, a criptografia é tratada ainda hoje como questão de segurança nacional por diversas nações. Este enfoque faz com que à exportação ou importação de tecnologia da área seja proibida ou controlada por diversos países. Em acréscimo a isto, ainda há a questão autoral. Diversos autores de algoritmos criptográficos impõe restrições ou cobram royalties pelo uso de suas idéias. Desta forma, a tendência forte no mundo das soluções abertas é utilizar protocolos de segurança que sejam independente dos algoritmos de segurança utilizados, possibilitando a negociação das melhores opções, entre o cliente e o servidor, no instante da conexão, em função das opções disponíveis em cada um. Por esta razão, softwares que utilizam criptografia, como os browsers web possuem versões diferentes para uso interno nos EUA/Canadá e para o resto do mundo. O Brasil não possui nenhuma restrição conhecida pelo autor a exportação e importação de tecnologia de criptografia. Em [Koops97] Bert-Jaap Koops apresenta a situação da regulamentação com respeito à criptografia em diversos países.

O leitor interessado num estudo profundo sobre criptografia pode utilizar o bem conceituado livro [Schneider95] de Bruce Schneider.

Figura 1: O Uso de Criptografia na Transferência de Mensagens

O Secure Sockets Layer

A SSL é hoje a mais popular solução para transações seguras na Web. Embora ainda não padronizada pela IETF, é um padrão de fato, implementado pelos mais populares browsers Web ( Navigator e Internet Explorer ) e pelos mais populares servidores Web ( Apache , NCSA httpd, IIS , Netscape Servers , dentre outros).

A SSL é um conjunto de três protocolo situados, dois deles, a nível de aplicação e, o terceiro, entre o protocolo de aplicação e o TCP, como esquematizado na figura abaixo. Seu objetivo é prover um canal seguro, isto é, com privacidade, com garantia opcional de autenticidade dos pares e garantia de integridade da mensagem.

Figura 2: Esquema de Níveis da SSL

Ao estabelecer a conexão, o SSL Handshake Protocol estabelece um identificador de sessão, um conjunto criptográfico (cypher suite) a ser adotado e um método de compressão a ser utilizado.

O conjunto criptográfico constitui-se de três algoritmos:

Um algoritmo para troca de chaves;
Um algoritmo para cifragem de dados, e
Um algoritmo para inserção de redundância nas mensagens.

O algoritmo para troca de chaves será um algoritmo de criptografia de chave pública que será utilizado para enviar uma chave privada do algoritmo de cifragem de dados(2). Assim, a SSL utiliza-se de um algoritmo assimétrico apenas para criar um canal seguro para enviar uma chave secreta, a ser criada de forma aleatória e que será utilizada para cifrar os dados utilizando-se de um algoritmo simétrico. O algoritmo simétrico (2) é utilizado para efetivamente cifrar os dados da camada de aplicação. Sua escolha é adequada por ser, em geral, mais rápido do que os assimétricos. Por fim, o algoritmo de inserção de redundância é utilizado para garantir a integridade da mensagem. Note-se aqui que a SSL não utiliza nenhum algoritmo específico, mas estabelece, em função dos algoritmos implementados no cliente e no servidor, qual o conjunto comum aos dois para implementar os três papéis necessários para criar-se um canal seguro.

Feito o handshake inicial, tem-se um canal que faz uso de um algoritmo simétrico de criptografia e um algoritmo de inserção de redundância na mensagem (chamada de MAC, Message Autentication Code). As mensagens do protocolo de aplicação são então comprimidas, inseridas as MACs e então cifradas antes de serem envidadas ao TCP. No destino, após a mensagem ser decifrada, a autenticidade da mensagem é verificada, comparando-a com a MAC, quando então ela é descomprimida e envida para a camda de aplicação. Exceto pelo fato de ter que iniciar o handshake da SSL e enviar as mensagens via SSL Record Protocol, nada mudou para os protocolos de aplicação. Outro ponto interessanda da SSL é a flexibilidade de poder ser implementada em qualquer protocolo de aplicação que utilize o TCP.

Há ainda o SSL Alert Protocol que existe para enviar e receber eventuais mensagens de erro, e, se necessário, interromper a conexão.

O leitor interessado nos detalhes da SSL pode encontrá-los em http://www.netscape.com/eng/ssl3/ .

Certificações: os cartórios eletrônicos

Um dos compromissos assumidos quando prometido o maravilhoso canal seguro foi o da autenticação das duas partes. Assume-se que um servidor, ou mesmo um browser, é quem diz ser, quando a chave pública por ele apresentada é certificada por um terceiro como sendo realmente dele. Na SSL, isto é feito solicitando-se do servidor (e.g.) sua chave acompanhada de um certificado de autenticidade. O processo é análogo à apresentação de uma identidade assinada por uma autoridade competente, a Secretaria de Segurança Pública (SSP), por exemplo. Mas, quem faz hoje o papel da SSP na Internet? Ou quem é aceita como autoridade certificadora (CA)? Uma resposta simples: a CA é uma entidade qualquer reconhecida como tal pelo servidor/cliente remoto.

Exemplificando para tornar mais claro este conceito. Imagine que um usuário X utilizando um browser com SSL estabeleça uma conexão com um servidor S. Durante o handshake e após terem acertado quais os algoritmos de criptografia que serão utilizados, S envia para X sua chave com seu certificado, emitido pela certificadora C. X pode, ou não, reconhecer C como uma CA e, caso reconheça, pode ser exigido por S que envie também sua chave com seu certificado. Uma questão importante aqui é: quem efetivamente decide se C é uma legítima CA? Quem? Depende! Depende do browser que X esteja utilizando. Em geral, os browsers têm internamente gravados de fábrica uma lista de certicadoras válidas fixa. A boa notícia é que alguns browsers permitem que o usuário acrescente novas certificadoras a esta lista. A má notícia é que nem todos eles hoje possuem essa facilidade. No primeiro caso, o fabricante do browser faculta ao usuário modificar, ou não, esta lista. No segundo, o fabricante é o único que pode determinar quem são as CAs válidadas no mercado! O Netscape Navigator 4.X é um exemplo do primeiro caso e o Internet Explorer 4.X é um exemplo do segundo caso. Espera-se que novas versões do Explorer permitam ao usuário tomar esta decisão no lugar do fabricante.

Embora na Web não seja muito utilizado, é possível também exigir do cliente, o browser, uma chave devidamente certificada. E aqui os papéis se invertem. No exemplo utilizado, isto é, utilizando o Apache-SSL, ver-se-á que o administrador pode determinar quais as CAs aceitas pelo seu servidor.

O Apache com SSL

O Apache-SSL é um servidor Web seguro, escrito por Ben Laurie , baseado no Apache e na SSLeay (lê-se S-S-L-e-a-y). O SSLeay é uma implementação da SSL feita por Eric Young e Tim Hudson . O SSLeay é uma biblioteca e um conjunto de aplicativos para criação/manipulação de chaves e certificados. Nesta seção, será explicado como instalar e configurar o Apache-SSL, sem entrar em detalhes sobre o processo ou o porte para algum UNIX em particular. O autor utilizou como base a versão 0.8.15 do SSLeay e a 1.2.5 do Apache, últimas versões disponíveis quando este artigo foi escrito.

Os passos necessários são:

Compilar o SSLeay;
Instalar o SSLeay;
Aplicar o patch do Apache-SSL sobre o Apache;
Compilar o Apache;
Instalar o Apache-SSL;
Criar chaves e certificado para o servidor;
Configurar o Apache-SSL.

O Apache pode ser encontrado a partir de http://www.apache.org , o SSLeay a partir de http://www.psy.uq.oz.au/~ftp/Crypto e o Apache-SSL a partir de http://www.apache-ssl.org .

Para compilar e instalar o SSLeay deve-se seguir as instruções contidas no arquivo INSTALL distribuido com o SSLeay.

Para aplicar o patch do Apache-SSL deve-se utilizar, no diretório dos fontes do Apache, o comando patch :

     % patch < SSLpatch

A partir daqui, procede-se a compilação e instalação do Apache normalmente. Ao final, haverá um executável, o httpsd. Eis o servidor desejado.

Precisa-se, agora, criar uma chave. O comando a seguir irá gerar uma chave utilizando DES triplo com 1024 bits. Os arquivos arquivo1:arquivo2:...:arquivoN são arquivos quaisquer utilizados para gerar números aleatórios. Há alguns UNIX que possuem um dispositivo (/dev/...) para este fim que pode ser utilizado aqui.


# cd /usr/local/etc/ssl/private
# ssleay genrsa -des3 -rand arquivo1:arquivo2:...:arquivoN 1024 > key.pem
req -new -out csr.pem -keyout key.pem -days 365 -config /usr/local/etc/ssleay.cnf
Enter PEM pass phrase:Nomonomonomo nomonomo
Verifying password - Enter PEM pass phrase:Nomonomonomo nomonomo
Country Name (2 letter code) [US]:BR
State or Province Name (full name) [MA]:Bahia
Locality Name (eg, city) [Cambridge]:Salvador
Organization Name (eg, company) [The Open Group]: RNP
Organizational Unit Name (eg, section) [Research Institute]:PoP-BA
Common Name (eg, YOUR name) [example.osf.org]: www.pop-ba.rnp.br
Email Address []:suporte@pop-ba.rnp.br
#

É necessário, agora, criar uma requisição de certificado (certificate signing request (csr)):

# cd /usr/local/etc/ssl/certs
# ssleay req -new -key ../private/key.pem > csr.pem

O próximo passo é solicitar a certificação da sua chave a uma CA. Há diversas CAs que certificam chaves do SSLeay. Em http://www.psy.uq.oz.au/~ftp/Crypto/#List of Certification Authorities encontra-se uma lista delas. Algumas das quais podem fazer a certificação gratuita para testes. É também possível criar a sua própria CA a título de teste, por exemplo, criando seu próprio certificado. Neste caso será necessário acrescentar a sua própria CA na lista de CAs aceitas pelo seu browser. Em [Hirsch97,Thawte98] o leitor interessado encontrará detalhes deste procedimento.

O Apache-SSL possui mais alguns parâmetros no arquivo httpd.conf adicionais aos parâmetros do Apache. Destacamos aqui os seguintes:

ServerType	Só Standalone está implementado
Port	Geralmente é a 443
SSLDisable	Se existir desabilita a SSL (útil se quiser utilizar HTTP e HTTPS no mesmo servidor)
SSLCACertificatePath	Diretório onde ficam os certificados dos CAs
SSLCACertificateFile	Certificado da certificadora
SSLCertificateFile	Certificado do servidor
SSLCertificateKeyFile	Chave do servidor
SSLVerifyClient	Para o cliente: 0 -> certificado não requerido (default) 1 -> o certificado é opcional 2 -> certificado válido é obrigatório 3 -> certificado é obrigatório, mas não é exigido que a CA seja reconhecida

No nosso exemplo, tem-se:

# cat /usr/local/etc/apache-SSL/httpd.conf
...
ServerType Standalone
Port 443
SSLCertificateFile /usr/local/etc/ssl/cert/cert.pem 
SSLCertificateKeyFile /usr/local/etc/ssl/private/key.pem 
SSLVerifyClient 0

O cert.pem foi obtido do CA a partir do csr.pem. O diretório /usr/local/etc/ssl/private deve ser de acesso apenas do root por segurança, embora o key.pem esteja cifrado.

Os SSLCACertificate* são necessários apenas se utilizar-se de certificação do browser. Um bom exemplo para isso é a criação de Intranets ou Extranets. Mas deixamos os detalhes a título de exercício para o leitor mais interessado.

Neste ponto, o Apache-SSL está pronto para rodar. Ao executar o httpsd, será pedida a senha utilizada para gerar a chave. Isso significa que, se o httpsd é configurado para ser automaticamente executado no boot, será necessário que um operador digite esta senha. Uma alternativa a isso é não deixar a chave em key.pem cifrada, mas tomando o cuidado de deixa este arquivo de acesso para leitura e escrita apenas pelo root e assumindo que o sistema utilizado é realmente seguro.

Conclusão

Trata-se, de fato, de um assunto complexo, mas não suficientemente complicado de forma a tornar-se inacessível. De uma forma geral, as atuais soluções criptográficas funcionam basicamente do mesmo jeito com algumas variações tipo: não utilizar chave pública (caso das senhas do UNIX), utilizar uma autoridade certificadora ( kerberos , por exemplo), deixar a certificação a nível do usuário ( ssh e PGP , por exemplo). Para os profissionais da área de redes, torna-se cada vez mais importante compreender e assimilar os conceitos aqui envolvidos como certificação, chaves públicas, criptografia, etc. Mesmo que alguns escapem da tarefa de configurar uma SSL, dificilmente, escaparão do IPsec ou do DNSsec .

Neste artigo, viu-se que o assunto não é tão complicado quanto parece e que não necessariamente precisa-se entender profundamente os meandros da criptografia para compreender o seu funcionamento e saber configurar/operar os serviços que a utlizam.

Referências

[Berners89] Information Management: A Proposal
by Tim Berners-Lee, CERN
March 1989, May 1990 . Em http://www.w3.org/History/1989/proposal.html em Fev/1998

[Hirsch97] Introducing SSL and Certificates using SSLeay
by Frederick J. Hirsch , The Open Group Research Institute, World Wide Web Journal, Summer 1997

[Koops97] Crypto Law Survey
by Bert-Jaap Koops, 8 December 1997. Em http://cwis.kub.nl/%7Efrw/people/koops/lawsurvy.htm em Fev/1998.

[Santos97] O que Vai Mudar na Sua Vida com o IPv6
by Adailton J. S. Silva , RNP , RNP NewsGeneration , Vol 1(2) 30 de junho de 1997. Em http://www.rnp.br/newsgen/ascii/n2.txt em Fev/1998

[Schneider95] Applied Cryptography Protocols, Algorithms, and Source Code in C
by Bruce Schneider, Wiley John & Sons Inc. ISBN 47111709-9. 1995

[Thawte98] ApacheSSL Key and CSR Generation
by Thawte Certification . Em http://www.thawte.com/certs/server/key_apachessl.html em Fev de 1998.