Bodo Moeller wrote:
> 
> Dr S N Henson <[EMAIL PROTECTED]>:
> 
> >>                         if (X509_verify(xs,pkey) <= 0)
> >>   +                             /* XXX  For the final trusted self-signed cert,
> >>   +                              * this is a waste of time.  That check should
> >>   +                              * optional so that e.g. 'openssl x509' can be
> >>   +                              * used to detect invalid self-signatures, but
> >>   +                              * we don't verify again and again in SSL
> >>   +                              * handshakes and the like once the cert has
> >>   +                              * been declared trusted. */
> >>                                 {
> >>                                 ctx->error=X509_V_ERR_CERT_SIGNATURE_FAILURE;
> >>                                 ctx->current_cert=xs;
> 
> > If I recall that bit of code I don't think the check will happen more
> > than once: though more by luck than design.
> >
> > If the certificate verifies the first time it will have its 'valid'
> > field set to 1.
> >
> > The root certificate will always be looked up and will then be placed in
> > the X509_STORE cache so subsequent lookups will always return the same
> > structure. This should mean that the check on the 'valid' field will
> > bypass the signature check after the first successful call.
> 
> However this does not help forking servers where new connections
> usually have to work with a fresh copy of the original X509_STORE
> cache.
> 

Yes you're right it wouldn't help that situation and for DSA
certificates the overhead would be considerable. 

> BTW, what is the CRYPTO_LOCK_X509_STORE lock good for?  It is obtained
> by X509_STORE_add_cert and X509_STORE_add_crl before adding something
> to ctx->objs, but the code that looks up stuff from ctx->objs would
> not be able to handle ctx->objs changing in the middle of things, so
> you cannot use X509_STORE_add_cert and X509_STORE_add_crl in
> multi-threaded programs.  Well, this locking makes it possible to use
> multiple threads to add stuff to the object cache of the same
> X509_STORE, but I'm not sure why one would want to do that.
> (As locking is per class and not per object, we have limited
> concurrency for multiple threads adding objects to the caches
> of *multiple* X509_STOREs, which is more likely to happen.)

Its probably good for nothing at all. I started analysing that stuff
some time ago and that's what caused me to conclude that it wants
completely ripping out and replacing. There's so much broken stuff in
there it's unbelievable.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to