João C. Ferreira (orientado)
Lucas C. Ferreira (orientador)
29 de junho de 2001
A seguir apresentamos um relatório da implementação de um sistema que integra a gerência de senhas, manutenção de anonimato e detecção parcial de SPAM em cadastros realizados via WWW. Para isso ele utiliza o recurso de proxies de forma a intermediar os cadastros feitos através de formulários HTML.
Na proposta de projeto [1] afirmamos que o projeto foi motivado pela crescente preocupação entre os usuários de serviços de internet com a sua privacidade. Os sites que oferecem serviços personalizados estão cada vez mais presentes na WWW e as correspondências eletrônicas indesejadas (SPAM) são cada vez mais comuns. Um sistema que permita lidar com segurança tanto com a privacidade do usuário, mantendo sua anonimidade, quanto com a detecção e filtragem de correspondência indesejável seria um grande atrativo para os usuários.
O trabalho apresentado a seguir corresponde a implementação do sistema descrito em [1]. Este sistema utiliza um proxy HTTP para fazer a gerência de senhas e anonimização de cadastros realizados na WWW através de formulários encontrados em sites que exigem personalização ou identificação dos usuários. Junto com a anonimização temos a geração de pseudônimos de e-mail correspondentes a cada cadastro em páginas WWW, de forma a manter a anonimidade inclusive nos casos onde e-mails válidos são solicitados para confirmar o cadastro. Como conseqüência desta anonimização de e-mails, temos um poderoso mecanismo de identificação de SPAM, já que cada site conhece apenas um dos pseudônimos criados e com isso podemos identificar qual site que passou adiante o endereço de e-mail pelo pseudônimo ao qual ele é destinado.
Para solucionar o problema de anonimização, foi desenvolvido um sistema que funciona como um proxy WWW e intermedia as mensagens trocadas entre um cliente e um conjunto de servidores. Este sistema tem a capacidade de alterar as mensagens enviadas pelo cliente de forma a criar dinamicamente conjuntos compostos por ``nome de usuário'', senha e e-mail. Esses conjuntos devem ser acessíveis para o usuário, de forma que ele possa usá-los novamente no mesmo servidor, e devem ser distintos para cada servidor, de forma que o servidor não possa identificar o usuário, nem trocar informações com outros servidores de forma a identificar um perfil único para aquele usuário.
Desta forma, cada conjunto 
nome, senha, email
deve ser calculado em função do conjunto
langlecliente, servidorrangle,
gerando uma saída única para cada cliente em cada servidor. A solução utilizada para isso foi a função de
Janus (Janus function), proposta em [3].
O sistema é então capaz de gerar e-mails, nomes de usuário e senhas distintos para cada par
cliente, servidor através de uma senha fornecida pelo cliente. De posse desta senha, o cliente pode
gerar novamente o mesmo conjunto enquanto o servidor só tem acesso ao conjunto que lhe foi destinado.
Tendo sido implementado como um proxy WWW a operação do sistema do ponto de vista do cliente é extremamente simples. Ao iniciar o navegador (devidamente configurado para utilizar o proxy) o usuário entra com uma senha (usando o sistema de autenticação de proxy já embutido no próprio navegador) e inicia a navegação. Quando o usuário se depara com uma situação onde uma senha, um e-mail ou um nome de usuário (ou qualquer combinação dos 3) são solicitados, como no caso de um formulário html ou uma solicitação de autenticação de uma página qualquer, ele preenche os campos desejados com uma seqüência de comandos predefinidos do proxy. O proxy ao identificar esses comandos calcula a função de Janus usando a senha do usuário e o site de destino da solicitação e substitui de forma transparente os valores computados. Como a função é calculada usando o site de destino da solicitação e a senha do usuário, enquanto o usuário mantiver a mesma senha os valores gerados serão sempre os mesmos e assim o usuário pode navegar sem a preocupação de criar nomes de usuário e senhas diferentes em cada site.
A detecção de SPAM é uma conseqüência da anonimização. Quando um site usa os e-mails cadastrados para fazer SPAM, ou vende suas listas de e-mail para terceiros, o usuário tem como identificar a origem do SPAM (ou quem vendeu seu endereço) pois cada cadastro em um site possui um e-mail diferente. Além disso a filtragem do SPAM se torna mais fácil pois basta desativar o alias de e-mail gerado para aquele site. Como o ofensor só tem acesso aquele endereço, ele não tem como continuar a enviar SPAM tornando o filtro mais eficiente que os filtros por conteúdo ou por origem, que sempre podem ser burlados.
Em primeiro lugar a decisão do que seria realmente necessário implementar teve de ser tomada. A implementação de um proxy WWW completo estaria fora do escopo deste trabalho, além de ser muito mais trabalhosa do que o projeto em si. Optou-se então pela elaboração de uma camada intermediária entre o cliente e um proxy WWW remoto, que faria apenas a filtragem e transformação das mensagens HTTP vindas do cliente. Os requisitos para essa camada intermediária estão descritos a seguir. Esta camada intermediadora ficaria situada diretamente na máquina do cliente, trazendo uma série de vantagens citadas em [3] sobre uma situação onde a camada de anonimização fosse situada num proxy remoto.
A camada de intermediação entre o cliente e o servidor de proxy deveria atender os seguitnes requisitos:
Estes requisitos são semelhantes aos propostos por [5], apenas adaptados para a realidade de uma camada intermediária entre o cliente e o proxy, já que em [5] um proxy completo foi implementado, envolvendo alguns requisitos adicionais.
A linguagem Java foi escolhida para a implementação do sistema por diversos fatores. O principal fator é a disponibilidade para os mais usados sistemas de computação pessoal (windows, Mac, Linux, etc). Além disso a possibilidade de extensão do sistema exigia uma linguagem com o perfil de Java, onde a orientação por objetos e a ligação dinâmica (dynamic linking) de classes permitem uma fácil extensão e atualização do sistema depois de ele já estar instalado. O suporte para operações de rede na linguagem java permite uma fácil implementação de sistemas que operam na internet, como no caso do proxy, o que torna Java a linguagem ideal para o projeto. A facilidade de criação de sistemas multitarefa também foi um dos fatores que levou a escolha da linguagem.
O proxy (ou a camada de interação entre o cliente e o proxy remoto) foi projetado como uma camada separada, com capacidade para fazer consultas a camada de anonimização. Uma hierarquia de classes descrevendo o proxy foi elaborada, composta principalmente de:
Um diagrama de classes pode ser visto na figura 1.
Além dessas classes uma série de classes que implementam ProxyState também são definidas. De forma que uma operação normal da máquina de estados inicia-se com InitialProxyState, passa para o HeaderGetterState onde o cabecalho HTTP da mensagem era lida. Dependendo da interpretação do cabecalho, o sistema entra num estado correspondente ao método solicitado pela mensagem (GET, POST ou HEAD). Estes estados são os responsáveis por encaminhar a mensagem ao proxy remoto, fazendo ou não a substituição através do objeto Aliasing. Ao final do processamento o sistema cai no estado CloseConnectionFinalState que finaliza com sucesso uma sessão. Outros estados derivados de FinalProxyState podem ser alcançados em condições de erro. A comunicação entre os estados é feita através do objeto de ProxySession que pode ser acessado por todos os estados e guarda dados como o cabeçalho das mensagens, nome de usuário e senha.
A função de Janus, como definida em [3] pode ser implementada com qualquer função do tipo MAC (Message Authentication Code) da seguinte maneira:
Entretanto, a função MD5 gera uma saída de 128 bits (ou 16 bytes), que é demasiado longa para ser utilizada como nome de usuário ou senha na maioria dos sistemas existentes na WWW hoje em dia. Além disso, a maioria dos sistemas exige que estes nomes e senhas sejam restritos a um conjunto de caracteres reduzido como o ASCII, de 7 bits. Para solucionar estes problemas modificamos a função de Janus, acrescentendo uma passada de uma função qualquer que transforme o conjunto de caracteres de 8 bits em um conjunto reduzido, como por exemplo o algoritmo de Base64 que mapeia de caracteres de 8 bits para caracteres de 6 bits. Para evitar também de calcular duas funções MAC, podemos separar os 128 bits da saída (agora transformados em 176 bits) em subconjuntos de 64bits (8 bytes) e usar um dos subconjuntos para gerar senha e outro para gerar o nome do usuário. Teríamos então uma função de Janus da sequinte forma:
A função de Janus para gerar um e-mail entretanto ainda consistia um problema pois a solução proposta por [3] e implementada em [2] e [5] exige a manutenção de alguma estrutura persistente que mapeie cada endereço para um determinado site. Para evitar a manutenção de uma estrutura persistente utilizamos uma forma em que o servidor de proxy utiliza uma chave secreta para criptografar uma sequência contendo o nome do usuário e o nome do site para o qual aquele e-mail foi gerado. Ao receber este e-mail tanto o usuário quanto o servidor de e-mail podem solicitar ao proxy quem são o destinatário ou o remetente. Esta forma entretanto exige que o servidor de e-mail esteja localizado em um servidor confiável. A função criptográfica utilizada foi o DES no modo conhecido como "ede" (também conhecida como triple DES ou 3DES).
A atenção desse projeto ficou voltada principalmente para a construção do proxy e das funções listadas acima, assim não proporcionamos nenhuma solução definitiva para a associação dos e-mails gerados com caixas postais reais, nem um sistema de encaminhamento dos e-mails recebidos para o usuário final. O sistema planejado é um redirecionador simples integrado com o proxy que receba os e-mails pelo protocolo de SMTP e redirecione para um servidor SMTP remoto, substituindo o campo do destinatário pelo endereço obtido ao se decifrar o e-mail do destinatário original.
A última fase do projeto consistiu na implementação do proxy. Nesta fase surgiram diversos problemas que não haviam sido previstos em tempo de projeto, levando a tomadas de decisões que são descritas abaixo.
O Plano original previa a implementação de um proxy compatível com o protocolo HTTP 1.0 [4]. Entretanto o protocolo HTTP 1.0 não permite a autenticação de proxies, com isso o proxy teve de ser extendido para implementar além do protocolo HTTP 1.0, uma parte do protocolo HTTP 1.1 [6]. Como a maioria dos navegadores em uso hoje aceita extensões do protocolo HTTP 1.0, a extensão do proxy para implementar todo o protocolo HTTP 1.1 não se fez necessária. Esta decisão pode levar o proxy a perder sua compatibilidade com alguns navegadores mais exigentes, mas até o presente não foi encontrado nenhum problema com esta implementação parcial.
Como foi descrito na seção 3.4 uma função que reduz o conjunto de caracteres e necessária para que
os pseudônimos gerados sejam aceitos pelos sites. A função originalmente utilizada foi a função
Base64, usada para a autenticação no protocolo HTTP, por já estar disponível devido a esse motivo.
Entretanto os aliases de e-mail exigiam que o mapeamento fosse feito para um conjunto mais reduzido
ainda, incluindo apenas as letras minúsculas. Por isso foi implementado um mapeamento que transforma cada
byte em um conjunto de 2 caracteres minúsculos, utilizando para isso apenas as 16 primeiras letras do
alfabeto. Esta codificacao funciona da seguinte maneira:
Cada byte é quebrado em dois conjuntos de 4 bits e cada um dos 16 valores possíveis para os conjuntos de 4 bits
é mapeado para uma letra minúscula correspondente (0 
a, 1 b, ..., 15 p). Assim cada
byte gera 2 caracteres minúsculos na saída da codificação.
No caso do e-mail, não existe uma redução da segurança devido a isso, já que o tamanho dos endereços
de e-mail não costuma ser limitado, com isso podendo toda a seqüência criptografada ser incluída como nome
do remetente no e-mail.
Foi constatado posteriormente durante a fase de testes que alguns sites rejeitavam alguns dos caracteres gerados pela codificação Base64, exigindo assim uma codificação mais restrita. A codificação Base64 foi então substituida pela mesma codificação usada para os e-mails. Com isso o número efetivo de bits da função MD5 usados para geração dos pseudônimos e das senhas foi reduzido para 32. As implicações de segurança desta redução ainda precisam ser avaliadas. Uma forma melhor de reduzir o conjunto de caracteres também precisa ser avaliada de forma a aproveitar melhor o conjunto aceito pelos sites. O uso de Base64 com algumas sequências de escape parece uma boa solução.
Como o sistema não foi implementado pensando em desempenho, e sim na facilidade de implementação, o resultado deixa um pouco a desejar em termos de desempenho. Entretanto por ser uma arquitetura relativamente flexível, melhorias de desempenho podem ser introduzidas no futuro com bastante facilidade e sem demandar alterações muito extensas no programa.
Os testes realizados até o momento não são muito extensos, mas indicam que o sistema atende os requisitos propostos. Além de tudo o sistema se mostrou bastante robusto em caso de falhas. Apesar disso o sistema ainda precisa ser testado extensivamente de forma a identificar quaisquer problemas que possam ocorrer. O ambiente onde o sistema foi testado consiste em:
This document was generated using the LaTeX2HTML translator Version 97.1 (release) (July 13th, 1997)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -no_navigation -show_section_numbers relatorio.tex.
The translation was initiated by Joao de Carvalho Ferreira on 6/29/2001
