Dominio b.br Garante Mais Segurança?

Alguém pode me explicar como é que ter um domínio b.br com DNSSec vai garantir mais segurança aos usuários de Internet Banking?

Meu raciocínio, talvez limitado, é o seguinte: o protocolo DNS é realmente inseguro. Está mesmo sujeito a todo tipo de spoofing conhecido. Só que esse problema já foi superado há muito tempo com o uso de HTTP com SSL pelos sites Web. O SSL já fornece uma autenticação criptograficamente forte do site Web, e de quebra estabelece um canal criptografado entre o cliente e o site. Não importam os truques que um fraudador venha a fazer com o DNS e com o resto da infraestrutura de rede, o cliente já sabe quando está acessando o site Web verdadeiro. E o navegador fornece uma indicação visual disso.

("Ah, mas ninguém olha o cadeadinho". Ok, se depois de 10 anos de intensa campanha muitos usuários ainda não prestam atenção no cadeado, agora subitamente vão prestar atenção em uma letra b colocada no meio da URL? Sério?)

E em termos conceituais, o DNSSec é ainda menos seguro do que o HTTP com SSL. Usando as leis de Ranum, ao confiar em um site com SSL de um banco, você está implicitamente confiando na autoridade certificadora e no próprio banco. No DNSSec você está confiando no próprio banco e no seu provedor de acesso Internet. Cancelando os fatores, você estaria trocando confiar em uma autoridade certificadora, cujo negócio é confiança, por confiar em um provedor de acesso, cujo negócio é... prover acesso. É uma má escolha na minha opinião.

Por favor, eu não condeno a iniciativa do CGI.br. Implementar DNSSec é o que está ao alcance do comitê e ele está fazendo a sua parte. Mas ele está tentando resolver um problema que já foi resolvido.

UPDATE: O site Linha Defensiva publica hoje uma notícia sobre o assunto, ouvindo inclusive o Augusto.

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
  Uma das novidades do Windows 7 e do Windows Server 2008 R2 (o “Windows 7 Server”) é o suporte a DNS Security

• Anonymous
  January 01, 2003
  Excelente referência Altieres, obrigado pelo link. E você toca em um ponto importante que eu nem tinha me dado conta. Nós sempre orientamos o usuário a não confiar na URL apresentada e sim verificar o cadeado, e por um bom motivo - existem dezenas de forma escrever uma URL que "pareça" ser a correta. Agora com o b.br vamos dizer para o usuário confiar na URL?

• Anonymous
  January 01, 2003
  Altieres, o uso incorreto do SSL é realmente um problema. Muita gente ainda pensa que SSL server somente para encriptar o dado na rede, quando na verdade a principal função é autenticar o servidor. Eu postei há algum tempo atrás sobre isso aqui no blog ("O problema é autenticar o servidor e não o cliente", http://blogs.technet.com/fcima/archive/2006/09/11/455474.aspx). Mas a solução para esse problema é usar o SSL de forma correta, não o DNSSEC. Voce também lembra bem que uma simples mudança no arquivo HOSTS é suficiente para bypassar o DNSSEC. Eu não entrei neste mérito nos meus posts porque eu assumo que se o computador do cliente foi invadido então nada pode ser feito, mas certamente depõe contra o DNSSEC que ele possa ser bypassado de forma tão trivial.

• Anonymous
  January 01, 2003
  Douglas, sem dúvida DNSSEC oferece proteção contra os ataques de poluição de cache. Meu ponto no entanto é outro - é que essa proteção é desnecessária porque o uso do SSL já oferece essa proteção. Eu não entendi a questão dos bits. Pela minha documentação aqui o servidor DNS Microsoft usa os mesmos 16 bits de entropia para gerar os transaction IDs que as outras implementações. A quê você se refere? Obrigado pela contribuição! Abracos.

• Anonymous
  January 01, 2003
  Oi Contestador, O uso de SSL/TLS já resolve o problema de ataques do tipo "man-in-the-middle". Tentar resolver isso com DNSSEC é no mínimo redundante, ainda mais sendo menos segura que a forma já existente. O fato do SSL/TLS trabalhar em uma camada mais alta é uma vantagem e não uma desvantagem, porque abstrai as vulnerabilidades eventualmente encontradas nas camadas abaixo. E na verdade já existe na máquina do usuário os certificados das autoridades certificadoras raiz, que permitem validar o certificado do Web site do banco. Abracos,

• Fernando Cima

• Anonymous
  July 02, 2007
  The comment has been removed

• Anonymous
  July 02, 2007
  Cima, O que eu tenho visto muito é uma tentativa de "consertar" o que se resolve com educação, utilizando recursos tecnológicos. Você acaba por aumentar demais a complexidade com um ganho de segurança mínimo. Quem sabe um dia não se tenta fazer o contrário? Educar para depois configurar? :). []'s Alberto

• Anonymous
  July 03, 2007
  O comentário do Alberto Oliveira me lembra de um artigo do Larry Seltzer na eWeek, The Moon and the Spam Filter, exatamente sobre o assunto das soluções tecnológicas para problemas sociais: http://www.eweek.com/article2/0,1895,1911795,00.asp Como o Cima falou, é difícil crer que alguém vai reparar no "b" quando ninguém observa o cadeado (nem presta atenção nas mensagens de certificado expirado). Exatamente por ser difícil de crer nisso é que se torna complicado convencer os desenvolvedores a implementar o DNSSEC no próprio sistema. E também fica impossível abafar outras soluções para o mesmo problema (EV-SSL). No fim, ficam escolhas demais e o medo de jogar trabalho fora acaba fazendo com que ninguém escolha nada. Ou então uns escolhem A e outros B, o que torna ainda mais difícil de educar os usuários, que é exatamente o que resolveria este tipo de problema. O pior é que isso tudo serve para bloquear um único tipo de golpe, que nem se sabe exatamente qual é a gravidade.

• Anonymous
  July 04, 2007
  Isto mesmo, Cima. Recebi um e-mail de um usuário confuso porque sempre achou que só poderia digitar seu usuário e senha de banco em páginas que tivessem o cadeado, mas vários bancos não utilizam SSL nas páginas com os formulários. Aí o usuário me questiona se observar o cadeado é afinal necessário ou não. "É necessário sim. Mas se você observá-lo à risca, não poderá usar internet banking porque o banco não usa o SSL corretamente." Isto não é resposta que podemos dar aos usuários. Creio que o ideal seria proteger a página inicial, mesmo que ela não tivesse formulário, já para que o usuário saiba que está no lugar certo. Mas não fazem nada disso. Como podemos dizer a eles que apenas um site com o cadeado é seguro? Se dissermos isso, vão desconfiar dos sites de praticamente todos os bancos (e com razão), porque não usam SSL de forma correta. Com isso chega o DNSSEC, oferecendo garantia do endereço visitado. De uma hora para outra, os usuários devem confiar na URL. E os trojans que mudam o arquivo hosts? O DNSSEC protege contra isso? Já vi vários destes (Banhosts) porque são mais simples de serem desenvolvidos. Se os bancos usassem SSL corretamente e os usuários soubessem verificar o cadeado, este tipo de praga não seria problema. Mas com os bancos usando SSL de forma errada, e agora com o DNSSEC, só podemos dar conselhos que se contradizem com a realidade. Quem perde com isso não são só os usuários, mas todos nós, porque a educação deles é que resolve vários dos problemas de segurança atualmente.

• Anonymous
  July 06, 2007
  Tentando complementar a troca de informações... Existe uma serie de outros tipos de ataques em que o DNSSEC atua... principalmente nos ataques onde se tenta poluir o cache do servidor recursivo. Pra quem atua diretamente na administracao deste tipo de servidores, sabe que isso é comum. Vale lembrar que o Windows Server usa dois bits a menos para geração do Id do protocolo DNS , facilitando ainda mais esse tipo de ataque. Espero que tenha contribuido com a discussão. Abracos