[conspire] www.debian.org ... upper right is a box, "Download Debian 8.3" ...

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> Nice ... not a panacea at all, but supporting, or also supporting
> https, generally a good thing (e.g. generally reduce probability of
> Man-In-The-Middle attacks - though it may not do much else).

I meant to mention:  The self-signed SSL cert for linuxmafia.com is now
incrementally far less bad.  I've improved the Apache CipherSuite and
related directives as well as can be done _until_ I upgrade to modern
Apache and OpenSSL versions.  (More the former than the latter, though
you need really recent OpenSSL to get TLS 1.2, which is going to be
really critical, going forward.  Also, although Apache 2.2.x isn't
broken, doing The Right Thing really requires 2.4.x.)

Once I have a satisfactory Apache/OpenSSL software setup, I will put my
full attention on the remainder of that problem -- and that includes
mercilessly culling out weak options so it's not _possible_ to do weak
verification.

FWIW, the biggest single improvement I forced on the cert and its
handling was to finally figure out how to get rid of sha1.  Everyone
needs to do that, this year.  Now is good.

  Why Google is Hurrying the Web to Kill SHA-1
  published by Eric Mill on September 7, 2014
  [...]

https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1


It was annoyingly challenging to track down why I kept getting an
SHA-hashed cert:  Turned out that it's an OpenSSL _default_ (at least,
with the OpenSSL I have).  I was able to tweak /etc/ssl/openssl.cnf to 
make my local OpenSSL components have saner defaults including that one,
_and_ I updated my published 'SSL Certificates, and Self-Signing'
documentation
(http://linuxmafia.com/faq/Security/ssl-cert-self-signed.html) to
explicitly require sha256.



On Let's Encrypt:  

I think it's an extremely well intentioned and competent attempt to prop 
up a hopelessly bad system that needs to just die.  Until that system 
dies, we need to at least do nothing to encourage people to rely on it.
By 'hopelessly bad system', I mean the public CA infrastructure.

I think Let's Encrypt solves the wrong problem.  Someone set out to
solve this problem:  'System admins self-sign primarily because it saves
money and hassle.  The result is sites whose certs cannot be vetted
using conventional CA methods using normal software, and naive users
will face a choice between accepting its https connection despite
displayed warnings that authenticity cannot be verified, which is bad
user acculturation, or declining to use the https version of that site.
It is good public policy to encourage, on both provider and user ends,
the use of strong crypto with verifiable certs.  Our tool will let
system admins deploy a cert that can be vetted from a normal browser CA
bundle, yet will have zero cost and can be issued by a fully automated
signing process.'

Let's look at some of the assumptions in that.


1.  I don't use a self-signed cert because a CA would be too much money
or trouble.  I use one as a gesture of non-confidence in the entire CA
system.  I do _not_ want the public CA infrastructure to be seamless --
because it's unfixably broken.

Assume Let's Encrypt is a jewel among CAs (though I have qualms about
implications of it being automated).  Then, users receiving the genuine
cert from linuxmafia.com are better off it it's attested by Let's
Encrypt, because they'll see the proper lock icon without special steps.
And we all want to encourage users to insist on the proper lock icon, 
because strong auth is good.  Right?

But wait.  Not so fast.  Conditioning users to accept the well-founded
assurance of Let's Encrypt also conditions them to accept a fake
linuxmafia.com cert signed by Comodo, or DigiNotar.

Until April 2015, when it got kicked out of the browser bundle club
for CA breach of trust, CNNIC's attestation of a fake linuxmafia.com 
cert would have resulted in the proper lock icon, too.  Today, the 
same fake attestation by HongKong Post Root, run by the Government of
Hong Kong, which is under the Beijing thumb (thus, really the same
problem as CNNIC) _will_ generate the proper lock icon.

Under the normal user model, the user is lulled into accepting the 
mere lock icon alone.  Attestation can change from hour to hour, as 
the user is flim-flammed by one shady CA after another -- and would
never know.  Visually, the user is going to blandly accept the alleged
cert for my browser being suddenly signed by a CA in Turkey, and then
one in Barcelona, and then one in Japan, and then one in Kazahkstan --
and suspect nothing, because they all show as 'secure'.

I don't wish to support and encourage this model, because the model is
rotten to the core.  You cannot save the model with use of a good CA,
because the addition of a good CA cannot make all the bad ones go away.

Here, brief article illustrating the CA problem:
https://bluebox.com/questioning-the-chain-of-trust-investigations-into-the-root-certificates-on-mobile-devices/


2.  The dichotomy between either havng smooth CA-based attestation
presenting naive users with reliable UI 'lock' feedback and being unable
to vet the cert at all is a false dilemma.  My cert is _not_ unsigned.
It just isn't signed by a CA.

_My_ signature can be deemed verifiable in a variety of ways
out-of-band.  People visiting can note down its hash while visiting my
local LAN.  People who talk to me can verify the hash with me
personally, or on telephone (esp. if they know my voice).  I can post a
gpg-signature of the hash, thereby letting people vet it via PGP chain
of trust.  Lots of other ways, not coming immediately to mind.


3.  I deny the premise that it's good policy to encourage the public to 
rely on strong attestation by CAs -- because of the visual inability to
distinguish a strong attestation by a good CA from one by a bad CA.
Again, fundamentally broken models:  The only thing to do is deprecate
them and work on replacements.  


4.  I deny the premise that an automated CA is A Good Thing.  Yes,
certainly it reduces transaction friction, greatly improves turnaround,
and is necessary if the CA is to be zero cost to sysadmins.  However:  
An automated CA is inescapably one whose vetting of the submitter's 
identity and authority is dodgy.  

https://letsencrypt.org/how-it-works/

  Domain Validation
  [...]
  To kick off the process, the agent asks the Let’s Encrypt CA what it
  needs to do in order to prove that it controls example.com. The Let’s
  Encrypt CA will look at the domain name being requested and issue one or
  more sets of challenges. These are different ways that the agent can
  prove control of the domain. For example, the CA might give the agent a
  choice of either 
  o  Provisioning a DNS record under example.com, or
  o  Provisioning an HTTP resource under a well-known URI on 
  https://example.com/

Getting to authentity and authority:  Let's say someone is a junior 
SA or technical support staffer at large company bigfirm.com that
permits such people to make at least temporary additions to such people
-- or the staffer misappropriates such powers at 3:30am for an hour.
Staffer goes out to Let's Encrypt, requests a cert for bigfirm.com.
CA robot requests FQDN imreal.bigfirm.com and for URI
http://bigfirm.com/imreal to no longer show 404.  Now, our bad guy
when so requested signs a nonce with a keypair.  Cert issued, OK!
Bad guy quickly erases evidence of the dodgy additions.  Elapsed time,
about 15 mins.  Bad guy now sells the believably signed bigfirm.com cert
on the black market.

Point is, it's actually not enough to have confidene that a CA's
attestations relied on the submitter for a bigfirm.com cert be 
J. Random Somebody at BigCo.  Although better than nothing, that is 
not what's required if you take it seriously.  CAs that (claim to) take
it seriously require serious proof, vetted by humans, that the submitter 
has actual authority, and isn't just Some Guy.

In fact, as Bruce Schneier showed in a particularaly damning chapter in
his non-technical book on security, _Beyond Fear_, even CAs often cited
as 'good' and doing extensive human-driven checking, end up delivering
in that department a great deal less than appearances suggest they do.
Please see that book for details.


What do I suggest be done?  For starters, it would be a good idea if
more users take measures within their browsers to curtail the 'any cert
that's signed by anyone is interchangeably good' assumption.  One way to
do that is with the Firefox CertificateWatch extension, which very
simply notifies the user in real time of any cert attestation's change
from what it was before.  In that display, it shows what the old vs. new
attestors were and are.

It would be a _huge_ step forward if users' browsers at least make
visible to users the fact that an https Web site in San Francisco 
suddenly is attested to by a CA in Kazakhstan or Iran or Nigeria, 
because then at least they have an opportunity to wonder why and smell a
rodent.  Under the standard model, they don't.

There are more-radical frameworks to build up a replacement for the
broken CA model, such as several that implement Web of trust in an
automated and smooth fashion.  The beauty of CertificateWatch is that 
it's modest in what it sets out to do (make attestation changes
visible), and does it without breaking anything or requiring
rearchitecting.