Re: https and self signed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux