Re: [CentOS] https and self signed

[James B. Byrne]

On Mon, June 20, 2016 13:16, Gordon Messmer wrote:
> 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).

I would rather look to Bruce Schneier and Noam Chomsky for guidance
before I would take security advice from organisations that have
already shown to be compromised in the matters of their clients'
security -- the EFF being the sole exception in the list provided.  Or
so I presently believe.

>> 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.
>

Except that I get the list as a digest.  Which means that your
assumptions were wrong.  Funny that think you not?

> ..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.

A snoop that self-signs its own certificates?

> Do you suddenly distrust the internet's single largest domain?  Do you
> think they implement poor security practices?
>

My distrust of Google developed over many years.  There was nothing
sudden about it.  But it is deep now.

>>> For someone who wants "evidence" you make a lot of unsupported
>>> assertions.  You do see the irony, don't you?

I assert my opinions if that is what you are referring to.  I do not
claim them to be fact.  I believe them to be true but I admit readily
that I may be wrong.  Indeed I most certainly must be wrong in some of
them.  My difficulty begin determining which ones.

However, I have formed my opinions on the basis of a long term
exposure to security matters both pre and post Internet.  And I have
seen before the same thoughtless enthusiasms for things shiny and
different in the security community. Things adopted and put into
practice without even the most cursory of trials and evaluations for
effectiveness and efficacy -- not to mention lawfulness on some
occasions --.  Sometimes I have had to deal with the consequences of
those choices at the pointy end of the stick.  Thus if I am to adopt a
different point of view then I require something in the way of
supporting measurable evidence to show that I am wrong and that others
are right.

>> 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.

Having actual software in the possession of users rendered unusable by
a policy decision implemented in the name of security is not
beneficial. Referring to others self-justification of measures they
have already implemented is not evidence. It is argument.  Which has
its place providing that one accepts the fundamental postulates of the
positions being argued. These, in this case, require evidence.
Assertions that these measures solve certain perceived flaws without
addressing the costs of those measures is a one-side argument and not
very convincing in my opinion.

Refusing to deal with that is simply ignoring the elephant in the room.


>
> 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 autom

Re: [CentOS] https and self signed

[Walter H.]

On Wed, June 15, 2016 16:17, Warren Young wrote:
> On Jun 15, 2016, at 7:57 AM, Александр Кириллов 
> wrote:
>>
>> Nowadays it's quite easy to get normal ssl certificates for free. E.g.
>>
>> http://www.startssl.com
>> http://buy.wosign.com/free
>
> Today, I would prefer Let’s Encrypt:
>
>   https://letsencrypt.org/

here is the better alternative for lazy people

https://www.startssl.com/StartEncrypt

its based on the root certificates of StartSSL and automatic as Let's
encrypt;

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

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?


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Gordon Messmer]

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@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Always Learning]

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.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[James B. Byrne]

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 cur

Re: [CentOS] https and self signed

[Always Learning]

On Sat, 2016-06-18 at 19:49 -0500, Valeri Galtsev wrote:

> Which browser do you use? I still am in a process of finding replacement
> for Firefox (the closest is midori, it doesn't fully fill the bill for me
> though).

There is a Mozilla folk called Palemoon by some Europeans (Sweeds, I
think)  http://palemoon.org

I have not tried it.  Finding a suitable browser is difficult. I hate
the spying and privacy-breaching tactics of once-impressive free
browsers.

To use Firefox with all the spyware/privacy-breaching disabled takes
time and effort then the administration of Asus routers does not work
because of something bad in their Java scripts which, despite the
allegation of being Linux based, has Wondoze type .asp web pages.

Just want an easy life where everything works smoothly.


-- 
Regards,

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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Sat, June 18, 2016 6:50 pm, Always Learning wrote:
>
> On Sat, 2016-06-18 at 15:39 -0700, 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).
>
> The same Mozilla Foundation that got USD 50 million from Google some
> years ago and the same Mozilla Foundation that automatically sends URLs
> to Google (the world's biggest spying operation) - questionable safety
> credentials that security conscious administrators might not implicitly
> trust.

Which browser do you use? I still am in a process of finding replacement
for Firefox (the closest is midori, it doesn't fully fill the bill for me
though). With this opinion about Mozilla Foundation you definitely are not
using their Firefox and Thunderbird, right? I have one more constraint: I
need to use it under FreeBSD (these are my laptop and workstation), so I
probably have to be able to build it myself (as, if it is in FreeBSD
ports/packages, I likely already tried it...).

Thanks.
Valeri

>
> I support a DNS record solution for certificate authenticity.
>
>
> --
> Regards,
>
> Paul.
> England, EU.  England's place is in the European Union.
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Always Learning]

On Sat, 2016-06-18 at 15:39 -0700, 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).

The same Mozilla Foundation that got USD 50 million from Google some
years ago and the same Mozilla Foundation that automatically sends URLs
to Google (the world's biggest spying operation) - questionable safety
credentials that security conscious administrators might not implicitly
trust.

I support a DNS record solution for certificate authenticity.


-- 
Regards,

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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Gordon Messmer]

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).



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?



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).

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[James B. Byrne]

On Fri, June 17, 2016 11:06, Walter H. wrote:
> On 17.06.2016 16:46, James B. Byrne wrote:
>> On Thu, June 16, 2016 13:53, Walter H. wrote:
>>> On 15.06.2016 16:17, Warren Young wrote:
   but it also affects the other public CAs: you can’t get a
 publicly-trusted cert for a machine without a publicly-recognized
 and -visible domain name.  For that, you still need to use
 self-signed certs or certs signed by a private CA.

>>> A private CA is the same as self signed;
>>>
>> No it is not.  A private CA is as trustworthy as the organisation
>> that
>> operates it.  No more and not one bit less.
>>
>> We operate a private CA for our domain and have since 2005.  We
>> maintain a public CRL strictly in accordance with our CPS and have
>> our
>> own OID assigned.
> for your understanding: every root CA certificate is self signed;
> any SSL certificate that was signed by a CA not delivered as built-in
> token in a browser is the same as self-signed;
>
>
>

For your understanding, a self-signed certificate is one that has been
signed by itself.  Naturally ALL root certificates are self-signed. 
The self-signed root cert is then used to sign a subordinate CA
issuing cert and that issuing cert is used to sign other subordinate
CAs and / or end-user certs depending upon the permissions given it by
the original signing certificate.  This establishes the certificate
trust chain.

If website presents an actual self-signed cert to Firefox for example,
it will refuse it.  I suppose there is a way to circumvent this
behaviour but I am not aware of it. If you present a certificate that
is not self-signed but is signed by an authority whose root
certificate chain is not in the trusted root store then Firefox gives
you a warning -- as given in a preceding message
'net::ERR_CERT_AUTHORITY_INVALID' --
but it none-the-less allows you to accept the certificate as an
exception and proceed to the website.

If you do not want to get warnings and you trust the issuer then you
can add their issuing CA cert chain to your trusted root certificate
store.

-- 
***  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. Byrnemailto:byrn...@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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Always Learning]

On Sat, 2016-06-18 at 08:20 -0500, Valeri Galtsev wrote:

> On Sat, June 18, 2016 7:52 am, Always Learning wrote:

> >
> > Your connection is not secure
> >
> > The owner of harte-lyne.ca has configured their website improperly. To
> > protect your information from being stolen, Firefox has not connected to
> > this website.

> You too huh?

No !

I get the similar 'Firefox version dependent' message when a new machine
logs-on to a secure web site, on a non-standard port with Internet
access restricted to designated individual IPs.

Instead of paying money for a "proper" certificate to access sensitive
restricted applications on the Internet, I make the certificates - that
is the beauty of being non-Wondoze and using Centos. ;-)


-- 
Regards,

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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 18.06.2016 03:41, Gordon Messmer wrote:

On 06/17/2016 07:56 AM, James B. Byrne wrote:

On Thu, June 16, 2016 14:09, Gordon Messmer wrote:

I doubt that most users check the dates on SSL certificates,
unless they are familiar enough with TLS to understand that
a shorter validity period is better for security.

What evidence do you possess that supports this assertion and would
you care to share it with us?

https://letsencrypt.org/2015/11/09/why-90-days.html

"29% of TLS transactions use ninety-day certificates."
could this statement be a little bit more precise ...

or another thought, if every website contained
this: https://www.track.org/track.png?id=75r75fbbf75hfn";>
and the host 'www.track.org' used a 90day throw-away certificate
then the statement wouldn't say anything,
because nobody said, if it was in connection with explicit wanted TLS 
transactions ...


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Sat, June 18, 2016 7:52 am, Always Learning wrote:
>
> On Fri, 2016-06-17 at 15:56 +0100, Michael H wrote:
>
>> On 17/06/16 15:46, James B. Byrne wrote:
>
>> >
>> > We operate a private CA for our domain and have since 2005.  We
>> > maintain a public CRL strictly in accordance with our CPS and have our
>> > own OID assigned.  Our CPS and CRL together with our active, expired
>> > and revoked certificate inventory is available online at
>> > ca.harte-lyne.ca.  Our CPS states that we will only issue certificates
>> > for our own domain and furthermore we only issue them for equipment
>> > and personnel under our direct control.
>
>
>> https://harte-lyne.ca/
>>
>> net::ERR_CERT_AUTHORITY_INVALID
>
> Your connection is not secure
>
> The owner of harte-lyne.ca has configured their website improperly. To
> protect your information from being stolen, Firefox has not connected to
> this website.
>

You too huh? Did you, guys read what the owner of that domain wrote? I
would suggest to go back to his post, and read the whole piece he wrote,
not just the paragraph you left quoted here. It is instructive. And he
definitely is qualifies to run Certification Authority. And can teach how
to do it. That is what he did in his post.

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Always Learning]

On Fri, 2016-06-17 at 15:56 +0100, Michael H wrote:

> On 17/06/16 15:46, James B. Byrne wrote:

> > 
> > We operate a private CA for our domain and have since 2005.  We
> > maintain a public CRL strictly in accordance with our CPS and have our
> > own OID assigned.  Our CPS and CRL together with our active, expired
> > and revoked certificate inventory is available online at
> > ca.harte-lyne.ca.  Our CPS states that we will only issue certificates
> > for our own domain and furthermore we only issue them for equipment
> > and personnel under our direct control.


> https://harte-lyne.ca/
> 
> net::ERR_CERT_AUTHORITY_INVALID

Your connection is not secure

The owner of harte-lyne.ca has configured their website improperly. To
protect your information from being stolen, Firefox has not connected to
this website.


-- 
Regards,

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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Gordon Messmer]

On 06/16/2016 10:50 PM, Walter H. wrote:

On 16.06.2016 22:02, Gordon Messmer wrote:
Without using a metaphor, please explain exactly who you think will 
not trust these certs, because I have never met these people.

then you know now, that there exist such people ...


Well, one, but I'm hardly going to tailor my security infrastructure to 
one customer.


at least the folks where their security software (antivirus, whatever) 
tells them a problem ... 


And what security software would report a problem with these 
certificates?  (bearing in mind that ~ 30% of all TLS transactions 
involve a 90-day certificate, according to telemetry)

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Gordon Messmer]

On 06/17/2016 08:19 AM, James B. Byrne wrote:

On Thu, June 16, 2016 14:23, Valeri Galtsev wrote:

Oh, this is what he meant: Cert validity period. Though I agree
with you in general (shorter period public key is exposed smaller
chance secret key brute-force discovered),

Like many things that appear to be common-sense these assumptions have
no empirical basis.  A properly generated RSA certificate and key of
sufficient strength -- RSA k>=2048bits -- should provide protection
from brute force attacks for decades if not centuries.


Yes.  The primary concern is theft, not brute forcing.  I would imagine 
that those with the resources to brute-force keys have other ways to 
intercept traffic.



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.


No it doesn't.  If your key/cert pair exists only on the host where it 
is used, then access to that host is required to exfiltrate the key.  If 
an attacker has ongoing access to a host, in order to acquire each key 
as it is generated, then the expiration of the keys is irrelevant with 
respect to the opportunities for theft.  The opportunities are equal for 
both cases of short certificate lives and long certificate lives.


There is, however, a difference if an attacker has only brief access.  
If you shut out an attacker who has taken your key, then a short key 
lifetime returns you to a secure state sooner than a long key lifetime.


In fact, you have the logic of the situation entirely backward.  The 
interaction between the opportunity for theft and the lifetime of the 
certificate is proportional to the remaining lifetime of the certificate 
at the time of the theft.


And remember that theft doesn't necessarily mean the attacker has login 
access.  A recent OpenSSL bug allowed an attacker to read portions of 
memory, and could be used to acquire key material.




Really, unless one has evidence of penetration and theft of
the key store, what possible benefit accrues from changing secured
device keys on a frequent basis?


You aren't always going to have evidence.  Be proactive.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Gordon Messmer]

On 06/17/2016 07:56 AM, James B. Byrne wrote:

On Thu, June 16, 2016 14:09, Gordon Messmer wrote:

I doubt that most users check the dates on SSL certificates,
unless they are familiar enough with TLS to understand that
a shorter validity period is better for security.

What evidence do you possess that supports this assertion and would
you care to share it with us?



https://letsencrypt.org/2015/11/09/why-90-days.html

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Александр Кириллов]

for me I refuse it or in other words, when there is no OCSP response
and I don't get a CRL from the CA
 the SSL-host is blocked;


Forget it, Walter. If you feel it's more secure that way I'm not going 
to waste my time to convince you otherwise. )


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 17.06.2016 22:39, Александр Кириллов wrote:

yes and no, but faking a valid OCSP response that says good instead of
revoked is also possible ...


Could you please provide any proof for that statement? If it were true 
the whole PKI infrastructure should probably be thrown out of the 
window. ) 
question back: is the SHA2 discussion a real security impact or just 
paranoia?


so provide a proof of the following statement:

"using OCSP Stapling is as secure as not using OCSP Stapling"

just think of the "parallel universe" called real life ...

do you believe a car dealer that a used car is ok, or do you want a 
proof by third party?
(here the car dealer is the server and 3rd pardy is the OCSP server or 
CRL provided by the CA)


for me I refuse it or in other words, when there is no OCSP response and 
I don't get a CRL from the CA

 the SSL-host is blocked;


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Александр Кириллов]

yes and no, but faking a valid OCSP response that says good instead of
revoked is also possible ...


Could you please provide any proof for that statement? If it were true 
the whole PKI infrastructure should probably be thrown out of the 
window. )



the primary reason was to prevent problems for connection problems -
or whatever problems - in connection with the OCSP


Sure. I've never said privacy concerns were the main reason.


Security concerns can probably be addressed with reducing update 
interval of issuer-signed OCSP responses. For my free wosign 
certificates ii's 4 days and my understanding is that interval matches 
CRL update policy of the CA.


Per RFC2560 (see nextUpdate below):

2.4  Semantics of thisUpdate, nextUpdate and producedAt

   Responses can contain three times in them - thisUpdate, nextUpdate
   and producedAt. The semantics of these fields are:

   - thisUpdate: The time at which the status being indicated is known
 to be correct
   - nextUpdate: The time at or before which newer information will be
 available about the status of the certificate
   - producedAt: The time at which the OCSP responder signed this
 response.

   If nextUpdate is not set, the responder is indicating that newer
   revocation information is available all the time.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 17.06.2016 19:57, Александр Кириллов wrote:
Then OCSP stapling is the way to go but it could be a real PITA to 
setup for the first time and may not be supported by older browsers 
anyway.



not really, because the same server tells the client that the SSL
certificate is good, as the SSL certificate itself;
these must be independent;


Says who?
the logic; anything you do to reduce problems or to prevent problems 
connecting to SSL sites because

of slow OCSP servers or similar reduces security itself ...
Yes, the OCSP response comes from the same server but it's still 
signed by the issuer CA.
yes and no, but faking a valid OCSP response that says good instead of 
revoked is also possible ...
OCSP stapling has been developed for a number of reasons including 
user privacy concerns and I find those reasons quite convincing.
the primary reason was to prevent problems for connection problems - or 
whatever problems - in connection with the OCSP
The need to revoke an issued certificate before its expiration date is 
rare.

maybe; but Heartbleed showed us something different ...;

Yet the origial OCSP implementation gives the interested third parties 
the ability to track browsing habits of unsuspecting visitors of the 
sites which do not implement OCSP stapling. This is not to mention 
much higher traffic the CAs will have to shoulder with the 
proliferation of secure sites.


of course; if there would be only one CA, and there would be only SSL, 
this CA would know what hosts you connect in your browser, because of 
OCSP ...


but the privacy concerns in this connections is less than the tracking 
cookies where a little bit more of information is sent ...
(with OCSP they know only which IP address is verifying which 
certificate and what time)


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Александр Кириллов]

Then OCSP stapling is the way to go but it could be a real PITA to 
setup for the first time and may not be supported by older browsers 
anyway.



not really, because the same server tells the client that the SSL
certificate is good, as the SSL certificate itself;
these must be independent;


Says who? Yes, the OCSP response comes from the same server but it's 
still signed by the issuer CA. OCSP stapling has been developed for a 
number of reasons including user privacy concerns and I find those 
reasons quite convincing. The need to revoke an issued certificate 
before its expiration date is rare. CA error, transfer of the domain 
ownership, loss of a private key... What else? Yet the origial OCSP 
implementation gives the interested third parties the ability to track 
browsing habits of unsuspecting visitors of the sites which do not 
implement OCSP stapling. This is not to mention much higher traffic the 
CAs will have to shoulder with the proliferation of secure sites.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Fri, June 17, 2016 10:19 am, James B. Byrne wrote:
>
> On Thu, June 16, 2016 14:23, Valeri Galtsev wrote:
>>
>> On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote:
>>>
>>> I doubt that most users check the dates on SSL certificates,
>>> unless they are familiar enough with TLS to understand that
>>> a shorter validity period is better for security.
>>
>> Oh, this is what he meant: Cert validity period. Though I agree with
you in general (shorter period public key is exposed smaller chance
secret key brute-force discovered),
>
> Like many things that appear to be common-sense these assumptions have
no empirical basis.  A properly generated RSA certificate and key of
sufficient strength -- RSA k>=2048bits -- should provide protection from
brute force attacks for decades if not centuries. 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.
>
> Keys issued to individuals certainly should have short time limits on
them.  In the same way that user accounts on systems should always have
a near term expiry date set.  People are careless.  And their
motivations are subject to change.

James, though in general one is likely to agree with this, I still
consider the conclusion I came to after discussions more than decade ago
valid for myself. Namely: forcing everyone to change password often sets
careful people off for nothing. Passwords they create and carefully keep
can stand for decades, and only can be compromised on some compromised
machine. Now, from my (careful person) point of view, US National labs
forcing me change password every 6 Months is just confirming the fact they
imply their boxes are compromised often. As: my passwords (passphrases)
are different everywhere, and I only connect one way ever: from trusted
(maintained by me that is) machine to untrusted (maintained by someone
else that is). Never from untrusted machine elsewhere.

Now, simple argument we had: if you force person to change password often,
even worse thing will happen: person will never remember ever changing
password and the last will be written on a piece of paper stuck to the
back of the screen or similar. Yes, I know about and I do use encrypted
storage dedicated for passwords. Does everybody? Things change but people
don't (almost don't).

So, the best bet for multi-user machine is to run it under assumption that
bad guys are already inside. Occasionally you see them attempting
elevation of privileges, smash them, and make the user whose password was
stolen change that, and change all his/her passwords everywhere, banks and
other $$$ accounts first. After this sort of exercise this same person
never is the one in this same sort of trouble. Yes I had these cases, not
many during last decade and a half. I also have seen an opposite attitude
on occasion (user didn't care his password was compromised on machine I
administer), then that user had all [bad] what sysadmin can get him...


> So having a guillotine date on a
> personal certificate makes sense from an administrative standpoint. One
wants to fail safe.  But modifying certificates on sealed
> servers?.  Really, unless one has evidence of penetration and theft of
the key store, what possible benefit accrues from changing secured
device keys on a frequent basis?

My point exactly. Only I usually try to say it in so short way, that my
point fails to propagate to readers ;-(

>
> We mainly use 4096bit keys which will be secure from brute force until
the advent of Quantum computing. At which point brute force attacks will
become a pointless worry.  Not because the existing RSA
> certificates and keys will withstand those attacks but because the
encryption process itself will move onto quantum devices.  That
> development, if and when it occurs, will prove more than the code
breakers will ever be able to handle.  Of course then one must worry
about the people who build the devices.  But we all have to do that
already.  Bought any USB devices from China recently?

Well, I started to avoid Lenovo after they shipped laptop with malware
preinstalled. It took them some time after they bought laptop line from
IBM. But yes, firmware/microcode malware is something that will bite us
soon.

BTW, the secret known to two people is not a secret Who said that?

Cheers,
Valeri

>
> --
> ***  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. Byrnemailto:byrn...@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
>



Valeri Galtsev
Sr System Administrator
Department of Astronom

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Fri, June 17, 2016 9:56 am, Michael H wrote:
> On 17/06/16 15:46, James B. Byrne wrote:
>> On Thu, June 16, 2016 13:53, Walter H. wrote:
>>> On 15.06.2016 16:17, Warren Young wrote:
  but it also affects the other public CAs: you can’t get a
 publicly-trusted cert for a machine without a publicly-recognized and
-visible domain name.  For that, you still need to use
 self-signed certs or certs signed by a private CA.
>>> A private CA is the same as self signed;
>> No it is not.  A private CA is as trustworthy as the organisation that
operates it.  No more and not one bit less.
>> We operate a private CA for our domain and have since 2005.  We
maintain a public CRL strictly in accordance with our CPS and have our
own OID assigned.  Our CPS and CRL together with our active, expired
and revoked certificate inventory is available online at
>> ca.harte-lyne.ca.  Our CPS states that we will only issue certificates
for our own domain and furthermore we only issue them for equipment and
personnel under our direct control.
>> In a few years DANE is going to destroy the entire market of 'TRUSTED'
root CA's  -- because really none of them are trust 'worthy' --.  And
that development is long overdue.  When we reach that point many
domains, if not most, will have their DNS forward zones providing TLSA
RRs for their domain CA certificates and signatures.  And most of those
that do this are going to be running their own private CA's simply to
maintain control of their certificates.
>> Our DNS TLSA flags tell those that verify using DANE that our private
CA is the only authority that can issue a valid certificate for
harte-lyne.ca and its sub-domains.  Compare that to the present case
wherein any 'trusted' CA can issue a certificate for any domain
whatsoever; whether they are authorised by the domain owner or not[1].
>>  So in a future with DANE it will be possible to detect when an
>> apparently 'valid' certificate is issued by a rogue CA.
>> The existing CA structure could not have been better designed for
exploitation by special interests.  It has been and continues to be so
exploited.
>> Personally I distrust every one of the preloaded root CAs shipped with
Firefox by manually removing all of their trust flags. I do the same
with any other browser I use.  I then add back in those trusts
>> essential for my browser operation as empirical evidence warrants. So I
must trust certain DigiCert certificates for GitHub and
>> DuckDuckGo, GeoTrust for Google, COMODO for Wikipedia, and so forth.
These I set the trust flags for web services only.  The rest can go
pound salt as we used to say.
>> [1]
>> https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/
>
>
> https://harte-lyne.ca/
>
> net::ERR_CERT_AUTHORITY_INVALID
>

Michael, no offense intended, but I really would suggest to do some
reading instead of quoting what web browser tells you here. James gives
excellent explanations, and all of them are extremely instructive. But one
really needs to do a bit of reading to follow them. In a nut shell: what
James described is exactly as the CA authorities operate with slight
difference: propagation of private CA trust to clients.

Again, please, do some reading on the subject and then re-read what James
posted. Please, do not take it as offense, James' write up is really
instructive, everyone of us who ever run own Certification Authority will
attest to that.

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247





___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[James B. Byrne]

On Thu, June 16, 2016 14:23, Valeri Galtsev wrote:
>
> On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote:
>>
>> I doubt that most users check the dates on SSL certificates,
>> unless they are familiar enough with TLS to understand that
>> a shorter validity period is better for security.
>
> Oh, this is what he meant: Cert validity period. Though I agree
> with you in general (shorter period public key is exposed smaller
> chance secret key brute-force discovered),

Like many things that appear to be common-sense these assumptions have
no empirical basis.  A properly generated RSA certificate and key of
sufficient strength -- RSA k>=2048bits -- should provide protection
from brute force attacks for decades if not centuries. 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.

Keys issued to individuals certainly should have short time limits on
them.  In the same way that user accounts on systems should always
have a near term expiry date set.  People are careless.  And their
motivations are subject to change.  So having a guillotine date on a
personal certificate makes sense from an administrative standpoint.
One wants to fail safe.  But modifying certificates on sealed
servers?.  Really, unless one has evidence of penetration and theft of
the key store, what possible benefit accrues from changing secured
device keys on a frequent basis?

We mainly use 4096bit keys which will be secure from brute force until
the advent of Quantum computing. At which point brute force attacks
will become a pointless worry.  Not because the existing RSA
certificates and keys will withstand those attacks but because the
encryption process itself will move onto quantum devices.  That
development, if and when it occurs, will prove more than the code
breakers will ever be able to handle.  Of course then one must worry
about the people who build the devices.  But we all have to do that
already.  Bought any USB devices from China recently?

-- 
***  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. Byrnemailto:byrn...@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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 17.06.2016 16:46, James B. Byrne wrote:

On Thu, June 16, 2016 13:53, Walter H. wrote:

On 15.06.2016 16:17, Warren Young wrote:

  but it also affects the other public CAs: you can’t get a
publicly-trusted cert for a machine without a publicly-recognized
and -visible domain name.  For that, you still need to use
self-signed certs or certs signed by a private CA.


A private CA is the same as self signed;


No it is not.  A private CA is as trustworthy as the organisation that
operates it.  No more and not one bit less.

We operate a private CA for our domain and have since 2005.  We
maintain a public CRL strictly in accordance with our CPS and have our
own OID assigned.

for your understanding: every root CA certificate is self signed;
any SSL certificate that was signed by a CA not delivered as built-in 
token in a browser is the same as self-signed;



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Michael H]

On 17/06/16 15:46, James B. Byrne wrote:
> 
> On Thu, June 16, 2016 13:53, Walter H. wrote:
>> On 15.06.2016 16:17, Warren Young wrote:
>>>  but it also affects the other public CAs: you can’t get a
>>> publicly-trusted cert for a machine without a publicly-recognized
>>> and -visible domain name.  For that, you still need to use
>>> self-signed certs or certs signed by a private CA.
>>>
>> A private CA is the same as self signed;
>>
> 
> No it is not.  A private CA is as trustworthy as the organisation that
> operates it.  No more and not one bit less.
> 
> We operate a private CA for our domain and have since 2005.  We
> maintain a public CRL strictly in accordance with our CPS and have our
> own OID assigned.  Our CPS and CRL together with our active, expired
> and revoked certificate inventory is available online at
> ca.harte-lyne.ca.  Our CPS states that we will only issue certificates
> for our own domain and furthermore we only issue them for equipment
> and personnel under our direct control.
> 
> In a few years DANE is going to destroy the entire market of 'TRUSTED'
> root CA's  -- because really none of them are trust 'worthy' --.  And
> that development is long overdue.  When we reach that point many
> domains, if not most, will have their DNS forward zones providing TLSA
> RRs for their domain CA certificates and signatures.  And most of
> those that do this are going to be running their own private CA's
> simply to maintain control of their certificates.
> 
> Our DNS TLSA flags tell those that verify using DANE that our private
> CA is the only authority that can issue a valid certificate for
> harte-lyne.ca and its sub-domains.  Compare that to the present case
> wherein any 'trusted' CA can issue a certificate for any domain
> whatsoever; whether they are authorised by the domain owner or not[1].
>  So in a future with DANE it will be possible to detect when an
> apparently 'valid' certificate is issued by a rogue CA.
> 
> The existing CA structure could not have been better designed for
> exploitation by special interests.  It has been and continues to be so
> exploited.
> 
> Personally I distrust every one of the preloaded root CAs shipped with
> Firefox by manually removing all of their trust flags. I do the same
> with any other browser I use.  I then add back in those trusts
> essential for my browser operation as empirical evidence warrants.  
> So I must trust certain DigiCert certificates for GitHub and
> DuckDuckGo, GeoTrust for Google, COMODO for Wikipedia, and so forth.
> These I set the trust flags for web services only.  The rest can go
> pound salt as we used to say.
> 
> 
> [1]
> https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/
> 


https://harte-lyne.ca/

net::ERR_CERT_AUTHORITY_INVALID

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[James B. Byrne]

On Thu, June 16, 2016 13:53, Walter H. wrote:
> On 15.06.2016 16:17, Warren Young wrote:
>>  but it also affects the other public CAs: you can’t get a
>> publicly-trusted cert for a machine without a publicly-recognized
>> and -visible domain name.  For that, you still need to use
>> self-signed certs or certs signed by a private CA.
>>
> A private CA is the same as self signed;
>

No it is not.  A private CA is as trustworthy as the organisation that
operates it.  No more and not one bit less.

We operate a private CA for our domain and have since 2005.  We
maintain a public CRL strictly in accordance with our CPS and have our
own OID assigned.  Our CPS and CRL together with our active, expired
and revoked certificate inventory is available online at
ca.harte-lyne.ca.  Our CPS states that we will only issue certificates
for our own domain and furthermore we only issue them for equipment
and personnel under our direct control.

In a few years DANE is going to destroy the entire market of 'TRUSTED'
root CA's  -- because really none of them are trust 'worthy' --.  And
that development is long overdue.  When we reach that point many
domains, if not most, will have their DNS forward zones providing TLSA
RRs for their domain CA certificates and signatures.  And most of
those that do this are going to be running their own private CA's
simply to maintain control of their certificates.

Our DNS TLSA flags tell those that verify using DANE that our private
CA is the only authority that can issue a valid certificate for
harte-lyne.ca and its sub-domains.  Compare that to the present case
wherein any 'trusted' CA can issue a certificate for any domain
whatsoever; whether they are authorised by the domain owner or not[1].
 So in a future with DANE it will be possible to detect when an
apparently 'valid' certificate is issued by a rogue CA.

The existing CA structure could not have been better designed for
exploitation by special interests.  It has been and continues to be so
exploited.

Personally I distrust every one of the preloaded root CAs shipped with
Firefox by manually removing all of their trust flags. I do the same
with any other browser I use.  I then add back in those trusts
essential for my browser operation as empirical evidence warrants.  
So I must trust certain DigiCert certificates for GitHub and
DuckDuckGo, GeoTrust for Google, COMODO for Wikipedia, and so forth.
These I set the trust flags for web services only.  The rest can go
pound salt as we used to say.


[1]
https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/

-- 
***  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. Byrnemailto:byrn...@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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 17.06.2016 16:27, Александр Кириллов wrote:

Walter H. писал 2016-06-16 22:54:

On 16.06.2016 21:42, Александр Кириллов wrote:


I don't think OCSP is critical for free certificates suitable for 
small businesses and personal sites.



this is philosophy;

I'd say when you do it then do it good, else don't do it;


Then OCSP stapling is the way to go but it could be a real PITA to 
setup for the first time and may not be supported by older browsers 
anyway.


not really, because the same server tells the client that the SSL 
certificate is good, as the SSL certificate itself;

these must be independent;

Walter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Александр Кириллов]

Walter H. писал 2016-06-16 22:54:

On 16.06.2016 21:42, Александр Кириллов wrote:

that is right, but hink of your potential clients, because
wosign has a problem - slow OCSP, ...
because their server infrastucture is located in China, and not the
best bandwidth ...

when validity checks of the used SSL certificate very probable fail,
it is worse than not using SSL ...


I don't think OCSP is critical for free certificates suitable for 
small businesses and personal sites.



this is philosophy;

I'd say when you do it then do it good, else don't do it;


Then OCSP stapling is the way to go but it could be a real PITA to setup 
for the first time and may not be supported by older browsers anyway.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 16.06.2016 22:02, Gordon Messmer wrote:
Without using a metaphor, please explain exactly who you think will 
not trust these certs, because I have never met these people.

then you know now, that there exist such people ...
at least the folks where their security software (antivirus, whatever) 
tells them a problem ...



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Thu, June 16, 2016 3:00 pm, Gordon Messmer wrote:
> On 06/16/2016 11:23 AM, Valeri Galtsev wrote:
>> as the one who has to handle quite a
>> few certificates, I only will go with certificates valid for a year,
>> ...do I miss something?).
>
>
> Yes.  The tool that creates certificate/key pairs, submits the CSR, and
> installs the certificate is intended to be fully automated.  In
> production, you should be running it as an automatic job.

Should I? Ooops. Not this, please. I do trust more myself installing it
manually, and testing results than my buggy scripts or external tools
alike (and the ability of these to keep up with possible changes on
Certification Authority interface side).

>
> As someone who handles a lot of certificates, I can't imagine why I'd
> want any other CA to handle my certs (excluding the EV certs).

And here we are on the same page...

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Gordon Messmer]

On 06/16/2016 11:50 AM, Walter H. wrote:
technically there is more: not the user needs to check the dates a SSL 
certificate is valid;


just compare it with real life:  which salesman would you trust more - 
the one that gets a new car every few years, which has the same 
advertisings on it and maybe has the same color, or the other one that 
gets nearly every month a new car, which looks totally different, 
other color and other advertisings on it? (and its not a car dealer) 



Your metaphor is extremely strained, and completely unnecessary. It 
doesn't relate to the reality of certificates in any way.


Without using a metaphor, please explain exactly who you think will not 
trust these certs, because I have never met these people.




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Gordon Messmer]

On 06/16/2016 11:23 AM, Valeri Galtsev wrote:

as the one who has to handle quite a
few certificates, I only will go with certificates valid for a year,
...do I miss something?).



Yes.  The tool that creates certificate/key pairs, submits the CSR, and 
installs the certificate is intended to be fully automated.  In 
production, you should be running it as an automatic job.


As someone who handles a lot of certificates, I can't imagine why I'd 
want any other CA to handle my certs (excluding the EV certs).


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 16.06.2016 21:42, Александр Кириллов wrote:

that is right, but hink of your potential clients, because
wosign has a problem - slow OCSP, ...
because their server infrastucture is located in China, and not the
best bandwidth ...

when validity checks of the used SSL certificate very probable fail,
it is worse than not using SSL ...


I don't think OCSP is critical for free certificates suitable for 
small businesses and personal sites.



this is philosophy;

I'd say when you do it then do it good, else don't do it;
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Александр Кириллов]

that is right, but hink of your potential clients, because
wosign has a problem - slow OCSP, ...
because their server infrastucture is located in China, and not the
best bandwidth ...

when validity checks of the used SSL certificate very probable fail,
it is worse than not using SSL ...


I don't think OCSP is critical for free certificates suitable for small 
businesses and personal sites.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 16.06.2016 20:09, Gordon Messmer wrote:

On 06/16/2016 10:53 AM, Walter H. wrote:
lets encrypt only trusts for 3 months; would you really except in an 
onlineshop, someone trusts this shop?
let us think something like this: "when the CA only trusts for 3 
months, how should I trust for a longer period

which is important for warranty ..."


I doubt that most users check the dates on SSL certificates, unless 
they are familiar enough with TLS to understand that a shorter 
validity period is better for security. 
technically there is more: not the user needs to check the dates a SSL 
certificate is valid;


just compare it with real life:  which salesman would you trust more - 
the one that gets a new car every few years,
which has the same advertisings on it and maybe has the same color, or 
the other one that gets nearly every month
a new car, which looks totally different, other color and other 
advertisings on it?

(and its not a car dealer)

the same its with SSL certificates; so you have to find the golden 
middle way, as long as enough without loosing the security

and not too short to prevent not to get trust;

Walter

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[m . roth]

Valeri Galtsev wrote:
>
> On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote:
>> On 06/16/2016 10:53 AM, Walter H. wrote:
>>> lets encrypt only trusts for 3 months; would you really except in an
>>> onlineshop, someone trusts this shop?
>>> let us think something like this: "when the CA only trusts for 3
>>> months, how should I trust for a longer period
>>> which is important for warranty ..."
>>
>> I doubt that most users check the dates on SSL certificates, unless they
>> are familiar enough with TLS to understand that a shorter validity
>> period is better for security.
>
> Oh, this is what he meant: Cert validity period. Though I agree with you
> in general (shorter period public key is exposed smaller chance secret key
> brute-force discovered), logistically as the one who has to handle quite a
> few certificates, I only will go with certificates valid for a year, or
> better 2 years. Given a bandwidths and ciphers these certificates still
> can provide necessary security (I exclude here such things like server
> system compromises which have nothing to do with the time the server
> exists or certificate lives on the server - do I miss something?).

There is also what use is being made of it. For internal dev websites, for
example, not available to the outside world, I create self-signed for one
length of time... ten years. By that time, the project, if it's still
around, will have gone other ways.

  mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote:
> On 06/16/2016 10:53 AM, Walter H. wrote:
>> lets encrypt only trusts for 3 months; would you really except in an
>> onlineshop, someone trusts this shop?
>> let us think something like this: "when the CA only trusts for 3
>> months, how should I trust for a longer period
>> which is important for warranty ..."
>
> I doubt that most users check the dates on SSL certificates, unless they
> are familiar enough with TLS to understand that a shorter validity
> period is better for security.

Oh, this is what he meant: Cert validity period. Though I agree with you
in general (shorter period public key is exposed smaller chance secret key
brute-force discovered), logistically as the one who has to handle quite a
few certificates, I only will go with certificates valid for a year, or
better 2 years. Given a bandwidths and ciphers these certificates still
can provide necessary security (I exclude here such things like server
system compromises which have nothing to do with the time the server
exists or certificate lives on the server - do I miss something?).

Just my $0.02

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Thu, June 16, 2016 12:53 pm, Walter H. wrote:
> On 15.06.2016 16:17, Warren Young wrote:
>> On Jun 15, 2016, at 7:57 AM, Александр
>> Кириллов  wrote:
>>> Nowadays it's quite easy to get normal ssl certificates for free. E.g.
>>>
>>> http://www.startssl.com
>>> http://buy.wosign.com/free
>> Today, I would prefer Let’s Encrypt:
>>
>>https://letsencrypt.org/
>>
>> It is philosophically aligned with the open source software world,
>> rather than act as bait for a company that would prefer to sell you a
>> cert instead.
>>
>> I’m only aware of one case where you absolutely cannot use Let’s
>> Encrypt,
> there is more than one case; just think of trust;
>
> lets encrypt only trusts for 3 months;

Could you elaborate on that?

Thanks.
Valeri

 would you really except in an
> onlineshop, someone trusts this shop?
> let us think something like this: "when the CA only trusts for 3 months,
> how should I trust for a longer period
> which is important for warranty ..."
>
>>   but it also affects the other public CAs: you can’t get a
>> publicly-trusted cert for a machine without a publicly-recognized and
>> -visible domain name.  For that, you still need to use self-signed
>> certs or certs signed by a private CA.
> A private CA is the same as self signed;
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Gordon Messmer]

On 06/16/2016 10:53 AM, Walter H. wrote:
lets encrypt only trusts for 3 months; would you really except in an 
onlineshop, someone trusts this shop?
let us think something like this: "when the CA only trusts for 3 
months, how should I trust for a longer period

which is important for warranty ..."


I doubt that most users check the dates on SSL certificates, unless they 
are familiar enough with TLS to understand that a shorter validity 
period is better for security.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 15.06.2016 15:57, Александр Кириллов wrote:

Nowadays it's quite easy to get normal ssl certificates for free. E.g.

http://www.startssl.com
http://buy.wosign.com/free

that is right, but hink of your potential clients, because
wosign has a problem - slow OCSP, ...
because their server infrastucture is located in China, and not the best 
bandwidth ...


when validity checks of the used SSL certificate very probable fail,
it is worse than not using SSL ...

Walter

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 15.06.2016 16:17, Warren Young wrote:

On Jun 15, 2016, at 7:57 AM, Александр Кириллов  wrote:

Nowadays it's quite easy to get normal ssl certificates for free. E.g.

http://www.startssl.com
http://buy.wosign.com/free

Today, I would prefer Let’s Encrypt:

   https://letsencrypt.org/

It is philosophically aligned with the open source software world, rather than 
act as bait for a company that would prefer to sell you a cert instead.

I’m only aware of one case where you absolutely cannot use Let’s Encrypt,

there is more than one case; just think of trust;

lets encrypt only trusts for 3 months; would you really except in an 
onlineshop, someone trusts this shop?
let us think something like this: "when the CA only trusts for 3 months, 
how should I trust for a longer period

which is important for warranty ..."


  but it also affects the other public CAs: you can’t get a publicly-trusted 
cert for a machine without a publicly-recognized and -visible domain name.  For 
that, you still need to use self-signed certs or certs signed by a private CA.

A private CA is the same as self signed;


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Warren Young]

On Jun 15, 2016, at 10:40 AM, Valeri Galtsev  wrote:
> 
> Thanks, that means no need to install CA. There is always someone (Thanks,
> Warren!) who looked deeper into things, and can explain them.

I claimed that the topic fills books.  That wasn’t an exaggeration.  Back in 
1997, I read the first edition of this thick tome:

  http://shop.oreilly.com/product/9780596000455.do

The second edition is about 50% bigger, and it’s about 15 years old now, so it 
could probably be 1,000 pages and still not cover everything about the modern 
Internet PKI.

I’m not sure I could recommend a book that old in a field that still changes as 
much as web security does.  Perhaps someone else could recommend something more 
current.

> I need to look deeper myself how the identity of the server
> is ensured in this case

As I said in a prior email, there are different grades of certificate.  I 
mentioned EV and DV.  There’s also OV:

  https://www.globalsign.com/en/ssl-information-center/types-of-ssl-certificate/

> (i.e. whether tier 2, tier 3, …

The tier doesn’t affect how the CA does validation.  You could have a very 
meticulous tier 3 EV provider and a sloppy tier 1 provider that only does DV.

> can
> I still trust that the physical entity owning server cert is indeed who it
> claims to be).

It’s a chain of trust: the browser vendor trusts these 1,100 CAs, and you trust 
the browser vendor, so you implicitly trust all of the certs signed, directly 
or indirectly by those CAs.

If you want to take an active role in this, you need to go into the trust store 
for the browser(s) you use and remove CAs you do not trust.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[m . roth]

John Hodrien wrote:
> On Wed, 15 Jun 2016, John R Pierce wrote:
>
>> On 6/15/2016 6:47 AM, Jerry Geis wrote:
>>>  How do I get past this? I was looking to just self sign for https.
>>
>> in my admittedly limited experience with this stuff, you need to create
>> your own rootCA, and use that to sign your certificates, AND you need
to take
>> the public key of the rootCA and import it into any trust stores that will
>> be used to verify said certificates.
>
> If you don't do this, then there's no real point using SSL at all, and you
> *should* be forced to override security with arguments:
>
> wget --no-check-certificate
> curl --insecure

Or, maybe, you're working in a domain, and one upper level website is set
up with https-use-strict recursive, so it breaks *everything* below
I'd like to be able to say "but not me" in the website configuration page
- maybe it just throws up a warning, to remind you to pull it when it goes
live, but for dev & test

 mark, really tired of it breaking our *internal* documentation wiki
   for me

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Wed, June 15, 2016 10:31 am, Scott Robbins wrote:
> On Wed, Jun 15, 2016 at 10:02:57AM -0500, Valeri Galtsev wrote:
>>
>> On Wed, June 15, 2016 9:17 am, Warren Young wrote:
>> >>
>> >> Nowadays it's quite easy to get normal ssl certificates for free.
>> E.g.
>> >
>> > Today, I would prefer Let’s Encrypt:
>> >
>> >   https://letsencrypt.org/
>> >
>> > It is philosophically aligned with the open source software world,
>> rather
>> > than act as bait for a company that would prefer to sell you a cert
>> > instead.
>>
>> I have got question for experts. I just opened settings of Firefox
>> (latest, on FreeBSD), and took a look at the list of Certification
>> Authorities it comes with.
>>
>> I do see WoSign there (though I'd prefer to avoid my US located servers
>> have certificates signed by authority located in China, hence located
>> sort
>> of behind "the great firewall of China" - call me superstitious).
>>
>> I do not see neither starttls.com nor letsencrypt.org between
>> Authorities
>> certificates.
>
>
> I'm not an expert by any means, but I use letsencrypt (mostly for testing)
> and it's always worked for me in FreeBSD with Firefox, without any special
> effort on my part.
> You can try https://srobb.net which is using letsencrypt as its cert.

Thanks, Scott, I made a note, and will use it if there ever will be a need
(Now I get certs signed through institutional channel by intermediate
authority as well!). Intermediate CAs somehow slept my mind today (I
probably missed my morning coffee ;-)

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Wed, June 15, 2016 10:38 am, Warren Young wrote:
> On Jun 15, 2016, at 9:02 AM, Valeri Galtsev 
> wrote:
>>
>> I do see WoSign there (though I'd prefer to avoid my US located servers
>> have certificates signed by authority located in China, hence located
>> sort
>> of behind "the great firewall of China" - call me superstitious).
>
> That’s a perfectly valid concern.  The last I heard, modern browsers
> trust 1,100 CAs!  Surely some of those CAs have interests that do not
> align with my interests.
>
>> I do not see neither starttls.com nor letsencrypt.org between
>> Authorities
>> certificates.
>
> That’s because they are not top-tier CAs.
>
>> This means (correct me if I'm wrong) that client has to
>> import one of these Certification Authorities certificates
>
> You must be unaware of certificate chaining:
>
>   https://en.wikipedia.org/wiki/Intermediate_certificate_authorities

Sorry, intermediate authorities just slept off my mind somehow (to say
worst: my server certificated _are_ signed by intermediate CA - shame on
me ;-)

Valeri



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Wed, June 15, 2016 10:48 am, Warren Young wrote:
> On Jun 15, 2016, at 9:38 AM, Warren Young  wrote:
>>
>> On Jun 15, 2016, at 9:02 AM, Valeri Galtsev 
>> wrote:
>>
>>> I do not see neither starttls.com nor letsencrypt.org between
>>> Authorities
>>> certificates.
>>
>> That’s because they are not top-tier CAs.
>
> I forgot to mention that letsencrypt.com uses one of its own certificates.
>  You can use your browser’s certificate detail view to see the chain of
> trust.  I see two levels here: IdenTrust -> TrustID -> Let’s Encrypt.

Thanks, that means no need to install CA. There is always someone (Thanks,
Warren!) who looked deeper into things, and can explain them. The only
thing here is: I need to look deeper myself how the identity of the server
is ensured in this case (i.e. whether tier 2, tier 3, ... CAs really do
that. But that is more fundamental thing: basically with that in play, can
I still trust that the physical entity owning server cert is indeed who it
claims to be).

>
> As for starttls.com, that doesn’t exist; you’re probably confusing it
> with the SMTP STARTTLS protocol extension.  What you mean is startssl.com,
> which is the main public face of StartCom.  StartCom is a top-tier CA.

I'm sure I did copy and paste, so that should have copied from OP e-mail...

Thanks again, Warren,

Valeri

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Jason Pyeron]

> -Original Message-
> From: Warren Young
> Sent: Wednesday, June 15, 2016 10:26
> To: CentOS mailing list
> Subject: Re: [CentOS] https and self signed
> 
> On Jun 15, 2016, at 7:47 AM, Jerry Geis  wrote:
> > 
> > Yes I can added the --insecure for curl - but - my other 
> app doesn't 

For the love of all that is holy, create your own CA and have your own PKI,
even for testing.

> > seem to work either - perhaps getting the same return 
> message instead 
> > of the actual file.
> 
...
> It's too bad, because self-signed certificates are only 
> unusual on the public Internet.  I wish the designers of TLS 
...
> self-signed cert that declares that it is for 172.16.69.42, 
> and that any host on 172.16.69.0/24 should trust it implicitly.

It is very easy to creat your own CA, to sign your own certs. There is no
need to support self signed "leaf nodes" of the PKI.

I have taken some liberties on this to save me time, you will need to change
config values to suit your needs.

$ mkdir -p CA/{private,certs}
$ cd CA
# copy the default openssl config
$ cp -v "$(openssl ca -verbose 2>&1 | head -n 1 | sed 's/Using configuration
from //')" .
$ sed -i 's/^\(\s*dir\s*=.*\)/#\1\ndir=./'
openssl.cnf
$ sed -i 's|^\(\s*certificate\s*=.*\)|#\1\ncertificate=$dir/CA.crt|'
openssl.cnf
$ sed -i 's|^\(\s*private_key\s*=.*\)|#\1\nprivate_key=$dir/private/CA.key|'
openssl.cnf
$ sed -i 's|^\(\s*new_certs_dir\s*=.*\)|#\1\nnew_certs_dir=$dir/newcerts|'
openssl.cnf
$ touch index.txt
# done setting up the file system
$ openssl req -config openssl.cnf -new -nodes -keyout private/CA.key -out
CA.csr
# answer the questions
$ openssl ca -config openssl.cnf -batch -in CA.csr -create_serial -selfsign
# there should only be one cert, the CA's self signed cert
$ cp certs/*.pem CA.crt
# done creating the CA


# now you can sign your server certificate signing requests (CSR)

# make a csr 

#sign server.csr
$ openssl ca -config openssl.cnf -batch -in server.csr

#files at end of email for understanding...


> 
> Such a cert could not be used to prove identity, prevent 
> spoofing, or prevent MITM attacks, but it would give a way to 
> set up encryption, which is often all you actually want.  
> MITM attacks could be largely prevented with certificate pinning.

And reducing the trusted CA set in your enterprise.



$ cat ./private/CA.key
-BEGIN PRIVATE KEY-
MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQDEHcq8mOpHHD+H
/qDNPpsG2GkRyj8wt9LVIltmUqwqIBlNe3nlxHEHg9YJExPbTTXERehNkpF8HPtM
S2rfcYMz2Cjq8C8CzNlC/Ur2a8GKfOufZU9a+gv8I2CXzah6DLkdZqqCsnC/dTPL
bRLPBlmmwldl3pcOpF1hmMF1CzCwDAx2V31ZijLHlMfd+cRdssfYk1D4ntGRBK+0
78g2/nBOKQsD6ajTXHwaH7eeV7BRasjGodSud8cJ1uhD0E3QLpW466sYmM1SGdgy
1mbuJYGnfHVy4zScDy7yQb4EvoQZOYOMJymETCQfk86B43Sncs20TEpDW2N48N+O
pbqM0TAxAgMBAAECggEAIt45IXb+kE4RbZhz9one/kSTybnvqjXEomhNX8/rFEJI
vWHqtlNK1U83Sr29lgwQNylGuCQLAcoVU+dExR1lel5ASCUT9qd9KU/neBCIhJrZ
OanFhiNW5ilUDyldfvWsI/IQ9tPK//9SiiSGZ5B1eBStfUsqCExo3eVO4ARxT5tF
Fug/XgyV5vdUnUFC/axQPCWNfkFlm6mXNBcVO+D7/kweklrKLGqIFQTSv7mzL5ya
nTslER6dTu/2gva6cVAw3PN8FjgFa85ISpAWcyZ7ZBHd2evL46V1WsxFOsu5Ish+
e4SPP0xf4+8VggNvPruPb0T3gV8jHbN4fyPGqH7DwQKBgQDmbg2Mj69WN1jw1EpH
agv2xzVqTnjQSdbD2YBJ8ZJqIolAZigdrLTXp/P/pnOXe+3up1S+9OGbktQAc9DN
i9zf6Wn9NyZ323YEfL2MLE8pRrLsFFw1+fVG/BNcrHMOnt3rSQ7v2LhGe/kLCIQh
RKDSf83sEvAcfcSCpWeoZRlnxQKBgQDZ4PnrBpUVm86cq9/RV4Ax0NJ7+u+ybLj5
tKEeEDRlzTyNv2KIF7MOWoK6EMBw3N/YloSp41Zm7UXAdwjJHrxZ3GrlHvYqJDaW
cGX+GjncDpcM2GIh4tcuhnKTdUZc/eGWPZRA97EPdhqwHbDaPLSrQhtDmPDCWVNs
DqyWPFbBfQKBgH7tuEDpFOgk7LUb+x6DZ7uz19SLDTmOsuKG+IfCragRBhGXNBnE
fIkeVuVHxvx2o4WGXsQhF/UeV/E32piepjgg1uVIb8Qt+0BVhgOklKZj70LjpDeH
THihefjedTJkiFGGmNe9RSRuPay6MC4zI3NQOxoDBIhtLsXYXtT/e5MRAoGAY48t
RFsmptAikm7rgGJmftz4QZUCENsjj18dvHoVJ2uoPvF0WdHSjT2IvPNIrIoRc4wc
JPFwGupTVEZQam60DK/u3LHQNKOFmirUQE/FnqvAFCuQdAGO6IChPIZ7V6Tff2K2
KxXD/9etDEsU9DSHLjav9KyfX3+n4hm2fZQm5JUCgYB1tiDFrX4kgf671A9eMXHa
4RJKtvKdXEzw/a1uU82rvShZnlfIijHOHnOduwpFbtZRjvwREslBjwe0KXC5n4rN
ontb9cb94SmJlrYWj0ZYGbECB2nh1xBq2IeF7ly8t6Ky5xRc9hcACX5Z5G0QfHf8
liGhEmq+iGBkYtW6Jucvbg==
-END PRIVATE KEY-

$ cat ./certs/FC4B076EEDAC665F.pem
-BEGIN CERTIFICATE-
MIIELjCCAxagAwIBAgIJAPxLB27trGZfMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYD
VQQGEwJVUzELMAkGA1UECAwCTUQxITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMg
UHR5IEx0ZDEZMBcGA1UECwwQVHJ1c3QgRGVwYXJ0bWVudDEYMBYGA1UEAwwPUHJp
dmF0ZSBSb290IENBMSMwIQYJKoZIhvcNAQkBFhRzZWN1cml0eUBleGFtcGxlLmNv
bTAeFw0xNjA2MTUxNjI3MzBaFw0xNzA2MTUxNjI3MzBaMIGXMQswCQYDVQQGEwJV
UzELMAkGA1UECAwCTUQxITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0
ZDEZMBcGA1UECwwQVHJ1c3QgRGVwYXJ0bWVudDEYMBYGA1UEAwwPUHJpdmF0ZSBS
b290IENBMSMwIQYJKoZIhvcNAQkBFhRzZWN1cml0eUBleGFtcGxlLmNvbTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQdyryY6kccP4f+oM0+mwbYaRHK
PzC30tUiW2ZSrCogGU17eeXEcQeD1gkTE9tNNcRF6E2SkXwc+0xLat9xgzPYKOrw
LwLM2UL9SvZrwYp8659lT1r6C/wjYJfNqHoMuR1mqoKycL91

Re: [CentOS] https and self signed

[Warren Young]

On Jun 15, 2016, at 9:38 AM, Warren Young  wrote:
> 
> On Jun 15, 2016, at 9:02 AM, Valeri Galtsev  wrote:
> 
>> I do not see neither starttls.com nor letsencrypt.org between Authorities
>> certificates.
> 
> That’s because they are not top-tier CAs.

I forgot to mention that letsencrypt.com uses one of its own certificates.  You 
can use your browser’s certificate detail view to see the chain of trust.  I 
see two levels here: IdenTrust -> TrustID -> Let’s Encrypt.

As for starttls.com, that doesn’t exist; you’re probably confusing it with the 
SMTP STARTTLS protocol extension.  What you mean is startssl.com, which is the 
main public face of StartCom.  StartCom is a top-tier CA.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Warren Young]

On Jun 15, 2016, at 9:02 AM, Valeri Galtsev  wrote:
> 
> I do see WoSign there (though I'd prefer to avoid my US located servers
> have certificates signed by authority located in China, hence located sort
> of behind "the great firewall of China" - call me superstitious).

That’s a perfectly valid concern.  The last I heard, modern browsers trust 
1,100 CAs!  Surely some of those CAs have interests that do not align with my 
interests.

> I do not see neither starttls.com nor letsencrypt.org between Authorities
> certificates.

That’s because they are not top-tier CAs.

> This means (correct me if I'm wrong) that client has to
> import one of these Certification Authorities certificates

You must be unaware of certificate chaining:

  https://en.wikipedia.org/wiki/Intermediate_certificate_authorities

Even top-tier CAs use certificate chaining.  The proper way to run a CA is to 
keep your private root signing key off-line, using it only to sign some number 
of intermediate CA signing certs, which are the ones used to generate the certs 
publicly distributed by that CA.

Doing so lets a CA abandon an escaped private key by issuing a CRL for an 
escaped private key.  The CA then just generates a new signing key and 
continues on with that; it doesn’t have to get its new signing key into all the 
TLS clients’s trusted signing key stores because the new key’s trust chain goes 
back to the still-private offline root key.

Without that layer of protection, if their private signing key somehow escapes, 
the CA is basically out of business until they convince all the major browsers 
to distribute their replacement public key.

> - but other clients, like laptops had to download, install and
> trus my CA certificate).

If those laptops are Windows laptops on an AD domain, there is a way to push CA 
public keys out to them automatically.  (Don’t ask me how, I’m not a Windows 
admin.  I’m just aware that it can be done.)

> Also: with CA signing server certificate there is a part that is
> "verification of identity" of domain or server owner. Namely, that whoever
> requested certificate indeed exists as physical entity (person,
> organization or company) accessible at some physical address etc. This is
> costly process, and as I remember, free automatically signed certificates
> were only available from Certification Authority whose CA certificated had
> no chance to be included into CA bundles shipped with browsers, systems
> etc. For that exact reason: there is "no identity verification". The last
> apparently is costly process.

I’m not exactly sure what you’re asking here.  If you are simply pointing out 
that the free certificate providers — including Let’s Encrypt — do not do 
public records background checks, D&B checks, phone calls to phone numbers on 
your web page and DNS records, etc. to prove that you are who you say you are, 
that is true.

Let’s Encrypt is not in competition with EV certificates, for example:

  https://en.wikipedia.org/wiki/Extended_Validation_Certificate

The term of art for what Let’s Encrypt provides is a domain validation 
certificate. That is, it only proves that the holder was in control of the 
domain name at the time the cert was generated.

> So, someone, please, set all of us straight: what is the state of the art
> today?

The answer could fill books.  In a forum like this, you can only expect answers 
to specific questions for such broad topics.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Scott Robbins]

On Wed, Jun 15, 2016 at 10:02:57AM -0500, Valeri Galtsev wrote:
> 
> On Wed, June 15, 2016 9:17 am, Warren Young wrote:
> >>
> >> Nowadays it's quite easy to get normal ssl certificates for free. E.g.
> >
> > Today, I would prefer Let’s Encrypt:
> >
> >   https://letsencrypt.org/
> >
> > It is philosophically aligned with the open source software world, rather
> > than act as bait for a company that would prefer to sell you a cert
> > instead.
> 
> I have got question for experts. I just opened settings of Firefox
> (latest, on FreeBSD), and took a look at the list of Certification
> Authorities it comes with.
> 
> I do see WoSign there (though I'd prefer to avoid my US located servers
> have certificates signed by authority located in China, hence located sort
> of behind "the great firewall of China" - call me superstitious).
> 
> I do not see neither starttls.com nor letsencrypt.org between Authorities
> certificates. 


I'm not an expert by any means, but I use letsencrypt (mostly for testing)
and it's always worked for me in FreeBSD with Firefox, without any special
effort on my part. 
You can try https://srobb.net which is using letsencrypt as its cert.

-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Paul Heinlein]

On Wed, 15 Jun 2016, John R Pierce wrote:


On 6/15/2016 6:47 AM, Jerry Geis wrote:

 How do I get past this? I was looking to just self sign for https.


in my admittedly limited experience with this stuff, you need to 
create your own rootCA, and use that to sign your certificates, AND 
you need to take the public key of the rootCA and import it into any 
trust stores that will be used to verify said certificates.


The EasyRSA scripts make creating and using your own Certificate 
Authority as painless as X.509 can be (which is to say, there will 
still be some pain). You can find them in the OpenVPN distribution 
tarball or at GitHub:


  https://github.com/OpenVPN/easy-rsa

--
Paul Heinlein <> heinl...@madboa.com <> http://www.madboa.com/
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[David Nelson]

On Jun 15, 2016, at 8:02 AM, Valeri Galtsev  wrote:
> 
> I do not see neither starttls.com  nor letsencrypt.org 
>  between Authorities
> certificates. This means (correct me if I'm wrong) that client has to
> import one of these Certification Authorities certificates, otherwise
> server certificate signed by one of these authorities is on the same page
> with my private Certification Authority (which I used to run for over 10
> years, then in my kickstart I had my CA certificate imported into CA of
> clients - but other clients, like laptops had to download, install and
> trus my CA certificate). Of course, this is a notch better than
> "self-signed" server certificates, as you only need to import CA
> certificate once, whereas you will need to import self-signed server
> certificates for each of the servers...



For my personal needs I use free StartSSL certs and the authority appears as 
StartCom, Ltd. in Firefox.

In my experience it is already a trusted authority in most/all browsers. At 
least I didn’t have to manually trust it, and I haven’t run into one that 
complains about it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[John Hodrien]

On Wed, 15 Jun 2016, John R Pierce wrote:


On 6/15/2016 6:47 AM, Jerry Geis wrote:

 How do I get past this? I was looking to just self sign for https.


in my admittedly limited experience with this stuff, you need to create your 
own rootCA, and use that to sign your certificates, AND you need to take the 
public key of the rootCA and import it into any trust stores that will be 
used to verify said certificates.


If you don't do this, then there's no real point using SSL at all, and you
*should* be forced to override security with arguments:

wget --no-check-certificate
curl --insecure

etc.

jh
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[John R Pierce]

On 6/15/2016 6:47 AM, Jerry Geis wrote:

How do I get past this? I was looking to just self sign for https.


in my admittedly limited experience with this stuff, you need to create 
your own rootCA, and use that to sign your certificates, AND you need to 
take the public key of the rootCA and import it into any trust stores 
that will be used to verify said certificates.



--
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Wed, June 15, 2016 9:17 am, Warren Young wrote:
> On Jun 15, 2016, at 7:57 AM, Александр Кириллов
>  wrote:
>>
>> Nowadays it's quite easy to get normal ssl certificates for free. E.g.
>>
>> http://www.startssl.com
>> http://buy.wosign.com/free
>
> Today, I would prefer Let’s Encrypt:
>
>   https://letsencrypt.org/
>
> It is philosophically aligned with the open source software world, rather
> than act as bait for a company that would prefer to sell you a cert
> instead.

I have got question for experts. I just opened settings of Firefox
(latest, on FreeBSD), and took a look at the list of Certification
Authorities it comes with.

I do see WoSign there (though I'd prefer to avoid my US located servers
have certificates signed by authority located in China, hence located sort
of behind "the great firewall of China" - call me superstitious).

I do not see neither starttls.com nor letsencrypt.org between Authorities
certificates. This means (correct me if I'm wrong) that client has to
import one of these Certification Authorities certificates, otherwise
server certificate signed by one of these authorities is on the same page
with my private Certification Authority (which I used to run for over 10
years, then in my kickstart I had my CA certificate imported into CA of
clients - but other clients, like laptops had to download, install and
trus my CA certificate). Of course, this is a notch better than
"self-signed" server certificates, as you only need to import CA
certificate once, whereas you will need to import self-signed server
certificates for each of the servers...

Am I missing something?

Also: with CA signing server certificate there is a part that is
"verification of identity" of domain or server owner. Namely, that whoever
requested certificate indeed exists as physical entity (person,
organization or company) accessible at some physical address etc. This is
costly process, and as I remember, free automatically signed certificates
were only available from Certification Authority whose CA certificated had
no chance to be included into CA bundles shipped with browsers, systems
etc. For that exact reason: there is "no identity verification". The last
apparently is costly process.

So, someone, please, set all of us straight: what is the state of the art
today?

Disclaimer: I have purely academic interest in this myself: my institution
makes CA signed certificated for my servers at no cost for me, and that
authority is in the CA Cert bundles.

Valeri

>
> I’m only aware of one case where you absolutely cannot use Let’s
> Encrypt, but it also affects the other public CAs: you can’t get a
> publicly-trusted cert for a machine without a publicly-recognized and
> -visible domain name.  For that, you still need to use self-signed certs
> or certs signed by a private CA.




Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Warren Young]

On Jun 15, 2016, at 7:47 AM, Jerry Geis  wrote:
> 
> Yes I can added the --insecure for curl - but - my other app doesn't
> seem to work either - perhaps getting the same return message instead of
> the actual file.

Because of all the security holes people have been finding in TLS, libraries 
implementing the client side of TLS are getting increasingly intolerant of 
risky configurations.

It’s too bad, because self-signed certificates are only unusual on the public 
Internet.  I wish the designers of TLS had included a flag in the cert that let 
it declare that it was only to be trusted on a private intranet by clients of 
that same intranet.

For example, instead of declaring that the given server is foo.example.com, it 
would be nice if you could generate a self-signed cert that declares that it is 
for 172.16.69.42, and that any host on 172.16.69.0/24 should trust it 
implicitly.

Such a cert could not be used to prove identity, prevent spoofing, or prevent 
MITM attacks, but it would give a way to set up encryption, which is often all 
you actually want.  MITM attacks could be largely prevented with certificate 
pinning.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Warren Young]

On Jun 15, 2016, at 7:57 AM, Александр Кириллов  wrote:
> 
> Nowadays it's quite easy to get normal ssl certificates for free. E.g.
> 
> http://www.startssl.com
> http://buy.wosign.com/free

Today, I would prefer Let’s Encrypt:

  https://letsencrypt.org/

It is philosophically aligned with the open source software world, rather than 
act as bait for a company that would prefer to sell you a cert instead.

I’m only aware of one case where you absolutely cannot use Let’s Encrypt, but 
it also affects the other public CAs: you can’t get a publicly-trusted cert for 
a machine without a publicly-recognized and -visible domain name.  For that, 
you still need to use self-signed certs or certs signed by a private CA.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Александр Кириллов]

Nowadays it's quite easy to get normal ssl certificates for free. E.g.

http://www.startssl.com
http://buy.wosign.com/free

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] https and self signed

[Jerry Geis]

I followed the instructions here https://wiki.centos.org/HowTos/Https

Checking port 80 I get the file...
curl http://localhost/file.html


Working



Checking port 443 I get and error
curl https://localhost/file.html

curl: (60) Peer's certificate issuer has been marked as not trusted by the
user.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.


How do I get past this? I was looking to just self sign for https.

Yes I can added the --insecure for curl - but - my other app doesn't
seem to work either - perhaps getting the same return message instead of
the actual file.

Thanks,

jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos