CentOS - Jun 2016 - https and self signed

On Sat, June 18, 2016 18:39, Gordon Messmer wrote:
> On 06/18/2016 02:49 PM, James B. Byrne wrote:
>> On Fri, June 17, 2016 21:40, Gordon Messmer wrote:
>>> https://letsencrypt.org/2015/11/09/why-90-days.html
>> With respect citing another person's or people's opinion in
support
>> of
>> your own is not evidence in the sense I understand the word to mean.
>
> I'm not interested in turning this in to a discussion on epistemology.
> This is based on the experience (the evidence) of some of the world's
> foremost experts in the field (Akamai, Cisco, EFF, Mozilla, etc).
Really? Then why did you forward your reply a private message to a
public mailing list if not to do exactly what you claim you wish to
avoid?
>
>> The assertion expressed in the link given above that 90-day
>> certificate lives will serve to increase certificate renewal
>> automation is at best a pious hope.
>
> You are ignoring the fact that the tool used to acquire letsencrypt
> certificates automates the entire process.  They're not merely hoping
> that users will automate the process, they're automating it on behalf
> of users.  They've done everything but schedule it for their users.
>
>> One that is unlikely to be
>> realised in my opinion for the simple reason that automated and
>> therefore mostly unobserved security systems are a primary target
>> for tampering.
>
> For someone who wants "evidence" you make a lot of unsupported
> assertions.  You do see the irony, don't you?
The difference is that I state this is my opinion and I do not claim
it as a fact.  Your statement claimed a factual basis.  I was
naturally curious to see what evidence supported your claim.
>
>> Likewise the authors' opinion that pki certificates are in
>> general just casually left laying around to be compromised displays
>> a
>> certain level of what reasonably could be considered elitist
>> contempt
>> for the average human's intelligence.
>
> Or, you know, a review of actual security problems in the real world.
>
>> Even as arguments I find these two positions are less than
>> compelling.
>>   And in no respect could either opinion be considered evidence.
>
> That's fine.  I don't really need to convince you, personally, of
> anything.  But for the security of the internet community in general,
> I'll continue to advocate for secure practices, including pervasive
> security (which means reducing barriers to the use of encryption at
> all points along the process of setup).
>
>
I know, and we put infants on no-fly lists for essentially the same
religious beliefs.  The benefit of so-called general security for the
rest of us who do not have to bear its individual specific cost.  The
is no evidence that this sort of stuff works. It is just done so that
if anything bad happens the authorities can claim that they did
something preventative which they can point to. Regardless of how
ineffectual it was.

Automated security is BS.  It has always been BS and it always will be
BS.  That is my OPINION.  It may not be a fact for I lack empirical
evidence to support it.  However, it has long been my observation that
when people place excessive trust in automation they are are
eventually and inevitably betrayed by it.  Often at enormous cost.

Let me give you an example of stupidity in action with respect to
signed certificates.  I have a MacBookPro c. early 2009.  There have
been five or six major releases of OSX since then.  Being a cautious
type I download the upgrade installer apps and archive them before
installing and upgrading.

Over this past weekend my MB stopped booting.  It would get to the
Apple symbol and go black.  Much trial, error, and research later I
discover that this is sometimes occurs when a MB has been repeatedly
upgraded and that a clean install is the recommended cure.  Oh,
by-the-way, if you ever have to do this then do not use the Apple
Migration Assistant app when you are done.  You will be sorry.

So, I get out my archived Installer app, go to install it and BANG! My
MB proclaims that "Somebody has tampered with the application or it is
corrupted!". OH NO!

This impediment however is strictly an artefact of signing code with
short term certificates.  I simply had to reset the date on my MB back
to some future date when the certificate was valid and everything
worked fine.  Of course this took me a great deal of frustrating
effort to discover what had happened to all of my archived copies and
how to fix it.  In the middle of a system recovery I might add.

But hey, what is my time worth in comparison to the security those
certificates provided?  SECURITY that was trivially evaded in the end.
 Exactly what mindless person or committee of bike-shedders decided
that software should be distributed so that copies of it expire?  What
security issue was addressed by this decision? What benefit to the
public was achieved?

When real people suffer real inconvenience and real loss of productive
effort because of mindless adhesion to bromide based cures that are
blandly offered for ills that mostly exist in the imagination of the
ignorant then yes;  I require evidence of their efficacy.  And lining
up a bunch of band-wagon pundits chanting the same vacuous refrains is
not evidence.

And this one is going to the list.

-- 
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

-- 
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

On Mon, 2016-06-20 at 10:47 -0400, James B. Byrne wrote:

........
> But hey, what is my time worth in comparison to the security those
> certificates provided?  SECURITY that was trivially evaded in the end.
>  Exactly what mindless person or committee of bike-shedders decided
> that software should be distributed so that copies of it expire?  What
> security issue was addressed by this decision? What benefit to the
> public was achieved?
+1.


-- 
Regards,

Paul.
England, EU.      England's place is in the European Union.

On 06/20/2016 07:47 AM, James B. Byrne wrote:
> On Sat, June 18, 2016 18:39, Gordon Messmer wrote:
>
>> I'm not interested in turning this in to a discussion on
epistemology.
>> This is based on the experience (the evidence) of some of the
world's
>> foremost experts in the field (Akamai, Cisco, EFF, Mozilla, etc).
> Really? Then why did you forward your reply a private message to a
> public mailing list if not to do exactly what you claim you wish to
> avoid?
Accidents happen.  I didn't intentionally mail you off-list, and when I 
noticed that I had, seconds later, I re-sent the message to the list, 
expecting that you'd notice and understand that I intended to keep the 
conversation on the list.

..which isn't relevant to the question of what you consider
"evidence"
of security practice implications.

Look, go to https://www.google.com/ right now and tell me what you see.  
Do you suddenly distrust the internet's single largest domain?  Do you 
think they implement poor security practices?
>> For someone who wants "evidence" you make a lot of
unsupported
>> assertions.  You do see the irony, don't you?
> The difference is that I state this is my opinion and I do not claim
> it as a fact.  Your statement claimed a factual basis.  I was
> naturally curious to see what evidence supported your claim.
Citation required.

Allow me an example.  To quote you:
"The usual way a private key gets compromised is by theft or by 
tampering with its generation.  Putting yourself on a hamster wheel of 
constant certificate generation and distribution simply increases the 
opportunities for key theft and tampering."

Now, when you asked "what possible benefit accrues from changing secured 
device keys on a frequent basis?" I pointed you to letsencrypt's 
documentation, which describes the benefits of 90-day certificates.

So, please describe how I am "claiming a factual basis" while you are
not.
> Automated security is BS.  It has always been BS and it always will be
> BS.  That is my OPINION.  It may not be a fact for I lack empirical
> evidence to support it.  However, it has long been my observation that
> when people place excessive trust in automation they are are
> eventually and inevitably betrayed by it.  Often at enormous cost.
This is what I consider "enormous cost":
https://en.wikipedia.org/wiki/Heartbleed#Certificate_renewal_and_revocation

After a major security bug which exposed private keys, hundreds of 
thousands of servers did not take the required action to secure their 
services, and the vast majority of those that took *some* action did it 
incorrectly and did not resolve the problem.

Had those sites been using letsencrypt and renewing automatically, the 
exposed keys would have been replaced within 90 days (typically 60 max, 
so 30 days on average).  Instead, it is likely that the problem will 
remain a risk for "months, if not years, to come."

And that's empirical evidence, which you have yet to offer.
> This impediment however is strictly an artefact of signing code with
> short term certificates.  I simply had to reset the date on my MB back
> to some future date when the certificate was valid and everything
> worked fine.
Apple's intermediate certs have a 10 year lifetime.  If you consider 
that "short term" then I fear that nothing is suitable in your
opinion.
> But hey, what is my time worth in comparison to the security those
> certificates provided?  SECURITY that was trivially evaded in the end.
Fixing your clock is not "evading" security.
> Exactly what mindless person or committee of bike-shedders decided
> that software should be distributed so that copies of it expire?
Expiration is a fundamental aspect of x509 certificates.  Do you 
understand x509 at all?

On Mon, June 20, 2016 19:16, Gordon Messmer wrote:
> On 06/20/2016 07:47 AM, James B. Byrne wrote:
>> Exactly what mindless person or committee of bike-shedders decided
>> that software should be distributed so that copies of it expire?
>
> Expiration is a fundamental aspect of x509 certificates.  Do you
> understand x509 at all?
with all its problems; look just a little bit into the future;
when I sign a document today, the certificate I sign this document maybe
valid till the end of next year (end of the year 2017);
let us think this is an important document; and let us think you were a
young boy now;
in case the software still exists in the next 50 years, the diagnosis if
the document has been modified is easy, but ...
how would you be able to verify that this document hasn't been signed by a
certificate that had been revoked when you are an old man?