DCC - UFMG
Projeto Orientado em Computação II
Relatório Final

Sistema de anonimização e detecção de SPAM através de um Proxy WWW

João C. Ferreira (orientado)
Lucas C. Ferreira (orientador)

29 de junho de 2001

Abstract:

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.

1 Apresentação

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.

2 Descrição do sistema

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 $\langle$nome, senha, email$\rangle$ 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 $\langle$cliente, servidor$\rangle$ 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.

3 Análise e projeto

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.

3.1 Requisitos do proxy

A camada de intermediação entre o cliente e o servidor de proxy deveria atender os seguitnes requisitos:

Compatibilidade
O proxy deve ser compatível com os navegadores existentes, e pelo menos com o protocolo HTTP 1.0 [4]. Isto garantiria que o usuário não precisasse de nenhuma modificação no sistema de navegação já em uso na sua máquina.
Transparência
O uso do proxy deve ser invisível para o usuário, funcionando apenas nos casos onde for solicitado.
Statelessness
O sistema não deve manter nenhuma insformação de estado após finalizada a sessão, sendo capaz de regerar os dados de anonimização novamente a partir do estabelecimento de uma nova sessão. Este requisito não é tão necessário no caso do anonimizador estar localizado na máquina do usuário por não oferecer risco de segurança, mas pode ser útil caso o usuário necessite trocar de máquina, não precisando carregar nenhuma informação de uma máquina para outra.

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.

3.2 Linguagem para implementação

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.

3.3 Projeto do proxy

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:

Proxy
Classe principal do sistema. Tem como objetivo esperar conexões e criar novos objetos do tipo ProxySession, que representam cada conexão do usuário com o proxy.
ProxySession
Esta classe extende java.lang.Thread, de forma a executar como uma tarefa concorrente e não influenciar na execução da classe principal. Ela dá início a uma máquina de estados representada pelas classes implementando a interface ProxyState. A máquina de estados corresponde ao Design Pattern [8] de máquinas de estado.
ProxyState
Esta é a interface que deve ser implementada por todos os estados da máquina de estados. Ela provê um método getNextState() que deve conter todo o processamento realizado durante a presença naquele estado e retornar o próximo estado em que a máquina deve se encontrar.
FinalProxyState
Esta sub-interface de ProxyState indica estados que terminam a execução da máquina de estados (e consequentemente uma sessão de proxy). Elas possuem um método doFinalProcessing() que é responsavel por finalizar a sessão e é executado na finalização da máquina de estados.
Aliasing
Esta é a classe responsável pela anonimização. Ela pode ser chamada por qualquer um dos estados da máquina de estados que necessitar de alguma anonimização. Ela possui métodos específicos para realizar substituição em strings codificadas em Base64, que é a codificação usada na autenticação do protocolo HTTP [4], ou URL Encoded, que é como os forms transmitem sua informação via método GET ou POST [4].

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.


  
Figure 1: Estrutura de classes
\begin{figure}
\psfig {file=teste.ps,width=12cm}

 \end{figure}

3.4 Projeto da função de Janus

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:

\begin{displaymath}
\mathcal{J}(c_i, s_j, p_i, t) = MAC_{p_i}(c_i\vert\vert s_j\vert\vert t) \end{displaymath}

onde ci é um cliente qualquer, sj um servidor qualquer, pi a senha correspondente ao cliente ci e t o tipo da transformação (seja gerar um e-mail, um nome de usuário ou uma senha). O Suporte de criptografia da linguagem Java [7] proporciona o uso da função MD5 como uma função MAC. Esta função foi escolhida por ser bastante conhecida e estudada, garantindo assim sua segurança, e também por que o seu suporte na linguagem Java a implementa de forma fácil de ser usada.

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:

\begin{displaymath}
\mathcal{J}(c_i, s_j, p_i, u) = bits_{0,63}(BASE64(MD5_{p_i}(c_i\vert\vert s_j))) \end{displaymath}

e

\begin{displaymath}
\mathcal{J}(c_i, s_j, p_i, p) = bits_{64,127}(BASE64(MD5_{p_i}(c_i\vert\vert s_j))) \end{displaymath}

onde u e p são os símbolos identificadores de "nome de usuário" e "senha" respectivamente.

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

3.5 E-mail

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.

4 Implementação

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.

4.1 Autenticação

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.

4.2 Redução do conjunto de caracteres válidos

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 $\Rightarrow$ a, 1 $\Rightarrow$ b, ..., 15 $\Rightarrow$ 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.

4.3 Desempenho

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.

5 Testes

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:

References

1
Ferreira, João & Ferreira, Lucas. Sistema de anonimização e detecção de SPAM através de um Proxy WWW . Proposta de POC II, Mar. 2001

2
Gabber, E., Gibbons, P.B., Kristol, D.M., Matias, Y. & Mayer, A. Consistent, Yet Anonymous, Web Acess with LPWA . Communications of the ACM Vol. 42, No. 2. Fev. 1999.

3
Bliechenbacher, D., Gabber, E., Gibbons, P.B., Matias, Y., Mayer A. On secure and pseudonimous client-relationships with multiple servers . Proceedings of the Third USENIX electronic Commerce Workshop. 1998.

4
Berners-Lee, T., Fielding, R., Frystyk, H. Hypertext Transfer Protocol - HTTP/1.0 . RFC 1945. Maio 1996.

5
Kristol, D.M., Gabber, E., Gibbons, P.B., Matias, Y. & Mayer, A. Design and implementation of the Lucent Personalized Web Assistant (LPWA) . http://www.math.tau.ac.il/~matias/papers/lpwa.ps. Jun. 1998.

6
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. Hypertext Transfer Protocol - HTTP/1.1 . RFC 2616. Jun. 1999

7
Sun Microsystems, Inc. JavaTM Cryptography Extension (JCE) . http://www.java.sun.com/products/jce/index.html.

8
Gamma, E., Helm, R., Johnson, R., Vlissides, J., Booch, G. Design Patterns . Addison-Wesley, 1995.

About this document ...

DCC - UFMG
Projeto Orientado em Computação II
Relatório Final

Sistema de anonimização e detecção de SPAM através de um Proxy WWW

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


Joao de Carvalho Ferreira
6/29/2001