OpenSSL 1.0.0 Stable snaps

[hdf sdesdh]

I recently tried to compile openssl 1.0.0-beta2 with apache to enable support for ECC crypto.  It compiled fine, though I ran into errors later on...  I then decided to compile the most recent snapshot of 1.0.0 stable.  To my surprise, none of the ECC ciphers showed up in the ciphers -v list, which I thought was the default for all versions after 0.99.

Is support being dropped?  

Thanks

--
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dr. Stephen Henson]

On Wed, Jun 24, 2009, hdf sdesdh wrote:

> I recently tried to compile openssl 1.0.0-beta2 with apache to enable
> support for ECC crypto.  It compiled fine, though I ran into errors later
> on...  I then decided to compile the most recent snapshot of 1.0.0 stable.
> To my surprise, none of the ECC ciphers showed up in the ciphers -v list,
> which I thought was the default for all versions after 0.99.
>
> Is support being dropped?  
>

It is supported in 1.0.0. Are you seeing an earlier version of openssl
somewhere on your path?

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Peter Sylvester-3]

Hello,

In 1.0.0beta it seems that the interface between
the certificate verify callback and the store context
has slightly changed.

The X509_STORE_CTX_get_current_cert may now
return NULL which was not the case  before the
introduction of policy checking.

Is it the responsibility of the callback not to assume
a non-null pointer now, for example not to simply
call X509_oneline to format the cert subject?

At least the verify callbacks currently in use in
apps check this (except for s_cb which is used
by s_server, but which is not yet affected).

The example in the openssl docs uses

X509_NAME_oneline(X509_get_subject_name(err_cert), buf, 256);

but also:

X509_NAME_oneline(X509_get_issuer_name(ctx->current_cert)


Thanks in advance for any information.

Peter Sylvester





 
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dr. Stephen Henson]

On Wed, Jun 24, 2009, Peter Sylvester wrote:

> Hello,
>
> In 1.0.0beta it seems that the interface between
> the certificate verify callback and the store context
> has slightly changed.
>
> The X509_STORE_CTX_get_current_cert may now
> return NULL which was not the case  before the
> introduction of policy checking.
>
> Is it the responsibility of the callback not to assume
> a non-null pointer now, for example not to simply
> call X509_oneline to format the cert subject?
>
> At least the verify callbacks currently in use in
> apps check this (except for s_cb which is used
> by s_server, but which is not yet affected).
>
> The example in the openssl docs uses
>
> X509_NAME_oneline(X509_get_subject_name(err_cert), buf, 256);
>
> but also:
>
> X509_NAME_oneline(X509_get_issuer_name(ctx->current_cert)
>
>

Those examples need updating. Use of X509_NAME_oneline() has been discouraged
for some time.

While this is true it wont happen unless you explicitly set policy checking
along with some additional flags. If an application does set the extra flags
it is expected to understand the implications in the callback.

One case is when you set a flag to require an explicit policy but there is
none in the chain. In that case the error isn't tied to one particular
certificate but the chain itself.

The other case is when you set a flag to notify that policy checking has
succeeded. Again this means the whole chain is OK and not indicating anything
right/wrong with a particular certificate.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Victor B. Wagner]

On 2009.06.24 at 10:28:35 -0500, hdf sdesdh wrote:

> I recently tried to compile openssl 1.0.0-beta2 with apache to enable
> support for ECC crypto.  It compiled fine, though I ran into errors

It is not so simple. Apache uses some very percular data structures
to handle keys and certificates inside mod_ssl, and these structures
support only DSA and RSA.

Some time ago I've developed patch for Apache 2.2.x, to allow use of
GOST algorithms. As a side effect it should also enable all other
algorithms, supported by OpenSSL 0.9.9/1.0.0

Patch is available at
http://www.cryptocom.ru/OpenSource/apache-2.2.6-openssl-1.0.0.diff.gz

and should work with recent patchlevels of apache (above 2.2.6) as well.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Peter Sylvester-3]

Somehow I missed the response. Good, that there are archives:


 > Those examples need updating. Use of X509_NAME_oneline() has been discouraged
 > for some time.
Yes, seems so,
Any other function that takes a NULL X509* may also have a problem.
My question was simply to confirm that a NULL pointer *can* happen.

 > While this is true it wont happen unless you explicitly set policy checking
 > along with some additional flags. If an application does set the extra flags
 > it is expected to understand the implications in the callback.
Yes. If they are documented :-)

 > One case is when you set a flag to require an explicit policy but there is
 > none in the chain. In that case the error isn't tied to one particular
 > certificate but the chain itself.

 > The other case is when you set a flag to notify that policy checking has
 > succeeded. Again this means the whole chain is OK and not indicating anything
 > right/wrong with a particular certificate.
That is what I figured out.

I am not asking for a change, here a kind of devil's advocate argument:
Leaving the pointer unchanged (i.e. the end entity) would that hurt much?
One could still interprete:
"no policy related to the chain that ends with the cert ..."
and  "The chain for cert xxx is valid and we have policy yyy".

At least in case of the missing explicit policy error,
a callback may want to log something of the chain.

 > Steve.

Anyway, thanks for the answer.
/P
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...