[conspire] (forw) Re: self-signed certificates
Rick Moen
rick at linuxmafia.com
Thu Dec 3 19:23:19 PST 2020
Offlist query was prompted by this on-list Dng discussion:
https://lists.dyne.org/lurker/message/20201203.213847.8bf66630.en.html
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----
Date: Thu, 3 Dec 2020 19:20:44 -0800
From: Rick Moen <rick at linuxmafia.com>
To: [redacted]
Subject: Re: self-signed certificates
Organization: If you lived here, you'd be $HOME already.
Quoting [redacted]:
> Hi Rick,
>
> I'm in the middle of all this, and the whole certificate thing
> continues to baffle me. I'm not new to Linux, but a bit naive on all
> the "real sysadmin" kind of stuff like this. I've had a Linux box at
> either work or home since Redhat 3.0.3, not REL, actual Redhat, as in
> the 1990's.
>
> I've tried making self-signed certificates, but Chrome (actually
> Brave) still complains about them. This is all internal LAN stuff. I
> don't do anything out in the wild. I'm assuming I'm missing some
> detail, or Chrime [sic] is part of this conspiracy. Internally, I
> don't really care about https, but my Synology's cert isn't accepted
> as valid, so I get nagged when I log in on from the web page, and my
> internal pages also nag me, although I may be dealing with mixed
> metaphors (using outside certificates internally).
>
> Am I missing something (clearly), or is this reality? Any how-to
> references would be appreciated. I think I get the pieces, but not
> the subtle details or the bigger picture.
Hi, [name]. Tell you what: Although I'm unwilling to spend time on this
just for you alone -- no offence, but I don't know you at all, and I
can't spend my small amount of spare time doing free-of-charge private
coaching for strangers -- but I'm willing to write something to post to
my local LUG mailing list, which I'll be doing (omitting your e-mail
address). If you wish to see any follow-up comments, you can find them
here:
http://linuxmafia.com/pipermail/conspire/
I will also suggest that you should think twice before writing offlist
to mailing list members asking for private briefings. This isn't what
mailing lists are for, i.e., this side-discussion doesn't benefit the
community, and it's essentially asking for a private side-favour from
someone who's participating to help the _public_. Anyway....
My hot take:
1. Seriously, read the Michael Orlitzky essay already referred to, and
follow its links where anything is unclear. (That's what they're for.)
http://michael.orlitzky.com/articles/lets_not_encrypt.xhtml
I really mean that. Read it.
2. Yes, of course Google Chrome complains about self-signed certs.
Like all other Web browsers, Google Chrome ships with a CA (certificate
authority) bundle, a set of signing keys for hundreds of CA
organisations all around the world. Any site's SSL cert that is
attested by a CA signature of one of those hundreds of CAs gets the
magic lock icon. Any that isn't, doesn't. Google has gotten more
aggressive than it used to be, in spooking users into being afraid to
visit any site without the magic lock icon. So have several other
browsers.
3. Orlitzky briefly alludes to some of the major reasons why the entire
CA model is unfixably broken. He describes them as "a thousand
murderous theocracies, advertising companies, and international spy
organizations". I would add: Also, some incompetent bunglers and/or
crooks.
As Orlitzky points out, you cannot as a CA customer evade the problem of
skeevy, corrupt, malign, and incompetent CAs by dealing only with a
highly rated one. That would mean only _your_ cert has a gold-standard
attestation chain. But someone wishing to impersonate your site can
still go pay a bit of money to one of the scumsuckers, and your
diligence becomes beside the point: You still will get impersonated,
and users will (wrongly) get the magic lock icon when visiting the
impersonation of your site.
A number of years ago, hapless errors and security failures at a number
of big-name CAs happened, including (from memory) DigiNotar, Comodo,
CNNIC (China), and Symantec(!). I responded by manually removing their
signing keys from my personal Web browsers, so that sites attested to by
them would no longer get their certs blanket-trusted. However, that was
_just me_ doing that, it's a manual, technical operation, and about a
few billion other people care only about whether there's a magic lock
icon or not, not whether it means anything real.
Also, as Orlitzky suggests, the crooks don't go away, nor do the
religious fanatics and the CAs that are captives of hostile intelligence
agencies (including those of the Iranian Islamic Republic, Russian
Federation, and lots of other dodgy states).
The aforementioned essay writer is exactly right:
And, as always with the certificate authorities, a thousand murderous
theocracies, advertising companies, and international spy organizations
are allowed to impersonate you by design.
His link, from there, is to a complete list of all CAs whose public keys
are in a browser bundle. Your browser trusts _all_ of them fully and
interchangeably. Any Web browser at all times. Everyone's Web
browsers. (Well, mine is missing a few, because I deleted them in
annoyance at particular CAs getting caught in particularly bad scandals,
but that's a drop in an ocean.)
As usual, this is an _old_ topic, and so here is my side of some prior
LUG discussions:
Date: Wed, 23 Mar 2011 14:37:40 -0700
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: Critical browser-cerificate problem
Here's a long but fascinating story, the bottom line of which
is that (1) you need to fix your Web browsers immediately so
they will not blithely accept fraudulent SSL certificates for
important Web sites as valid, and (2) it illustrates why the
whole 'trust this site certificate because it's signed by the good guys'
model is snake-oil, and always has been.
(The latter point is not news to those who've been paying attention.
For more, see the relevant chapter in Bruce Schneier's layman-level book
on security, _Beyond Fear_.)
https://blog.torproject.org/category/tags/ssl-tls-ca-tor-certificates-torbrowser
There are Firefox / Seamonkey / etc. updates out.
One of the impersonated Web sites is addons.mozilla.org . (Full list
below.) Those who either attended my Firefox talk at SVLUG, or read my
article on the subject, will remember my stressing reasons why you
should _avoid_ trusting sites like addons.mozilla.org and always if
humanly possible favour distro-mediated software distribution channels
over upstream sources. The current security meltdown is yet another
example of why.
In general, given that Web browsers are stuck using the 'trust it; it's
signed' crypto model, there needs to be a _lot_ more scrutiny of
certificate authorities whose root keys are bundled into browsers, and
also (as the above page stresses) all browsers should hard-fail on
certificate revocation errors. Linux distro package maintainers are the
most likely places for this to happen.
Claimed full list of impersonated site SSL certs, according to 'a
source at Microsoft' mentioned in the article's comments:
o login.live.com
o mail.google.com
o www.google.com
o login.yahoo.com (3 certificates)
o login.skype.com
o addons.mozilla.org
o "Global Trustee"
The unidentfied commentator adds 'I'm not sure what "Global Trustee"
means.'
Certificate authority 'Comodo', where the breach occurred, confirms that list:
http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
Comodo, which was provably negligent, attempts to say 'We're merely a
victim!' Don't look at us. Look at those evil people in Iran.' They
also claim that the system worked because when informed of their screwup
they added the nine fraudulent certs to their current Certification
Revocation List -- a claim the article I mentions in the previous post
is at pains to explain is utter bullshit, as that process doesn't work
in the real world.
Brief analysis by an Iranian commentator:
http://hazimiai.wordpress.com/2011/03/24/firm-points-finger-at-iran-for-ssl-certificate-theft/
Coverage by _Wired's_ 'Threat Level' news-column:
http://www.wired.com/threatlevel/2011/03/comodo-compromise/
The 'Global Trustee' cert was an interesting detail. This was an SSL
cert using an identifying phrase often claimed for itself by ICANN
and by the various operators of the root DNS nameservers. However,
nobody's yet given enough detail (that I've found in a few minutes of
reading, anyway) to do further meaningful analysis.
It should be noted that exploiting the ability to make impersonations of
popular Web sites SSL-validate would require controlling the user's
DNS infrastructure.
Which helps underlie one of my other frequent points: Control your own
DNS infrastructure through the simple expedient of running a local
recursive nameserver, and using it instead of the usual
any-old-service-somewhere-I-don't-know-where.
Date: Mon, 29 Aug 2011 20:38:15 -0700
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: Fraudulent SSL certs for *.google.com from DigiNotar
Hullo, what have we here?
https://blog.mozilla.com/security/2011/08/29/fraudulent-google-com-certificate/
Fraudulent *.google.com Certificate
08.29.11 - 02:59pm
Mozilla was informed today about the issuance of at least one
fraudulent SSL certificate for public websites belonging to Google, Inc.
This is not a Firefox-specific issue, and the certificate has now been
revoked by its issuer, DigiNotar. This should protect most users.
[...]
Because the extent of the mis-issuance is not clear, we are releasing
new versions of Firefox for desktop (3.6.21, 6.0.1, 7, 8, and 9) and
mobile (6.0.1, 7, 8, and 9), Thunderbird (3.1.13, and 6.0.1) and
SeaMonkey (2.3.2) shortly that will revoke trust in the DigiNotar root
and protect users from this attack. We encourage all users to keep their
software up-to-date by regularly applying security updates. Users can
also manually disable the DigiNotar root through the Firefox
preferences.
Preferences, Advanced, Encryption tab, View Certificates. Authorities
tab (showing a scrolling list of Certificate Authorities = CAs whose
signatures of SSL certs Firefox is prepared to trust). Scroll down to
DigiNotar, which has one entry:
Certificate Name Security Device
DigiNotar Root CA Builtin Object Token
Select 'Delete'.
DigiNotar is a CA in the Netherlands. News story:
http://www.theregister.co.uk/2011/08/29/fraudulent_google_ssl_certificate/
Statements issued by Google and Mozilla shortly after this article was
first published indicate a growing mistrust of DigiNotar, which in
January was acquired by VASCO Data Security, a maker of two-factor
tokens and other authentication products.
"While we investigate, we plan to block any sites whose certificates
were signed by DigiNotar," a statement issued by Google announced.
VASCO Data Security is in Illinois.
There are a lot of wild accusations flying about claiming that unstated
Iranian interests produced the phony DigiNotar-attested cert, which
seems completely non-credible. The only thing Iranian in this picture
is the good guy, an Iranian going by the name 'Alibo', who reported the
forgery in a GMail help forum over the weekend.
https://www.google.com/support/forum/p/gmail/thread?tid=2da6158b094b225a&hl=en
However, this incident comes hard on the heels of a CA named Comodo
making a much worse gaffe, attesting to nine fraudulent SSL certs for
such sites as Google, Yahoo, Skype and Microsoft's Hotmail, for which a
pseudonymous Iranian claimed responsibility:
http://pastebin.com/74KXCaEZ
Anyway, more than sufficient reason to delete Commodo's CA entries, too.
More usefully, that's more than sufficient reason to break the habit of
trusting SSL certs just because some goofball firm you've never heard of
signed it for money. Consider CertWatch: http://certwatch.simos.info/
Date: Mon, 29 Aug 2011 23:26:31 -0700
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: Re: [conspire] Fraudulent SSL certs for *.google.com from DigiNotar
[...]
Anyway, my larger point about SSL certs is simply that the whole CA
model is deeply broken. This whole idea that you should believe a
displayed Web site is your bank just because your browser elects to
believe a cert (which is in turn may be because it elects to a
fraudulent cert signed by the likes of Comodo or DigiNotar) has _never_
made sense, but two successive meltdowns have proven that point past all
doubt.
So, I'm saying: _Wake up, people!_ A 'lock' icon is not good enough
reason to trust your credit cards, banking, health records, etc. to a
Web page.
Date: Tue, 30 Aug 2011 15:57:28 -0700
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: Re: [conspire] Fraudulent SSL certs for *.google.com from DigiNotar
Quoting Don Marti (dmarti at zgp.org):
> Yes, you have to make sure it's backed up by Honest
> Achmed's Used Cars and Certificates, right?
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=647959
Almost too close to truth for humour.
I'm sure Honest Achmed would be a fine PKI. If Debian won't have hiim as
a CA, he should just sign up to be a Comodo 'Trusted Partner'
Registration Authority. I hear they'll take anyone.
I like Whisper Systems CTO Moxie Marlinspike's take on the problem
(referenced on LWN):
http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity
Among other things, Moxie explains why the 'Just use DNSSEC' people are
on crack.
Date: Thu, 8 Sep 2011 18:35:23 -0700
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: Comodo-signed bogosity (was: DigiNotar Damage Disclosure)
The two sites' SSL certs Adrien was talking about
(http://linuxmafia.com/pipermail/conspire/2011-September/006596.html)
were:
login.yahoo.com
login.skype.com
He was saying they 'have Google Ltd. as their organization names' as
viewed in his browser.
Calling up https://login.yahoo.com/ and getting Page Info, I see:
Issued To:
Common Name (CN): login.yahoo.com
Organization (O): Yahoo! Inc.
Organizational Unit (OU): <Not Part Of Certificate>
Issued By:
Common Name (CN): DigiCert High Assurance CA-3
Organization (O): DigiCert, Inc.
Organizational Unit (OU): www.digicert.com
Validity:
Issued On: 12/20/2010
Expires On: 01/03/2013
Fingerprints:
SHA1 Fingerprint: 89:0C:0C:65:87:30:4C:43:75:20:B4:81:AA:7B:CC:F2:EE:15:19:54
MD5 Fingerprint: 75:4A:A4:87:70:53:70:5D:4D:1D:15:54:18:3C:FE:EC
Getting 'Details' on that shows the cert as being signed by DigiCert
High Assurance CA-A, which in turn is attested by DigiCert High
Assurance EV Root CA, which in turn is attested by GTE CyberTrest Global
Root, operated by GTE CyberTrust Solutions, Inc.
I have CertWatch installed and operating. CertWatch didn't trigger on
my visit to that URL because for some reason it'd seen that chain of
stuff before.
Calling up https://login.skype.com/ and getting Page Info, I see:
Issued To:
Common Name (CN): *.skype.com
Organization (O): Skype Technologies SA
Organizational Unit (OU): Information Security
Serial: 01:00:00:00:01:2E:BE:AA:C9:F8
Issued By:
Common Name (CN): GlobalSign Organization Validation CA
Organization (O): GlobalSign
Organizational Unit (OU): Organization Validation CA
Validity:
Issued On: 03/16/2011
Expires On: 03/16/2012
Fingerprints:
SHA1 Fingerprint: 17:21:4B:D1:D2:87:E6:E3:BF:1A:1B:4F:96:D8:B2:70:FF:CE:CB:B6
CertWatch _did_ trigger on that site, because I'd not encountered those
before.
I do not see any 'Google Ltd.'
So, in short, I simply did not see the data that Adrien saw popped up by
CertWatch in his own browser. The reason is: I blanket-revoked my
browser's trust in Comodo, after their screw-up of several months ago.
The bogus SSL certificate attestations Adrien saw were (I believe) both
from Comodo's subsidiary Usertrust Network.
Adrien's report about login.skype.com had, in part:
Issued To:
Common Name (CN): login.skype.com
Organization (O): Google, Ltd.
Organizational Unit (OU): Tech Dept.
Serial Number: 00:E9:02:8B:95:78:E4:15:DC:1A:71:0A:2B:88:15:44:47
Issued By:
Common Name (CN): UTN-UserFirst-Hardware
Organization (O): The USERTRUST Network
Organizational Unit (OU): http://www.usertrust.com/
Validity:
Issued On: 3/14/11
Expires On: 3/14/14
Fingerprints:
[omitted; it suffices that these are rubbish]
It's important to note that this was part of the well-known Comodo
screwup of a few months ago. Those cert signatures were revoked and
everyone sent out new browser versions that marked those signatures as
not to be trusted. I suspect that, if Adrien selects "Edit Trust' for
that signature, he will see: 'Do not trust the authenticity of
this certificate'. This is now Firefox works: If you say something in
the chain of SSL certs to intermediate certs to root certs should be
removed, it doesn't _literally_ remove them. It merely marks that thing
as to be disregarded.
[...]
Date: Mon, 19 Sep 2011 17:06:36 -0700
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: Re: [conspire] Oh, Diginotar, no!
Quoting Dire Red (deirdre at deirdre.net):
> Source: http://twitter.com/letoams/status/115905431766958080
>
> "diginotar.nl has a new cert issued by Comodo! It also redirects port
> 443 to port 80! You can't make that shit up!!"
Wow, it's just like walking up Sand Hill Road. All the thieves in a
single spot.
Date: Tue, 18 Oct 2011 13:32:16 -0700
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: Re: [conspire] Oh, Diginotar, no!
Quoting Paul Zander (paulz at ieee.org):
> Article from BBC,
>
> Web commerce hack attack may 'happen again'.
>
> The problem of what to do when certificate issuers were
> compromised never came up when the original work was being
> done on SSL/TLS, said Dr Elgamal.
>
> "Nobody asked the question of what to do if a
> certificate authority turns out to be bad," he said.
>
> Full article at:
> http://www.bbc.co.uk/news/technology-15348821
It's a good article as far as it goes. Two points:
1. Don't expect any prepackaged solution to the problem of unreliable
certificate authorities, for the foreseeable future. _You_ need to
independently be a type of certificate authority. That's my preferred
brand of solution. Personally, I am so far finding it sufficient to run
a browser extension that notifies me whenever an SSL cert or its
attestation has changed. And there are other approaches worth
considering for SSL vetting, such as the Convergence and Monkeysphere
extensions.
2. The bit in the latter paragraphs about upgrades to TLS (to less
gimmick-able later revision TLS 1.2) is correct but of relatively minor
importance. The 'attack' the author refers to isn't really very
practical. In any event, if users leave the warnings about mixed
SSL/non-SSL content enabled (in Firefox: Preferences, Security, Warning
Messages, "I'm about to view an encrypted page that contains some
unencrypted information'), and make sure they understand anything
generating those messages, that attack cannot work at all.
Date: Sun, 26 Mar 2017 19:27:14 -0700
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: Bill numbering; Symantec in the doghouse
[...]
Hey, a couple of years ago, we started seeing breakdown of the worldwide
Certificate Authority (CA) system that even the IT press couldn't
entirely ignore, in the form of epic screwups by CAs Diginotar and
Comodo. Many people including me decided to banish those CAs from our
Web browser bundles.
Well, guess who's in the doghouse now? Symantec!
https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ
Since January 19, the Google Chrome team has been investigating a
series of failures by Symantec Corporation to properly validate
certificates. Over the course of this investigation, the explanations
provided by Symantec have revealed a continually increasing scope of
mis-issuance with each set of questions from members of the Google Chrome
team; an initial set of reportedly 127 certificates has expanded to
include at least 30,000 certificates, issued over a period spanning
several years. This is also coupled with a series of failures following
the previous set of mis-issued certificates from Symantec
(https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html),
causing us to no longer have confidence in the certificate issuance
policies and practices of Symantec over the past several years. To
restore confidence and security of our users, we propose the following
steps:
o A reduction in the accepted validity period of newly issued
Symantec-issued certificates to nine months or less, in order to
minimize any impact to Google Chrome users from any further
mis-issuances that may arise.
o An incremental distrust, spanning a series of Google Chrome releases,
of all currently-trusted Symantec-issued certificates, requiring they
be revalidated and replaced.
o Removal of recognition of the Extended Validation status of Symantec
issued certificates, until such a time as the community can be assured
in the policies and practices of Symantec, but no sooner than one year.
Google announcing that Google Chrome will no longer trust Symantec EV
(extended validation) certs is a pretty major step, folks. Symantec
is an umbrella for GeoTrust, VeriSign, and Thawte certs.
InfoWorld coverage:
http://www.infoworld.com/article/3184482/security/google-to-symantec-we-dont-trust-you-anymore.html
Date: Fri, 11 Mar 2016 07:16:40 -0800
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: Re: [conspire] www.debian.org ... upper right is a box, "Download
Debian 8.3
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 having 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<E2><80><99>s Encrypt CA what it
needs to do in order to prove that it controls example.com. The Let<E2><80><99>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 authenticity 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 confidence 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 particularly 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
re-architecting.
Date: Sat, 12 Mar 2016 18:56:18 -0800
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: Re: [conspire] CA signed certs, and not CA signed ... PGP/GPG
cross-signed? ... Firefox CertificateWatch extension ...
Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
> Yes, I think PGP/GPG signing SSL/TLS certs (be the certs CA signed or
> self-signed) is an *excellent* idea [...]
Also, alas, possibly a somewhat utopian one. And here's why I say that:
The Web of Trust (WoT) model exemplified by PGP / gpg works great,
provided participants are motivated and are willing to participate in
keysignings, so that they have credible trust paths they can use to
vet people and things they don't know personally.
You like the WoT model because it works well (for motivated people).
I like it. The Debian Project likes it. Software developers all over
the world like it.
Because we've done some keysignings.
I believe I used to have a standard techie joke about playing 'Six
degrees of Ted T'so' because the Linux technical community is so
interconnected that we all have PGP trust paths going through Ted T'so.
And I used to have Ted as a co-worker, so my T'so Number (analogous to
an Erdős Number or a Bacon Number) is probably 1.
https://en.wikipedia.org/wiki/Erdős_number
https://en.wikipedia.org/wiki/Six_Degrees_of_Kevin_Bacon
By contrast, J. Random User has never heard of it and isn't likely to
even try. If he/she tries, the guaranteed initial result is total
frustration, because of no usable trust paths. And this is why the
alternative PKI model rules the broader non-developer, non-sysadmin
world, even though its implementation (Certificate Authorities) is
rotten to the core.
So, getting to the point, _even_ if we get a pervasive browser plug-in
that makes WoT attestation of SSL certs seamless, most people would get
failure to find a trust path, most of the time. And so the value
proposition would be non-obvious except to us people with
(metaphorically) low T'so Numbers, i.e., people who actually participate
in keysignings, hence actually have trust paths.
Anyway, there _are_ some schemes for using a semi-seamless WoT model for
Web certs -- including matching browser plug-ins so users don't need to
manually gpg-check hashes. I swear I've seen some. Hold a sec:
http://web.monkeysphere.info/
The Monkeysphere project's goal is to extend OpenPGP's web of trust to
new areas of the Internet to help us securely identify servers we
connect to, as well as each other while we work online. The suite of
Monkeysphere utilities provides a framework to transparently leverage
the web of trust for authentication of TLS/SSL communications through
the normal use of tools you are familiar with, such as your web browser
or secure shell.
Lots of details here:
http://web.monkeysphere.info/FAQ/
I've been totally lame, and have utterly failed to look into, and
experiment with, Monkeysphere Project tools.
Convergence is a less radical, and probably more promising, but still
very clever option that does _not_ abandon PKI entirely, but tries to
tame it:
http://convergence.io/details.html
Convergence is a secure replacement for the Certificate Authority
System. Rather than employing a traditionally hard-coded list of
immutable CAs, Convergence allows you to configure a dynamic set of
Notaries which use network perspective to validate your communication.
Convergence allows you to choose who you want to trust, rather than
having someone else's decision forced on you. You can revise your trust
decisions at any time, so that you're not locked in to trusting anyone
for longer than you want.
Convergence makes it easy for anyone to run their own trust notary.
Each notary can only make security decisions for the clients that have
chosen to trust it -- so the security, integrity, or accuracy of a
notary does not effect those who haven't selected it.
The working assumption behind Convergence is that it's not necessary to
throw out the PKI _concept_, just the clown car of corrupt, incompetent,
and mafioso-and/or-government-suborned jackassess that are the world's CAs.
I've been talking a good game on my Web pages
(http://linuxmafia.com/~rick/faq/kicking.html#linuxbrowser) about how I
_should_ try Convergence and/or Monkeysphere to pioneer cert attestation
that doesn't suck for years, but I haven't done it. So, realism
suggests that for the _near_ future at least, I'm not likely to do much
more than just have a competent self-signed cert, make my Web site use
TLS 1.2 and prevent the use of bad ciphers, make a gpg-signed hash of my
cert available, and continue telling people that the CA system is rotten
to the core and needs to die.
It bothers me that WoT-based alternatives to PKI seem very difficult to
find using Web-searching. That's on the strength of several minutes'
trying. I had to give up and consult my Web pages.
That's either a bad sign for the state of mindshare, _or_ it means that
my brain is sufficiently fried by the Martian Death Flu that I'm not
searching intelligently. (I definitely would not be quick to rule out
the latter.)
Date: Sat, 12 Mar 2016 19:25:48 -0800
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: Re: [conspire] CA signed certs, and not CA signed ... PGP/GPG
cross-signed? ... Firefox CertificateWatch extension ...
[...]
This situation isn't necessarily hopeless. It just requires some good
systems thinking, and some realism about adoption by the general public.
Imagine this: Instead of seeking to junk the PKI scheme entirely, we
phase in measures to tame PKI partially (CertificateWatch, Convergence)
and promote the idea of an SSL-cert trust metric under user control.
In that case, alternative attestation paths like that of Monkeysphere
Project can _at the user's option_ be assigned some fraction of the
local trust weighting. Or not.
That idea came to mind by analogy: In the world of SMTP mail servers,
we have the notion of programmatically estimated 'spamicity'. My
system's MTA uses the local SpamAssassin daemon as framework for
consulting a variety of DNS blocklists, SPF, (in the future) DKIM,
and any other spam-metrics tool I deemed worth consulting. In each
case, the tool SpamAssassin's spamd consults reports back data, and
spamd decided based on my scaling decision how much to adjust the
current arriving mail's estimated spamicity up or down. After each
tool has been consulted, spamd reports back to Exim4 (the MTA) a
composite spamicity score. Exim4 adds that to the results of its own
rulesets, and determines whether or not to accept the arriving mail.
Analogously, a user might give greater or lesser weight to a
Monkeysphere Project trustability number, alongside the opinion of the
PKI infrastructure. User would need to decide what default number
applies when Monkeysphere Project cannot find a trust path. And maybe
other schemes can be likewise included and given weights.
I don't know how practical that is, and (as always) it's easy to talk
ideas without bothering to implement them, but showstopper problems
sometimes emerge when someone actually tries. But it's a model that
could be explored, for whatever that's worth.
----- End forwarded message -----
More information about the conspire
mailing list