Re: [lp-br-sp] Fwd: Compartilho post da Electronic Frontier Foundation: "Launching in 2015: A Certificate Authority to Encrypt the Entire Web"

[cascardo]

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:         address@hidden
> To:   address@hidden <address@hidden>,
> address@hidden <address@hidden>, address@hidden
> <address@hidden>, address@hidden <address@hidden>,
> address@hidden <address@hidden>, address@hidden
> <address@hidden>, address@hidden <address@hidden>
> 
> 
> 
> 
> 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