- Feed completo
- Feed dos comentários
- Feed do Fórum
- Feed Canal Games
- Feed Canal Fotografia
- Feed Canal Mobile
- Receba o Meio Bit via e-mail
Fórum
Últimos tópicos no fórumÚltimas respostas no fórum
- Ajuda para comprar um notebook
- instalar mac osx em pc
- Novo Portal Terra. Não funciona no Chrome?
- Você consegue resolver esse enigma?
- Campus Party
- Dica de Headset
- Pilhas recarregaveis?
- OpenID consertado !
- Vendo D60 com lente 18-55mm VR
- nova ortografia brasileira no Microsoft Office
- ajuda com placa mãe....
- Feed de comentários consertado !
Newsletter
Mantenha-se informado sobre as nossas novidades com nosso newsletter semanal, todas as segundas-feiras
Categorias
Áudio Vídeo Fotografia
Acessórios
Análise
Análises
Anúncios
Anúncios
Apple e Mac
Artigo
Blog
Celular
Computação móvel
Computadores
Comunicação Digital
Cultura Gamer
Destaque
Destaque
Dicas
Download
Equipamentos
Games
Google
Hardware
Indústria
Indústria
Internet
Linux
Microsoft
Miscelâneas
Miscelâneas
MMO
Museu
Nintendo
Open-Source
Periféricos
Podcast
Portáteis
Preview
Produtividade
Propaganda & Marketing
Publicidade
Rumores
Seguranca
Software
Sony
Tutorial
Vídeos
VoIP
Web 2.0
Web Games
Wireless e Redes
Os bancos Alfa, Bonsucesso, Bradesco, BVA, Banco Cooperativo Sicredi, Bic Banco, Prosper, Schahin, Banrisul e Paraná Banco já aderiram ao novo domínio "b.br". Criado há mais ou menos um mês, a nomenclatura é de uso exclusivo para instituições bancárias.
A medida visa dar mais segurança às transações bancárias via Internet, preservando internautas de práticas maliciosas na rede, como o "phishing" (furto de dados pessoais pela web).
O novo domínio tem um sistema que identifica sites (DNSSEC), valida e reconhece a autenticidade da página antes que o usuário tenha acesso a ela.
Agora vêm os questionamentos: como é que vão garantir mais segurança aos usuários de Internet Banking se o protocolo DNS é inseguro? De toda forma, me parece ser redundante, já que o protocolo HTTPS faz a criptografia dos dados e tem uma autoridade certificadora.
Para finalizar, bem que poderiam seguir o padrão usando um domínio do tipo ".bco.br", mas do que isso adiantaria? O usuário não vai olhar o endereço da URL mesmo...
[ Via Folha ]
- Ueba
- Rec6
- entre com seu usuário e senha ou registre-se no site para enviar comentários
Não vai adiantar nada.
O problema de tanto golpe é o usuário, e ele vai continuar fornecendo todos os seus dados para sites falsos do mesmo jeito que já vem fazendo.
E visite meu blog.
_____________________
About Me - Muita Pimenta para sua vida.
01010010 01101111 01100011 01101011 01
[Não vai adiantar nada.[2]
E não esqueçam, visitem o:
Blog do Monthiel
O DNSSEC é voltado a segurança do usuário.
Eu nunca vi tanta besteira em um artigo só. É evidente que o DNSSEC não será a solução, mas é uma excelente medida adotada para proteção de usuários de Internet Banking e outros serviços que também irão vir a usa-lo.
"O único homem que está isento de erro é aquele que não arrisca acertar." (Albert Einstein)
Bem, eu nunca vi tanta baboseira em um comentário só. O Wilton está certíssimo - o SSL já dá a proteção fim-a-fim para a comunicação entre o usuário e o banco, e o DNSSEC não acrescenta rigosoramente nada neste cenário. Para dizer a verdade só atrapalha.
Ah é? gênio.
E se o cliente do banco for vítima de ataques como: DNS cache poisoning / Pharming, DNS hijacking, e outros ataques usando o DNS?
Essa frase sua mereceu um quote.
Como ocorre o DNS cache poisoning?
Quando um resolver faz uma consulta DNS a um servidor recursivo, caso o servidor recursivo não possua a informação em cache ele propagará a consulta para outros servidores. Neste
momento pode ocorrer uma ataque de envenenamento de cache. Pois é possível que um agente de má fé devolva uma mensagem antes da resposta verdadeira.
Caso o servidor autoritativo esteja com a zona assinada com o DNSSEC, e o recursivo com o DNSSEC habilitado, todas as respostas deverão ser enviadas assinadas e verificadas no destinatário. Com isso, o servidor recursivo irá executar um procedimento de validação antes de incluir qualquer resposta no cachê ou mesmo de repassá-la ao resolver. Sendo assim, uma resposta sem assinatura ou com assinatura inválida, será descartada pelo servidor recursivo.
Sabendo disso, olhe no ISC.org por BIND Vulnerabilities.
Link: http://www.isc.org/index.pl?/sw/bind/bind-security...
Por exemplo:
CERT VU#800113 DNS Cache Poisoning Issue
ISC characterization: Query Port Randomization for BIND 9
[Added 2008.07.08]
CVE: CVE-2008-1447
CERT: VU#800113
Versions affected: BIND 8 (all versions)
BIND 9 (all versions)
Severity: High
Known exploits to date: None
=======
Depois da divulgação já existem exploits
Description:
Tested: BIND 9.4.1-9.4.2
Release Date: 2008.07.23
=============
Mesmo com isso tudo, você deve ter razão. Errado estou EU, o Internet System Consortium (ISC), o Internet Engineering Task Force (IETF), o Internet Corporation for Assigned Names and Numbers (ICANN), os Bancos, o Registro.br, entre outros.
"O único homem que está isento de erro é aquele que não arrisca acertar." (Albert Einstein)
E se o cliente do banco for vítima de ataques como: DNS cache poisoning / Pharming, DNS hijacking, e outros ataques usando o DNS?
Nada disso importa se você estiver usando SSL. Neste caso o cliente está *autenticando* o servidor e criando um *canal seguro* entre os dois. Um ataque na camada 3 não é relevante se eu tenho autenticação fim-a-fim na camada 7.
Para você entender, vamos supor que o meu banco tenha endereço IP 10.1.1.1, mas um atacante tenha feito um cache poisoning no meu servidor DNS e eu receba 10.2.2.2, um IP de um site de phishing.
Na hora que eu me conectar via SSL ao banco, eu vou ser mandado para o site de phishing no IP 10.2.2.2. O que acontece então? **A conexão não acontece**, porque o site de phishing não tem a chave e certificado SSL do site legítimo. A fraude não acontece, e o cache poisoning não serviu para nada.
Existem outros cenários onde o DNSSEC é interessante, mas para outras aplicações e em particular onde os servidores DNS são confiáveis. Em Internet Banking e ISPs simplesmente não existe ganho.
Você estaria certo se toda comunicação com o banco fosse feita através de SSL. Qual banco no Brasil possui SSL na página principal, ou melhor, qual banco não tem SSL apenas no formulário de conta?
Se você é vítima de um DNS poisoning antes desse host ssl, então, você é sim uma vítima em potencial.
Bradesco: wwwss.bradesco.com.br
Itaú: bankline.itau.com.br
O que a segurança DNSSEC irá acrescentar é a garantia que o site antes do host com certificado ssl é realmente real. Se você falasse que seria melhor o banco implementar o ssl de melhor maneira, então, eu concordaria integralmente com você, mas falar que DNSSEC é inútil nesse cenário? você se engana.
"O único homem que está isento de erro é aquele que não arrisca acertar." (Albert Einstein)
Você estaria certo se toda comunicação com o banco fosse feita através de SSL. Qual banco no Brasil possui SSL na página principal, ou melhor, qual banco não tem SSL apenas no formulário de conta?
SSL não precisa estar na página inicial, e sim na parte onde os clientes enviam credenciais, recebem informações sensíveis e fazem transações.
O meu banco (Itaú) tem SSL em toda a parte transacional. Se algum outro banco tem SSL apenas no formulário de conta deveria estar corrigindo isso, e não perdendo o seu tempo com DNSSEC.
Eu penso diferente, não é a maçã. Todo dado deveria ser sensível.
Deve ter me expressado mal, vamos tentar denovo.
O que o DNSSEC garante é que o site: www.bradesco.b.br é realmente o site www.bradesco.b.br, o que não ocorre com o DNS. Se você é vítima de um DNS poisoning antes desse host ssl, então, você é sim uma vítima em potencial.
De que iria adiantar ter o certificado SSL para os hosts abaixo, se o usuário não estaria no site dos bancos, e sim em um site fake retornado pelo DNS?
Bradesco: wwwss.bradesco.com.br
Itaú: bankline.itau.com.br
O que a segurança DNSSEC irá acrescentar é a garantia que o site ANTES do host com certificado ssl é realmente real. O DNSSEC não é inútil neste cenário, pelo contrário, é excelente.
Se um usuário digita o endereço (vou mudar de banco pra não parecer marketing) www.itau.com.br, e ele é vítima de DNS cache poisoning, lá estará ele vendo o site que digitou só que na verdade não é o site do Itaú, e agora? aonde entra a segurança SSL para este usuário? ou você acha que usuário sabe o que é entidade certificadora e para quem ela realmente emitiu o certificado?
O que estamos tratando aqui é de resolução de nome, e não do canal seguro de comunicações.
"O único homem que está isento de erro é aquele que não arrisca acertar." (Albert Einstein)
O TSL/SSL garante privacidade (você se refere a isso usando *canal seguro*, certo?). Falta a autenticação, que é *provar a identidade*, e isso não é responsabilidade do TSL/SSL, ele só dá o certificado do servidor pro cliente (e vice e versa, em certos casos) e garante que a comunicação é com o portador do certificado. A responsabilidade de avaliar se o certificado portado pelo servidor é adequado É DO CLIENTE.
Bigode, não existe canal seguro sem autenticação. Não adianta nada encriptar a comunicação se você está falando com o cara errado. Autenticação do servidor é a principal função do certificado.
Adianta sim, eu tenho privacidade. O *canal seguro* precisa de privacidade e autenticação.
O TLS/SSL é responsável pela privacidade e a garante, mas não pela autenticação (ele só dá meios funcionais para isso e garante que a comunicação é feita com o portador legítimo do certificado USADO). A autenticação, no caso do TSL/SSL é avaliar se o certificado portado identifica corretamente o servidor (ou cliente) legítimo, e isso é de total responsabilidade do cliente (ou do servidor, no caso da autenticação do cliente), não do protocolo ou do certificado. E isso é feito antes do canal começar a ser encriptado.
Aproveitando o assunto, fiquei impressionado como não houve nenhuma evolução no site do Banco do Brasil.
Haviam dois anos que não o visitava e simplesmente não implementaram nenhuma alteração. Nem de layout e, pelo que vi, nem em segurança, inclusive com links "quebrados".
Engraçado é que há uns dois anos atrás era o site bancário mais avançado que eu conhecia, no Brasil.
.....................r o n i u j ...........................
Concordo contigo, é bem fraquinho sim, minha melhor experiência até agora é com o Unibanco, muito bom o site, o Itaú também supera o BB mas ainda fica devendo em alguns quesitos, como por exemplo algumas transações de pagamentos não possuem autenticação no comprovante.
Imagina como vai ficar o endereço do site do Banco do Brasil depois que adotarem isso!
www.bb.b.br
_____________________________________
Assinatura?
Nem pensar! Nunca entenderiam minha letra, minha sorte e que meu Blog não é manuscrito!
ou www.b.br
a alteração visa a segurança dos servidores "DO BANCO" e de todo o sistema dele e não do sistema dos usuários e nem da burrice deles =D
Sinceramente bco no lugar b seria mais ultilizável. Ma que diferença faria no montante de merda final se os bancos vão usar apenas como direcionamento já que as outras páginas estão em .com.br?
Pra mim iniciou-se mais uma incrível iniciativa sem fim prático!
Na verdade não, como em teoria esse domínio é melhor que o antigo, os bancos vão redirecionar os com.br pro b.br. Ah, pelo que eu vi nem o bradesco nem o banrisul fizeram isso.
O https não tem autoridade certificadora. O que há é que certificados (chaves) são sempre assinados, e alguns browsers vêm com uma lista de "Otoridades" - Assinaturas Confiáveis.
O DNSSEC não valida e reconhece a autenticidade da página antes que o usuário tenha acesso a ela, ele nem olha a página. Ele somente é um servidor de dns comum, que manda as respostas assinadas, isso teoricamente protege contra cache poisoning e essas coisas. O servidor dns usado pelo usuário pode por exemplo ser comprometido por terceiros... o DNSSEC não resolve problemas assim.
Eu sei que você copiou literalmente da folha, mas olha o tamanho das besteiras que eles falam:
"O domínio tem um novo sistema de identificação de sites chamado DNSSEC, que valida e reconhece a autenticidade da página antes que o internauta tenha acesso a ela. "
Rá DNS é IDENTIFICAÇÃO DE SITES. Brilhante.
Repórteres em geral adoram falar com pompa de coisas que não conhecem. Dá um desconto, isso é um traço de personalidade inerente a classe deles.
Não, esses são os políticos. Veja Palin, segundo ela a primeira emenda foi criada pra proteger os representantes do Estado de repórteres bisbilhoteiros.
Essa manja. Quanto aos políticos, você tem razão, eles também.
Creio que quanto maior a sensação de prepotência e ego-inflado no estilo "Todos dependem de mim" ou "Eu sou o/a cara", mais agravante é essa característica.
Mas pera se eu bem entendi não existiram então os "mirrors" dos sites, aqueles falsos que parece que você está no lugar certo, mas na verdade está num site de um Cracker. porque para estar cadastrado nesse dominio tem que ser reconhecido com banco pelo estado certo. então é uma boa saída sim.
Se for utilizado com frequência passará a ser tão normal como o .com.br
__________________________________________________________
Pangamirratomiruaro...
Como pode alguém que não sabe nem o que é DNSSEC comentar sobre esse?
Eu nunca vi tanta besteira em um artigo só. É evidente que o DNSSEC não será a SOLUÇÃO, mas é uma excelente medida adotada para proteção de usuários de Internet Banking.
Agora criticam até quando acatam boas medidas? pra usuário burro nunca irá existir Internet Banking seguro, nem Internet Banking nem nenhum outro tipo de serviço, pois são facilmente enganados.. ocorrem vários casos como o caso da Bolsa, o caso do Dólar preto onde dizem pintar o dólar para passar na fiscalização e vendem por um preço muito menor.. só que a maioria das notas são falsas. Então, isso não é um problema do Internet Banking e sim da mentalidade das pessoas.
Pra mim, o Internet Banking é a maneira mais segura para movimentação bancária.. faça uma analogia:
Se você for roubado pelo Internet Banking, você pode ir na justiça reclamar o seu direito e na grande maioria dos casos se não em todos, o banco fica obrigado a devolver o dinheiro.. e se fosse na rua? além do risco eminente de perder a sua vida por conta de um marginal armado e muitas vezes drogado, você não terá a quem recorrer para reaver o dinheiro perdido.
Sobre o DNSSEC:
Ele ajuda SIM aos usuários, qual segurança você tem no DNS padrão retornando apenas um IP para sua consulta? agora veja no DNSSEC onde irá trabalhar com chaves confiáveis:
Resposta com DNSSEC
;; AUTHORITY SECTION:
bradesco.b.br. 3600 IN NS ns004.bradesco.com.br.
bradesco.b.br. 3600 IN NS ns001.bradesco.com.br.
bradesco.b.br. 3600 IN TYPE46 \# 161 ( 0002050300000E1049ED0C4448F645FE 93D308627261 646573636F01620262720081FEE5C84BBF94F6C12204 1DB10D8DCE839EBC17DBCD928E6B3A7F725DF044C53F 3894E3C03DFE08D21AFA4A6314C18D9CE4B03E295334 4C77BACD8812BB50E48048A87A86728BA3A6D5DC27F1 A70DFBE9AB2C31B0F4541D0D16D4079C2122FC7E3105 66C7C89CD477AAEF52DF13C8A559CF51231714726BA1
F370BD632DF299 )
===================
Resposta DNS "comum"
;; ANSWER SECTION:
bradesco.com.br. 3600 IN A 200.155.80.15
;; AUTHORITY SECTION:
bradesco.com.br. 3600 IN NS ns001.bradesco.com.br.
bradesco.com.br. 3600 IN NS ns004.bradesco.com.br.
"O único homem que está isento de erro é aquele que não arrisca acertar." (Albert Einstein)
No caso do Internet Banking é uma medida rigososamente inútil. Os bancos já usam HTTP com TLS aka HTTPS que garante a identidade do servidor do banco para o usuário (o que o DNSSEC não faz) e ainda a integridade da comunicação entre eles (o que o DNSSEC também não faz).
O DNSSEC tem outras aplicações onde ele é interesasnte. Para Internet Banking ele é completamente inútil.
Eu não diria "completamente inútil", uma vez que o DNSSEC evita envenenamento de DNS.
__
"Uma pessoa inteligente resolve um problema, um sábio o previne." Albert Einstein
Olha, o DNSSEC previne alguns tipos de envenenamento de cache de DNS. E é exatamente por isso que ele não é completamente inútil.
Ninguém discute isso. O que eu estou dizendo é que cache poisoning não importa se você estiver usando SSL.
Cache poisoning permite que você na prática redirecione a conexão do usuário para um IP que você controla. Só que se você está fazendo autenticação, integridade e encriptação fim-a-fim como no caso do SSL o atacante não consegue fazer nada com isso.
Consegue sim. Ele pode te redirecionar prum IP sob o controle do vagabundo e ele utilizar um certificado auto-assinado.
Já vi muito usuário aceitando certificado auto-assinado quando o browser alerta sobre isso (ainda mais o FireFox, que exibe uma página similar a de erro, alertando o usuário).
__
"Uma pessoa inteligente resolve um problema, um sábio o previne." Albert Einstein
NÃO HÁ COISA ALGUMA DE ERRADO COM CERTIFICADOS AUTO-ASSINADOS.
É responsabilidade do usuário verificar a autenticidade do certificado, e para isso ele pode ESCOLHER CONFIAR em terceiros.
Eu não disse que tem problemas com certeficados auto-assinados, o grande problema é O USUARIO, que aceita tudo que vê pela frente só pela ânsia de querer acessar logo aquele conteudo.
Inclusive o Firefox aumentou os passos para que um certificado de terceiros seja aceito, vc tem que clicar em "Add Exception" e depois em "Confirm Exception" e ainda tem um botão bem claro dizendo "Me tire daqui!".
Como sempre, o usuário é o problema.
__
"Uma pessoa inteligente resolve um problema, um sábio o previne." Albert Einstein
Acho melhor dar uma pesquisada melhor sobre um assunto antes de comentá-lo.
http://registro.br/faq/faq8.html
http://www.rnp.br/newsgen/9801/dnssec.html (Muito bom!)
http://en.wikipedia.org/wiki/DNSSEC
__
"Uma pessoa inteligente resolve um problema, um sábio o previne." Albert Einstein
Só acrescentando:
Site com diversas informações sobre DNSSEC do registro.br
http://registro.br/info/dnssec.html
Tutorial DNSSEC:
ftp://ftp.registro.br/pub/doc/tutorial-dnssec.pdf
Apresentação e Tutorial (para os que tem preguiça de ler pra ficar sabendo do que se trata antes de falar):
Parte 1:
ftp://ftp.registro.br/pub/gter/gter23/videos/mp4/g...
Parte 2:
ftp://ftp.registro.br/pub/gter/gter23/videos/mp4/g...
"O único homem que está isento de erro é aquele que não arrisca acertar." (Albert Einstein)
Quando foi dito "O novo domínio tem um sistema que identifica sites (DNSSEC), valida e reconhece a autenticidade da página antes que o usuário tenha acesso a ela" acredito que o jornalista querida dizer que o DNSEC "garantirá" que o site com com determinado IP é o correto.
E desculpem os colegas, mas dizer que não adianta também é besteira. Grandes bancos E ISPs não gastariam milhares de dólares na mudança de seus servidores e infra-estrutura do DNS para DNSSEC se não fosse uma solução que adicionasse maior segurança a seus sistemas. Quem trabalha com DNS sabe o dinheiro gasto e a mão-de-obra que se emprega numa mudança dessas.
DNSSEC custa milhões de dólares?
Você claramente não vive no mesmo mundo do que eu. Que eu saiba os Bancos investem em qualquer coisa que diminua a responsabilidade deles ou de seus clientes.
Bigode,
Você acha que DNS é só uma máquina linux rodando bind? Uma telefonica da vida possui pelo menos 2 dúzias de servidores tendo redundâncias, e o DNSSEC demanda muito mais do que hoje as empresas tem.
Milhões? Não sei. Alguns milhares para atualizar seus equipamentos é bem capaz.
Qualquer iniciativa que possa melhorar a segurança deve ser considerada!
_____________________________________
Assinatura?
Nem pensar! Nunca entenderiam minha letra, minha sorte e que meu Blog não é manuscrito!
Concordo. De qualquer jeito as pessoas vão cair em golpes, porem, os que sabem que o endereço "b.br" é seguro não vão se arriscar em outros.
ñ vai adiantar nada[3]
------------------------------------------------------------
Não é na nomenclatura que algo irá se resolver. Mas...
Fórum Xavante: Mobilização via internet!
Sinceramente? Ter um domínio padrão para instituições financeiras é pura perfumaria.
A importância da área de TI nos bancos é manter a segurança, minimizar sites e e-mails falsos, disponibilizar acesso a outros browsers além do IE... dentre tantas outras possibilidades para não roubarem o seu e o meu dinheiro depois de um mês de trabalho.
Gabriela Bia
http://www.mercadoemalagueta.com
Usuários querem rapidez e facilidade e, por este motivo, nem observam o que estão fazendo. Assim, continuarão caindo em golpes, pouco importando quantos esquemas de segurança existam.
____________
Abraços!
Palavras Sussurradas
Flickr
Sem tomar partido de nada, vou comentar sobre a questão tecnológica da coisa;
Comunicação criptografada é uma coisa (SSL), resolução de nomes é outra (DNS).
Criptografar uma conexão não impede que o usuário acesse sites que não sejam os verdadeiros, pois o usuário mesmo recebendo avisos que o certificado não é valido e blá, blá, blá, geralmente não vai desconfiar de nada. SSL serve prioritariamente para evitar a captura de informações sensíveis no meio do caminho. Pode ser usado para comprovar a autenticidade de um site, mas não é esse o foco.
No caso do DNSSEC, o comprometimento é assegurar que a consulta de um nome e sua consequente resolução para um IP, só que ao contrário do DNS normal, uma entidade certificadora só lhe entregará o IP resolvido após comprovar que o resolver é autenticado pelos root servers, isto é, o resolver é validado antes. Isso evita que outros DNS´s respondam arbitrariamente, pois do lado do cliente não existe nenhuma método ativo para assegurar que aquele IP/Nome é de fato quem você quer acessar.
Na minha opinião, acredito que por mais técnicas de prevenção que possamos usar, o usuário sempre será o elo mais fraco, porém quanto mais camadas de proteção, ou a combinação de delas, melhor. Segurança nunca é demais.
Linux User #201715
Pode ser usado para comprovar a autenticidade de um site, mas não é esse o foco.
Na verdade é exatamente o contrário. Ele serve primariamente para autenticar o site. A encriptação dos dados é um valor agregado, até mesmo porque não adianta nada encriptar a comunicação se você está falando com quem não devia.
"fcima",
Você está equivocado;
SSL é a sigla de "Secure Sockets Layer" que é um método de conexão criptografada visando assegurar a integridade das informações enviadas e recebidas, evitando que "alguém" capture estas informações no meio do caminho ou altere essa comunicação, e o fato de ser feito por criptografia, evita ou dificulta que alguém intercepte e decifre o que está sendo trafegado. O TLS (Transport Layer Security)segue na mesma linha e como o próprio significado denota, o foco também é assegurar o transporte íntegro de dados, mas não garantir que você está falando com a pessoa certa. Experimente criar um site com algum certificado ssl, mesmo que inválido, você vai conseguir conectar e apesar do aviso que a autenticidade do site não foi validada, você como usuário pode fazer um bypass e continuar acessando o site, embora com a comunicação criptografada. Se o foco fosse validar a autenticidade de um site, não teríamos opção de acessá-lo quando essa validação fosse negativa. Já com o DNSSEC, a proposta é justamente tapar esse buraco que o TLS/SSL deixam.
Uma solução de criptografia de comunicação que de fato faz o que você comenta, são as VPN´s, pois para fechar e/ou estabelecer comunicação, somente o host de destino terá a chave, autenticando assim as duas partes, mas ai alguém pode roubar um certificado... mas ai já é outra história... no meu ponto de vista, o usuário é sempre o elo mais fraco.
Linux User #201715
Todos os dados deveriam circular SOMENTE por ssl, seja com certificados podres ou não. Privacidade é importantissima.
Anderson, não vejo como o DNSSEC pode tapar um buraco que o SSL/TSL deixa, até porque é responsabilidadade de um lado do "túnel" verificar a autenticidade do certificado do outro lado.
Bigode
Todos os dados deveriam circular SOMENTE por ssl, seja com certificados podres ou não. Privacidade é "importantíssima". << Cuidado, aqui vão te apedrejar e sugerir que é um analfabeto funcional por esquecer de colocar um acento... brincadeira!!!
Concordo, também acho que qualquer tráfego deveria ser cifrado, aumentando a dificuldade de um pretenso violador de "correspondências", sim, coloco tráfego de dados puro e email no mesmo balaio, pois violar qualquer tipo de comunicação é o equivalente a abrir uma carta endereçado a outra pessoa.
Anderson, não vejo como o DNSSEC pode tapar um buraco que o SSL/TSL deixa, até porque é responsabilidadade de um lado do "túnel" verificar a autenticidade do certificado do outro lado.
Também concordo e acrescento que o fato de uma entidade garantir antes que você conectou em quem realmente você requisitou a conexão, seria uma camada de segurança complementar ao que o TLS/SSL já oferecem.
Linux User #201715
O DNSSEC, pelo que eu entendi (deve ser menos do que devia, mas tudo bem) protege contra algumas formas de envenenamento de cache. O servidor dns que o usuário usa pode ser comprometido por outras formas.
Also, como a internets não é ideal, e não EXIGE TIRANICAMENTE privacidade e autenticação responsável na camada de transporte em todos as aplicações, tanto o DNSSEC e o SSL/TSL em certas partes do site com certificados assinados por uma patética empresa extorquista não resolvem o problema do usuário imbecil.
Also, quanto aos acentos, nós freetards vamos sempre ter a defesa fabiânica de que os acentos deram algum problema estranho no linux!. Lol.
Bem lembrado, a internet por essência é uma mídia promíscua. As VPN´s são uma alternativa, os links privados uma fortuna e o usuário sempre vai clicar no "veja_minhas_fotos.scr", portanto a imbecilidade do usuário sempre será o elo mais fraco da corrente.
Linux User #201715
A imbecilidade do usuário pode ser facilmente controlada se você desenhar algo que necessite de interação inteligente da parte do usuário, o que vai obrigar o usuário a se educar. Claro que nos resta sempre a solução educativa final. Obtê-la é tão simples quanto remover educação de seu nome.