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

[Ricardo Panaggio]

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.

-------- 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: OpenPGP digital signature