[kwlug-disc] Let's Encrypt out of beta

[Bob Jonkman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hubert wrote:
> The problem here is that the code is a secondary issue.  The
> important part is that their signing key is trusted by the
> browsers, and for obvious reasons, they can't open source their
> signing key.

In fact, the fundamental problem is that the whole PKI system is
inadequate, and probably doesn't achieve its mandate.

Check your browser: Mine has over 120 "trusted" Certificate
Authorities, plus 20 servers that have issued certificates, plus
another 7 in "Others".  Some of those "trusted" CAs are known to have
issued bogus certificates (Comodo, Diginotar). And why should I trust
some CA called "Baltimore" to certify companies like Microsoft,
DigiCert and Verizon?

And I'm using IceCat, which is likely to trust fewer certs and CAs
than, oh, Internet Explorer.

But these Certificate Authorities pay tens of thousands of dollars to
be included in the browsers' "trusted CA" list; what FLOSS browser
provider is going to refuse that revenue stream by turning away
lesser-known companies that claim to be "Certificate Authorities"?

Another big beef of mine is that for self-signed certificates that I
*do* trust, browsers are now throwing up errors that would alarm the
most easygoing web surfers. If anything, self-signed certificates are
more trustworthy than the ones signed by the browser CAs, because
they're likely to be from people I know, who understand enough about
crypto to create their own certs.

Part of the problem is that the current PKI system conflates
'security' with 'authentication'. The current system is pretty good at
providing security: a stream of data that can't be viewed by
third-parties, is unaltered from what was sent, and is from the owner
of the certificate. But this last point is where authentication fails.
We need to take pains to verify the certificate when we first receive
it (TOFU, Trust On First Use), otherwise we're blindly "trusting" the
CA list in the browser.

Hubert is right, DANE is the way to fix this properly. In the
meantime, Monkeysphere, anyone?  http://web.monkeysphere.info/

- --Bob.


DANE:
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities

- --
Bob Jonkman <bjonkman at sobac.com>          Phone: +1-519-635-9413
SOBAC Microcomputer Services             http://sobac.com/sobac/
Software   ---   Office & Business Automation   ---   Consulting
GnuPG Fngrprnt:04F7 742B 8F54 C40A E115 26C2 B912 89B0 D2CC E5EA




On 2016-04-15 03:59 PM, Hubert Chathi wrote:
> On Fri, 15 Apr 2016 14:59:42 -0400, Paul Nijjar via kwlug-disc
> <kwlug-disc at kwlug.org> said:
> 
>> In principle the code is open and available. If there were a
>> bunch of organizations running their own Boulder server CAs then
>> I would be less worried. Maybe this is happening, but I do not
>> know what those other services are. That would be a model that is
>> more robust, in any case.
> 
> The problem here is that the code is a secondary issue.  The
> important part is that their signing key is trusted by the
> browsers, and for obvious reasons, they can't open source their
> signing key.
> 
> If CACert had ever maneged to get their key trusted, I don't know
> if there would have been sufficient motivation for Let's Encrypt.
> 
>> You may be right. Maybe this is FUD. But I think that worrying
>> about this infrastructure for Let's Encrypt is more important
>> than the average unsustainable project, because Let's Encrypt is
>> trying to become a core component of the Web. If Let's Encrypt is
>> successful then a lot of commercial CAs are going to go out of
>> business.
> 
> The big ticket items for commercial CAs are wildcard certificates
> and Extended Verification (EV) certificates, which Let's Encrypt
> doesn't issue.  Let's Encrypt might eat into some of the wildcard
> certificate revenue, but for some organizations, they either *need*
> a wildcard certificate, or it's more cost-effective for them to
> purchase a wildcard instead of getting a Let's Encrypt certificate
> for every host name that they need.  And in fact, there are some
> companies that *only* issue EV certificates, so I don't think the
> CA business is going any time soon.
> 
> But the real solution to basic web encryption isn't Let's Encrypt,
> it's DNSSEC + DANE.
> 
> 
> _______________________________________________ kwlug-disc mailing
> list kwlug-disc at kwlug.org 
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Ensure confidentiality, authenticity, non-repudiability

iEYEARECAAYFAlcRWTAACgkQuRKJsNLM5errNACgsX3XzxfYdq7lcSJFQ0pFah7R
4/oAoLMzhWP63fWYR1i/GAbe03jHDlIV
=vPLv
-----END PGP SIGNATURE-----