Question on necessity of SSL_CTX_set_client_CA_list

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Question on necessity of SSL_CTX_set_client_CA_list

Charles Mills

I have an OpenSSL (v1.1.0f) server application that processes client certificates.

 

The doc for SSL_CTX_load_verify_locations() states “In server mode, when requesting a client certificate, the server must send the list of CAs of which it will accept client certificates. This list is not influenced by the contents of CAfile or CApath and must explicitly be set using the SSL_CTX_set_client_CA_list family of functions.”

 

The application makes no calls to SSL_CTX_set_client_CA_list() yet receives client certificates without errors.

 

Can someone please explain the discrepancy. I’m especially wondering if I have set a trap that will spring down the road: “yes it works, but if a user does X then it will not work.”

 

Thanks!

 

Charles

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Charles Mills

Do I need to say no calls to SSL_CTX_set_client_CA_list() nor any of the three related functions listed on the man page?

 

Charles

 

From: Charles Mills [mailto:[hidden email]]
Sent: Sunday, December 2, 2018 4:38 PM
To: '[hidden email]'
Subject: Question on necessity of SSL_CTX_set_client_CA_list

 

I have an OpenSSL (v1.1.0f) server application that processes client certificates.

 

The doc for SSL_CTX_load_verify_locations() states “In server mode, when requesting a client certificate, the server must send the list of CAs of which it will accept client certificates. This list is not influenced by the contents of CAfile or CApath and must explicitly be set using the SSL_CTX_set_client_CA_list family of functions.”

 

The application makes no calls to SSL_CTX_set_client_CA_list() yet receives client certificates without errors.

 

Can someone please explain the discrepancy. I’m especially wondering if I have set a trap that will spring down the road: “yes it works, but if a user does X then it will not work.”

 

Thanks!

 

Charles

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Viktor Dukhovni
In reply to this post by Charles Mills
> On Dec 2, 2018, at 7:38 PM, Charles Mills <[hidden email]> wrote:
>
> I have an OpenSSL (v1.1.0f) server application that processes client certificates.
>  
> The doc for SSL_CTX_load_verify_locations() states “In server mode, when requesting a client certificate, the server must send the list of CAs of which it will accept client certificates. This list is not influenced by the contents of CAfile or CApath and must explicitly be set using the SSL_CTX_set_client_CA_list family of functions.”
>  
> The application makes no calls to SSL_CTX_set_client_CA_list() yet receives client certificates without errors.
>  
> Can someone please explain the discrepancy. I’m especially wondering if I have set a trap that will spring down the road: “yes it works, but if a user does X then it will not work.”

The default list is empty.  Some client implementations, IIRC Java's TLS
stack or at least some Java TLS toolkits, will not use a client certificate
unless the server's list is non-empty, and perhaps may also require that it
include a CA name that matches an issuer of their certificate.

Other clients have but one default certificate and use it regardless of the
server's CA list.  Your mileage may vary.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Charles Mills
Got it. Thanks. I would think the basic client case is "one certificate, one CA" so I think I will roll with what we have (especially since the product has been out there for years with no reported problems in this area -- although I think client certificate usage is rare) but keep the issue in mind if a problem comes up.

Charles


-----Original Message-----
From: openssl-users [mailto:[hidden email]] On Behalf Of Viktor Dukhovni
Sent: Sunday, December 2, 2018 5:50 PM
To: [hidden email]
Subject: Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list

> On Dec 2, 2018, at 7:38 PM, Charles Mills <[hidden email]> wrote:
>
> I have an OpenSSL (v1.1.0f) server application that processes client certificates.
>  
> The doc for SSL_CTX_load_verify_locations() states “In server mode, when requesting a client certificate, the server must send the list of CAs of which it will accept client certificates. This list is not influenced by the contents of CAfile or CApath and must explicitly be set using the SSL_CTX_set_client_CA_list family of functions.”
>  
> The application makes no calls to SSL_CTX_set_client_CA_list() yet receives client certificates without errors.
>  
> Can someone please explain the discrepancy. I’m especially wondering if I have set a trap that will spring down the road: “yes it works, but if a user does X then it will not work.”

The default list is empty.  Some client implementations, IIRC Java's TLS
stack or at least some Java TLS toolkits, will not use a client certificate
unless the server's list is non-empty, and perhaps may also require that it
include a CA name that matches an issuer of their certificate.

Other clients have but one default certificate and use it regardless of the
server's CA list.  Your mileage may vary.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Charles Mills
> Sent: Monday, December 03, 2018 10:55
>
> Got it. Thanks. I would think the basic client case is "one certificate, one CA"

I'm going to disagree somewhat with this assumption, but not necessarily with your decision.

That assumption is probably safe for some use cases, but not all. For example, Windows-based clients that use Microsoft's TLS implementation (SChannel, via CAPI or CNG or any of the various wrapper APIs, including the .NET Framework) have access to all the "personal" certificates in the Windows per-machine and per-user certificate stores. In a Windows domain environment, certificates may be added to those stores by central administration, as well as being created or added locally. So such clients could have quite a few client certificates available to them.

Some other TLS implementations can optionally use the Windows certificate stores. I believe Netscape's NSS can be configured to do so, for example. A suitable JSSE provider is included with the standard Windows JRE and JDK distributions. And OpenSSL itself has a CAPI engine that can (probably) be used to pull client certificates from the Windows stores.

(I say "probably" because when we went to use the OpenSSL CAPI engine some years ago, we ran into some issues caused by Microsoft's awkward provider mechanism and how it interacts with private-key storage, and I ended up enhancing the OpenSSL CAPI module in various ways. So I don't recall what exactly works with it out of the box.)

There are other environments which similarly provide centralized storage of certificates (and corresponding private keys) to all clients. zOS does, for example, at least if you're using the RACF security provider.

Perhaps more importantly, as Viktor noted, some clients won't send a certificate at all unless they have one signed by a CA on the server's list, or at least only if the server sends a non-empty list.

The list is also useful for clients that want to help the user select from among a set of certificates.

> so I think I will roll with what we have (especially since the product has been
> out there for years with no reported problems in this area -- although I think
> client certificate usage is rare) but keep the issue in mind if a problem comes
> up.

Despite what I wrote above, the important thing, of course, is what your users need. If they haven't needed a server that sends a CA list, there's a good chance they won't need one any time soon. Often there are better things to address first. TLS configuration is important, but certainly for the software projects I work on there are any number of important areas for further work. You can't do everything at once.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Charles Mills
> zOS does, for example, at least if you're using the RACF security
provider.

Ha! Spoken like a Micro Focus guy! One of the most likely clients for this
server is in fact implemented on z/OS. Just FYI, the key variable is not so
much RACF: (a.) RACF is just (in this case) a certificate store, not a TLS
implementation; and (b.) I think the other two ESM's (CA TSS and ACF2) are
99% equivalent in their certificate facilities.

The TLS implementation is named System SSL (sometimes known as GSK). That is
the TLS library, roughly parallel to OpenSSL. (In fact I don't know of any
other TLS implementation on z/OS other than the OpenSSL port -- but there
could be some.) GSK also implements its own certificate store, but I don't
think it is widely used in production.

Yes, there would be lots of certificates in the certificate store, but at
least in the case of the client I wrote, you configure it in advance to use
a particular named certificate, so the server application itself does not
have any choice at run time. It is "one certificate, take it or leave it."

Thanks for the heads-up on Windows. I develop for both platforms, but I am
much less familiar with all of the ins and outs of Windows.

OCSP and OCSP stapling are currently higher on my wish list than this.

Charles


-----Original Message-----
From: openssl-users [mailto:[hidden email]] On Behalf Of
Michael Wojcik
Sent: Monday, December 3, 2018 10:58 AM
To: [hidden email]
Subject: Re: [openssl-users] Question on necessity of
SSL_CTX_set_client_CA_list

> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Charles Mills
> Sent: Monday, December 03, 2018 10:55
>
> Got it. Thanks. I would think the basic client case is "one certificate,
one CA"

I'm going to disagree somewhat with this assumption, but not necessarily
with your decision.

That assumption is probably safe for some use cases, but not all. For
example, Windows-based clients that use Microsoft's TLS implementation
(SChannel, via CAPI or CNG or any of the various wrapper APIs, including the
.NET Framework) have access to all the "personal" certificates in the
Windows per-machine and per-user certificate stores. In a Windows domain
environment, certificates may be added to those stores by central
administration, as well as being created or added locally. So such clients
could have quite a few client certificates available to them.

Some other TLS implementations can optionally use the Windows certificate
stores. I believe Netscape's NSS can be configured to do so, for example. A
suitable JSSE provider is included with the standard Windows JRE and JDK
distributions. And OpenSSL itself has a CAPI engine that can (probably) be
used to pull client certificates from the Windows stores.

(I say "probably" because when we went to use the OpenSSL CAPI engine some
years ago, we ran into some issues caused by Microsoft's awkward provider
mechanism and how it interacts with private-key storage, and I ended up
enhancing the OpenSSL CAPI module in various ways. So I don't recall what
exactly works with it out of the box.)

There are other environments which similarly provide centralized storage of
certificates (and corresponding private keys) to all clients. zOS does, for
example, at least if you're using the RACF security provider.

Perhaps more importantly, as Viktor noted, some clients won't send a
certificate at all unless they have one signed by a CA on the server's list,
or at least only if the server sends a non-empty list.

The list is also useful for clients that want to help the user select from
among a set of certificates.

> so I think I will roll with what we have (especially since the product has
been
> out there for years with no reported problems in this area -- although I
think
> client certificate usage is rare) but keep the issue in mind if a problem
comes
> up.

Despite what I wrote above, the important thing, of course, is what your
users need. If they haven't needed a server that sends a CA list, there's a
good chance they won't need one any time soon. Often there are better things
to address first. TLS configuration is important, but certainly for the
software projects I work on there are any number of important areas for
further work. You can't do everything at once.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Viktor Dukhovni
> On Dec 3, 2018, at 3:35 PM, Charles Mills <[hidden email]> wrote:
>
> OCSP and OCSP stapling are currently higher on my wish list than this.

Good luck with OCSP, the documentation could definitely be better, and
various projects get it wrong.  IIRC curl gets OCSP right, so you
could look there for example code, some other projects go through the
motions, but don't always achieve a robust result.

[ FWIW, I don't care much for OCSP, it's often not required, so it is
  then not clear what security properties it provides. ]

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Charles Mills
Those darned customers are asking for it!

I do understand the privacy exposure. Don't know if the customers do or do
not.

Charles


-----Original Message-----
From: openssl-users [mailto:[hidden email]] On Behalf Of
Viktor Dukhovni
Sent: Monday, December 3, 2018 12:40 PM
To: [hidden email]
Subject: Re: [openssl-users] Question on necessity of
SSL_CTX_set_client_CA_list

> On Dec 3, 2018, at 3:35 PM, Charles Mills <[hidden email]> wrote:
>
> OCSP and OCSP stapling are currently higher on my wish list than this.

Good luck with OCSP, the documentation could definitely be better, and
various projects get it wrong.  IIRC curl gets OCSP right, so you
could look there for example code, some other projects go through the
motions, but don't always achieve a robust result.

[ FWIW, I don't care much for OCSP, it's often not required, so it is
  then not clear what security properties it provides. ]

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Jan Just Keijser-2
In reply to this post by Viktor Dukhovni
Hi,

On 03/12/18 21:40, Viktor Dukhovni wrote:

>> On Dec 3, 2018, at 3:35 PM, Charles Mills <[hidden email]> wrote:
>>
>> OCSP and OCSP stapling are currently higher on my wish list than this.
> Good luck with OCSP, the documentation could definitely be better, and
> various projects get it wrong.  IIRC curl gets OCSP right, so you
> could look there for example code, some other projects go through the
> motions, but don't always achieve a robust result.
>
> [ FWIW, I don't care much for OCSP, it's often not required, so it is
>    then not clear what security properties it provides. ]

the only reason to use OCSP I currently have is in Firefox:  if you turn
off "Query OCSP responder servers" in Firefox then EV certificates will
no longer show up with their owner/domain name. Now the question is:  
does Firefox get OCSP "right" ;) ?

cheers,

JJK / Jan Just Keijser

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Viktor Dukhovni
> On Dec 5, 2018, at 4:49 AM, Jan Just Keijser <[hidden email]> wrote:
>
> The only reason to use OCSP I currently have is in Firefox:  if you turn off
> "Query OCSP responder servers" in Firefox then EV certificates will no longer
> show up with their owner/domain name.

IIRC Apple's Safari is ending support for EV, and some say that EV
has failed, and are not sorry to see it go.

> Now the question is:   does Firefox get OCSP "right" ;) ?

Very likely yes.  The Firefox TLS stack is maintained by experts.
[ Also, FWIW, Firefox uses the "nss" library, not OpenSSL. ]

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

OpenSSL - User mailing list
On 05/12/2018 17:59, Viktor Dukhovni wrote:
>> On Dec 5, 2018, at 4:49 AM, Jan Just Keijser <[hidden email]> wrote:
>>
>> The only reason to use OCSP I currently have is in Firefox:  if you turn off
>> "Query OCSP responder servers" in Firefox then EV certificates will no longer
>> show up with their owner/domain name.
> IIRC Apple's Safari is ending support for EV, and some say that EV
> has failed, and are not sorry to see it go.
This is very bad for security.  So far the only real failures have
been:

1. Some cloud provider(s) actively want to reduce all TLS security to
   the anonymous form provided by Let's encrypt, and are doing their worst
   to sabotage EV providing CAs.

2. As part of this campaign, those same cloud provider(s) take every
   opportunity to declare EV (and even OV) certificates as worthless
   and irrelevant.

3. At least one of those cloud provider(s) publishes a widely used
   "browser", in which they have preemptively removed support.

Apple being tricked into removing support (contrary to their public hard
stance on user security) is sad.

>> Now the question is:   does Firefox get OCSP "right" ;) ?
> Very likely yes.  The Firefox TLS stack is maintained by experts.
> [ Also, FWIW, Firefox uses the "nss" library, not OpenSSL. ]
>
However Firefox code also contains lots of idiotic usability bugs,
even in the code that talks to the TLS stack.  It is quite possible
that the "OCSP must be on" rule is another bad usability hangover
from the set of badly thought out UI changes made to initially
promote EV certificates, just like the hiding of company names
from non-EV certificates that actually contain them (so called OV
certificates).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Michael Ströder
On 12/6/18 10:03 AM, Jakob Bohm via openssl-users wrote:

> On 05/12/2018 17:59, Viktor Dukhovni wrote:
>> IIRC Apple's Safari is ending support for EV, and some say that EV
>> has failed, and are not sorry to see it go.
>
> This is very bad for security.  So far the only real failures have
> been:
>
> 1. Some cloud provider(s) actively want to reduce all TLS security to
>   the anonymous form provided by Let's encrypt, and are doing their worst
>   to sabotage EV providing CAs.
Quoting from Peter Gutmann's "Engineering Security",
section "EV Certificates: PKI-me-Harder"

    Indeed, cynics would say that this was exactly the problem that
    certificates and CAs were supposed to solve in the first place, and
    that “high-assurance” certificates are just a way of charging a
    second time for an existing service.

I fully agree with the above and I'm also for removing this crap from
the browser UI.

Ciao, Michael.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

OpenSSL - User mailing list
On 06/12/2018 11:48, Michael Ströder wrote:

> On 12/6/18 10:03 AM, Jakob Bohm via openssl-users wrote:
>> On 05/12/2018 17:59, Viktor Dukhovni wrote:
>>> IIRC Apple's Safari is ending support for EV, and some say that EV
>>> has failed, and are not sorry to see it go.
>> This is very bad for security.  So far the only real failures have
>> been:
>>
>> 1. Some cloud provider(s) actively want to reduce all TLS security to
>>    the anonymous form provided by Let's encrypt, and are doing their worst
>>    to sabotage EV providing CAs.
> Quoting from Peter Gutmann's "Engineering Security",
> section "EV Certificates: PKI-me-Harder"
>
>      Indeed, cynics would say that this was exactly the problem that
>      certificates and CAs were supposed to solve in the first place, and
>      that “high-assurance” certificates are just a way of charging a
>      second time for an existing service.
>
> I fully agree with the above and I'm also for removing this crap from
> the browser UI.
Peter Gutman, for all his talents, dislikes PKI with a vengeance.

EV is a standard for OV certificates done right.  Which involves more
thorough identity checks, stricter rules for the CAs to follow etc.

The real point of EV certificates is to separate CAs that do a good
job from those that do a more sloppy job, without completely distrusting
the mediocre CA operations.

Due to market forces, the good CAs also offer the weaker certificate
types at a lower price to compete with the mediocre CAs that are aren't
good/thorough enough to do the full job.

The way EV certs are highlighted in Browsers (Green bar etc.) was a way
to create market demand for the higher quality.  They could be indicated
in some other useful way of cause, but the distinguishment between "The
CA did something to check the name and real world address in the
certificate" (OV) versus "The CA checked the name and and real world
address thoroughly in accordance with the higher quality standard" (EV)
is still of some significance.

If you look at that long list of CA roots preinstalled in a typical
browser, only a minority are authorized, trusted and audited to issue
to the higher EV standard.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Blumenthal, Uri - 0553 - MITLL
>    > Quoting from Peter Gutmann's "Engineering Security",

>    > section "EV Certificates: PKI-me-Harder"
>    >
>    >      Indeed, cynics would say that this was exactly the problem that
>    >      certificates and CAs were supposed to solve in the first place, and
>    >      that “high-assurance” certificates are just a way of charging a
>    >      second time for an existing service.
>    
>    Peter Gutman, for all his talents, dislikes PKI with a vengeance.
>     EV is a standard for OV certificates done right.  Which involves more
>    thorough identity checks, stricter rules for the CAs to follow etc.
>  
>     The real point of EV certificates is to separate CAs that do a good
>    job from those that do a more sloppy job, without completely distrusting
>    the mediocre CA operations.
 
So, a CA that's supposed to validate its customer before issuing a certificate, may do a "more sloppy job" if he doesn't cough up some extra money.

I think Peter is exactly right here. CA either do their job, or they don't. If they agree to certify a set of attributes, they ought to verify each one of them.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Viktor Dukhovni
> On Dec 6, 2018, at 3:06 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
> So, a CA that's supposed to validate its customer before issuing a certificate, may do a "more sloppy job" if he doesn't cough up some extra money.
>
> I think Peter is exactly right here. CA either do their job, or they don't. If they agree to certify a set of attributes, they ought to verify each one of them.

While the point of EV was that it certified a binding to a (domain + business name)
rather than just a domain with DV, it turned out that displaying the business name
was also subject to abuse, and the security gain proved elusive.

  https://www.troyhunt.com/extended-validation-certificates-are-dead/

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

OpenSSL - User mailing list
On 06/12/2018 21:16, Viktor Dukhovni wrote:
>> On Dec 6, 2018, at 3:06 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>>
>> So, a CA that's supposed to validate its customer before issuing a certificate, may do a "more sloppy job" if he doesn't cough up some extra money.
>>
>> I think Peter is exactly right here. CA either do their job, or they don't. If they agree to certify a set of attributes, they ought to verify each one of them.
No, Uri you get it wrong.  Different levels of certainty is the
point.

Consider it like this:

DV: A regular printed business card that you can get from a
   vending machine, proves very little.
     The CA just checks that the person or robot requesting the
   certificate has some semblance of control over the domain
   name at the time of issuance.  Price is as low as $0.

OV: A debit card with the supposed owners name on it, available
   from a number of companies that do minimal checking, but still
   a better ID proof than a business card.
     The CA must check that the company name and address are true,
   using some basic steps such as checking that a company by that
   name exists at that address and confirms they are the ones
   requesting the certificate.  There is no check that the company
   name is an official name or that the company has a business
   license etc.  A traditional lemonade stand run by children can
   potentially get an OV certificate if they stay in one place for
   the time it takes to get the certificate.  (A CA agent visiting
   the company site is enough checking of company existence for OV).

EV: A proper photo ID with serious identity checking before being
   issued, like a government passport.  Includes the holders
   legal name and government ID number (literally), which can be
   used to look up the subjects legal status.
     The CA must check public records, and do some hard checks that
   the request is officially from that company.  There is a 50+
   pages official specification listing how every tidbit of
   this information must be checked.  The CA cannot limit
   its own liability for certain failures to less than $2000.

Each step up the ladder gives the user more certainty the
person/website is who it says it is, but is more expensive
and difficult to obtain for the person/website.  Each step also
costs more money for the CA to check, because there is more work
to do.

The "make it look green" and "fights crime" slogans were just
the old marketing campaign, repeated endlessly as a more
efficient sales pressure than the real explanation.


> While the point of EV was that it certified a binding to a (domain + business name)
> rather than just a domain with DV, it turned out that displaying the business name
> was also subject to abuse, and the security gain proved elusive.
>
>    https://www.troyhunt.com/extended-validation-certificates-are-dead/

A traveling salesman for a cloud provider.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Viktor Dukhovni
> On Dec 6, 2018, at 5:56 PM, Jakob Bohm via openssl-users <[hidden email]> wrote:
>
>> While the point of EV was that it certified a binding to a (domain + business name)
>> rather than just a domain with DV, it turned out that displaying the business name
>> was also subject to abuse, and the security gain proved elusive.
>>
>>   https://www.troyhunt.com/extended-validation-certificates-are-dead/
>
> A traveling salesman for a cloud provider.

That's an ad-hominem argument.  Just because he may have an agenda,
does not mean he's wrong.  One might wish he were wrong, but perhaps
the market has spoken otherwise.  Or perhaps he really is wrong, we'll
see...

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Michael Ströder
In reply to this post by OpenSSL - User mailing list
On 12/6/18 11:56 PM, Jakob Bohm via openssl-users wrote:
>  Different levels of certainty is the point.

Which never worked well in practice, no matter how hard people tried to
clearly define levels if certainty.

Ciao, Michael.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Kyle Hamilton
In reply to this post by Blumenthal, Uri - 0553 - MITLL
CAs *do* verify the attributes they certify.  That they're not presented as such is not the fault of the CAs, but rather of the browsers who insist on not changing or improving their UI.

The thing is, if I run a website with a forum that I don't ask for money on and don't want any transactions happening on, why should I have to pay for the same level of certainty of my identity that a company like Amazon needs?

(Why does Amazon need that much certainty? Well, I could set up wireless access points around coffee shops in December, point the DNS provided at those WAPs to my own server and run a fake amazon.com site to capture account credentials and credit cards. Without EV, that's a plausible attack. Especially with SSL being not-by-default, someone could type amazon.com and it can be intercepted without showing any certificate warning -- which then allows a redirect to a lookalike amazon.com name that could get certified by something like LetsEncrypt.)

Plus, clouds have had a protocol available for doing queries to certs and keys held by other parties for several years. Cloudflare developed this protocol for banks, for whom loss of control of the certificate key is a reportable event, but who also often need DDoS protection. There's no reason it can't be extended to other clouds and sites -- unless Cloudflare patented it and wants royalties, in which case their rent-seeking is destroying the security of the web by convincing cloud salesmen to say that EV is too much trouble to deal with and thus should be killed off in the marketplace.

Demanding that EV be perfect and dropping support for it if it has any found vulnerability falls into a class of human behavior known as "letting the perfect be the enemy of the good", which is also known as "cutting off the nose to spite the face".  It still cuts down on a huge number of potential attacks, and doing away with it allows those attacks to flourish again. (Which, by the way, is what organized crime would prefer to permit.)

-Kyle H


On Thu, Dec 6, 2018, 14:07 Blumenthal, Uri - 0553 - MITLL <[hidden email] wrote:
>    > Quoting from Peter Gutmann's "Engineering Security",
>    > section "EV Certificates: PKI-me-Harder"
>    >
>    >      Indeed, cynics would say that this was exactly the problem that
>    >      certificates and CAs were supposed to solve in the first place, and
>    >      that “high-assurance” certificates are just a way of charging a
>    >      second time for an existing service.
>   
>    Peter Gutman, for all his talents, dislikes PKI with a vengeance.
>     EV is a standard for OV certificates done right.  Which involves more
>    thorough identity checks, stricter rules for the CAs to follow etc.

>     The real point of EV certificates is to separate CAs that do a good
>    job from those that do a more sloppy job, without completely distrusting
>    the mediocre CA operations.

So, a CA that's supposed to validate its customer before issuing a certificate, may do a "more sloppy job" if he doesn't cough up some extra money.

I think Peter is exactly right here. CA either do their job, or they don't. If they agree to certify a set of attributes, they ought to verify each one of them.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Blumenthal, Uri - 0553 - MITLL
If there's a non-EV CA that would give you a cert for DNS name amazon.com - I'd like to make sure it's in my list and marked Not Trusted.

Regards,
Uri

Sent from my iPhone

On Dec 7, 2018, at 17:02, Kyle Hamilton <[hidden email]> wrote:

CAs *do* verify the attributes they certify.  That they're not presented as such is not the fault of the CAs, but rather of the browsers who insist on not changing or improving their UI.

The thing is, if I run a website with a forum that I don't ask for money on and don't want any transactions happening on, why should I have to pay for the same level of certainty of my identity that a company like Amazon needs?

(Why does Amazon need that much certainty? Well, I could set up wireless access points around coffee shops in December, point the DNS provided at those WAPs to my own server and run a fake amazon.com site to capture account credentials and credit cards. Without EV, that's a plausible attack. Especially with SSL being not-by-default, someone could type amazon.com and it can be intercepted without showing any certificate warning -- which then allows a redirect to a lookalike amazon.com name that could get certified by something like LetsEncrypt.)

Plus, clouds have had a protocol available for doing queries to certs and keys held by other parties for several years. Cloudflare developed this protocol for banks, for whom loss of control of the certificate key is a reportable event, but who also often need DDoS protection. There's no reason it can't be extended to other clouds and sites -- unless Cloudflare patented it and wants royalties, in which case their rent-seeking is destroying the security of the web by convincing cloud salesmen to say that EV is too much trouble to deal with and thus should be killed off in the marketplace.

Demanding that EV be perfect and dropping support for it if it has any found vulnerability falls into a class of human behavior known as "letting the perfect be the enemy of the good", which is also known as "cutting off the nose to spite the face".  It still cuts down on a huge number of potential attacks, and doing away with it allows those attacks to flourish again. (Which, by the way, is what organized crime would prefer to permit.)

-Kyle H


On Thu, Dec 6, 2018, 14:07 Blumenthal, Uri - 0553 - MITLL <[hidden email] wrote:
>    > Quoting from Peter Gutmann's "Engineering Security",
>    > section "EV Certificates: PKI-me-Harder"
>    >
>    >      Indeed, cynics would say that this was exactly the problem that
>    >      certificates and CAs were supposed to solve in the first place, and
>    >      that “high-assurance” certificates are just a way of charging a
>    >      second time for an existing service.
>   
>    Peter Gutman, for all his talents, dislikes PKI with a vengeance.
>     EV is a standard for OV certificates done right.  Which involves more
>    thorough identity checks, stricter rules for the CAs to follow etc.

>     The real point of EV certificates is to separate CAs that do a good
>    job from those that do a more sloppy job, without completely distrusting
>    the mediocre CA operations.

So, a CA that's supposed to validate its customer before issuing a certificate, may do a "more sloppy job" if he doesn't cough up some extra money.

I think Peter is exactly right here. CA either do their job, or they don't. If they agree to certify a set of attributes, they ought to verify each one of them.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (7K) Download Attachment
12