On Tue, Nov 18, 2014 at 09:40:54PM -0200, Ricardo Panaggio wrote: > Alguém está acompanhando isso? > > Tem gente boa envolvida. Mas é só até aqui que eu cheguei. > > Devemos negar esse CA como todos os outros? Não entendi com clareza, mas > aparentemente esse é tão ruim quanto os outros, no sentido que nada > garante que ele não guarda cópias das chaves privadas, e que elas não > podem ser recuperadas posteriormente por governos. Mas posso não ter ido > fundo o suficiente, e estou atirando a pedra antes de perguntar. >
Há um erro de concepcão aqui. Vou tentar esclarecer e mostrar porque isso não resolve o problema, ou apenas dá uma falsa sensacão de seguranca. Primeiro, a chave privada do site não vai pra CA. Ela recebe uma requisicão que contém a sua chave pública, que ela utiliza para gerar um certificado com a assinatura da CA. No entanto, a CA utiliza a sua própria chave privada para realizar essa assinatura. E essa chave não pode ser jogada fora a cada certificado emitido. Justamente porque o princípio das CAs é que o browser confia automaticamente nos certificados assinados pela CA, utilizando o seu certificado com sua chave pública correspondente que é distribuído junto com o browser ou sistema operacional. Isso quer dizer que podemos respirar aliviados? Sem dúvida, não! O que já aconteceu e esse modelo permite é que a CA emita certificados para o seu site utilizando chaves privadas de um terceiro. Esse terceiro (governo, NSA, atacante, etc.) pode realizar um MITMA contra qualquer usuário de seu site, sem que o usuário perceba, porque o browser não vai emitir qualquer erro. Vai confiar que aquele certificado emitido pela CA é válido. Note que isso independe do seu site já ter um certificado emitido pela mesma CA. Ou seja, mesmo que hoje você não use qualquer certificado, e independente desta nova CA, as CAs que já existem por aí já podem e continuarão podendo emitir certificados para o seu site e para facebook.com, google.com, twitter.com, etc, como já foi feito em alguns países, que conseguiram tais certificados. O modelo de confianca cega nas CAs é quebrado. E essa iniciativa apenas nos cega quanto a esse problema, nos dando a falsa sensacão de seguranca. Abracos. Cascardo. > -------- Forwarded Message -------- > Subject: Compartilho post da Electronic Frontier Foundation: "Launching > in 2015: A Certificate Authority to Encrypt the Entire Web" > Date: Tue, 18 Nov 2014 17:29:34 -0200 > From: [email protected] > To: [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]> > > > > > https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web > > November 18, 2014 | By Peter Eckersley > <https://www.eff.org/about/staff/peter-eckersley> > > > Launching in 2015: A Certificate Authority to Encrypt the Entire Web > > Let's Encrypt logo > > Today EFF is pleased to announce Let’s Encrypt > <https://letsencrypt.org/>, a new certificate authority (CA) initiative > that we have put together with Mozilla, Cisco, Akamai, Identrust, and > researchers at the University of Michigan that aims to clear the > remaining roadblocks to transition the Web from HTTP to HTTPS > <https://www.eff.org/encrypt-the-web>. > > Although the HTTP protocol has been hugely successful, it is inherently > insecure. Whenever you use an HTTP website, you are always vulnerable to > problems, including account hijacking and identity theft > <https://www.eff.org/deeplinks/2010/10/message-firesheep-baaaad-websites-implement>; > surveillance and tracking by governments > <https://www.eff.org/nsa-spying>, companies > <https://www.eff.org/deeplinks/2014/11/verizon-x-uidh>, and both in > concert > <http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/>; > injection of malicious scripts into pages; and censorship that targets > specific keywords > <https://en.wikipedia.org/wiki/List_of_blacklisted_keywords_in_China> or > specific pages > <https://www.eff.org/deeplinks/2008/12/internet-censors-must-be-accountable-things-they-b> > on sites. The HTTPS protocol, though it is not yet flawless, is a vast > improvement on all of these fronts, and we need to move to a future > where every website is HTTPS by default.With a launch scheduled for > summer 2015, the Let’s Encrypt CA will automatically issue and manage > free certificates for any website that needs them. Switching a webserver > from HTTP to HTTPS with this CA will be as easy as issuing one command, > or clicking one button. > > The biggest obstacle to HTTPS deployment has been the complexity, > bureaucracy, and cost of the certificates that HTTPS requires. We’re all > familiar with the warnings and error messages produced by misconfigured > certificates. These warnings are a hint that HTTPS (and other uses of > TLS/SSL <https://en.wikipedia.org/wiki/Transport_Layer_Security>) is > dependent on a horrifyingly complex and often structurally dysfunctional > bureaucracy for authentication. > > example certificate warningLet's Encrypt will eliminate most kinds of > erroneous certificate warnings > > The need to obtain, install, and manage certificates from that > bureaucracy is the largest reason that sites keep using HTTP instead of > HTTPS. In our tests, it typically takes a web developer 1-3 hours to > enable encryption for the first time. The Let’s Encrypt project is > aiming to fix that by reducing setup time to 20-30 seconds. You can help > test and hack on the developer preview of our Let's Encrypt agent > software <https://github.com/letsencrypt/lets-encrypt-preview> or watch > a video of it in action here: > > Let’s Encrypt will employ a number of new technologies to manage secure > automated verification of domains and issuance of certificates. We will > use a protocol we’re developing called ACME > <https://github.com/letsencrypt/acme-spec> between web servers and the > CA, which includes support for new and stronger forms of domain > validation. We will also employ Internet-wide datasets of certificates, > such as EFF’s own Decentralized SSL Observatory > <https://www.eff.org/deeplinks/2012/02/https-everywhere-decentralized-ssl-observatory>, > the University of Michigan’s scans.io <https://scans.io>, and Google's > Certificate Transparency <http://www.certificate-transparency.org/> > logs, to make higher-security decisions about when a certificate is safe > to issue. > > The Let’s Encrypt CA will be operated by a new non-profit organization > called the Internet Security Research Group (ISRG). EFF helped to put > together this initiative with Mozilla and the University of Michigan, > and it has been joined for launch by partners including Cisco, Akamai, > and Identrust. > > /The core team working on the Let's Encrypt CA and agent software > includes James Kasten <https://jdkasten.com/>, Seth Schoen > <https://www.eff.org/about/staff/seth-schoen>, and Peter Eckersley > <https://www.eff.org/about/staff/peter-eckersley> at EFF; Josh Aas > <http://joshaas.net>, Richard Barnes > <https://www.ietf.org/iesg/bio/richard-barnes.html>, Kevin Dick and Eric > Rescorla <http://www.rtfm.com> at Mozilla; Alex Halderman > <https://jhalderm.com> and James Kasten and the University of Michigan./ > > > >
signature.asc
Description: Digital signature
