Ainda DNSSec e Dominios b.br

Continuo na busca do motivo pelo qual os dominios b.br com DNSSEC garantiriam mais segurança para os usuários de Internet Banking. Um comentário anônimo no meu post anterior deu uma pista: o DNSSEC trabalha em uma camada mais baixa que as outras soluções de segurança, notadamente o HTTP com SSL. Seria essa uma vantagem?

O DNSSEC realmente trabalha em uma camada bem baixa, dentro o mecanismo de resolução de nomes da Internet. Resolver um nome, como todo mundo provavelmente sabe, significa traduzir um nome como www.contosobank.b.br para um endereço IP como 200.1.2.3, que então é utilizado para comunicação com o site. É também possível fazer a operação inversa, obtendo um nome a partir de um endereço IP.

Justamente por trabalhar nessa camada baixa, tudo o que o DNSSEC pode garantir é que o IP 200.1.2.3 realmente corresponde ao o nome www.contosobank.b.br. Nada mais do que isso. (para ser honesto, o .b.br também nos diz que se trata de um banco brasileiro)

É um bom começo, mas de fazer a resolução do nome até o cliente efetivamente se comunicar com o banco ainda vai um longo caminho, também sujeito a intempéries e ataques. E é aqui que o DNSSEC mostra as suas limitações. Por exemplo, um atacante pode subverter o roteamento do provedor e redirecionar toda a comunicação do IP 200.1.2.3 para o seu próprio computador, fazendo um ataque de man-in-the-middle (ou talvez man-in-the-end!). E DNSSEC não tem como fazer nada para impedir isso - ele já faz a parte dele resolvendo o nome corretamente, e é só.

Por isso trabalhar em uma camada mais baixa é uma desvantagem e não uma vantagem. Um protocolo nada pode fazer contra ataques feitos nas camadas de cima, como é o caso do roteamento no exemplo anterior. Quanto mais alta a camada, quanto mais perto o mecanismo de segurança estiver próximo do que efetivamente precisa ser protegido - que no caso do Internet Banking são as transações financeiras - maior será a segurança deste mecanismo.

Aqui então de novo o DNSSEC perde em comparação com o uso de HTTP com SSL. O SSL vai trabalhar bem acima, em camada de aplicação, autenticando e criando um canal seguro fim-a-fim entre os cliente e o site do banco. Isso faz com que o SSL consiga proteger o cliente contra ataques por exemplo feitos em cima do roteamento ou mesmo sobre a resolução de nomes. Em resumo, o HTTP com SSL fornece toda a proteção fornecida pelo DNSSEC e mais um pouco para o Internet Banking.

Antes de terminar, dois pontos que também valem a pena se ressaltar. O primeiro é que o único tipo de ataque contra uma camada baixa que não pode ser evitado em uma camada mais alta é a negação de serviço. É por isso por exemplo que 802.1x protege contra ataques de flood de rede e o IPsec não. O DNSSEC evita por exemplo que um atacante faça um ataque de spoofing DNS e redirecione todo o tráfego para um IP inexistente, efetivamente tirando o serviço do ar. É uma boa coisa, mas não é essa a ameaça com que os usuários de Internet Banking estão preocupados.

O segundo ponto relevante é que HTTP com SSL também não é uma panacéia. O HTTP com SSL nada pode contra ataques feitos com cross-site scripting ou cross-site request forgery, que exploram vulnerabilidades em uma camada acima da que ele trabalha. A solução no entanto está em subir mais de camada e ficar ainda mais perto do que precisa ser protegido, fazendo autenticação em cada transação por exemplo.

Comments

• Anonymous
  January 01, 2003
  Em junho do ano passado o Comitê Gestor da Internet anunciou com grande repercussão a criação do domínio

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  The comment has been removed