Hi there,
As I'd mentioned a while back, there seems to be some form of behavioural
change in the machinery underneath SSL_CTX_load_verify_locations that has
it spitting tacks where previously it was happy. As far as I can spot,
this affects ssltest, s_server, s_client, and four different parts of
Ralf's mod_ssl (the only other OpenSSL-based source I could readily grep
without expending more effort than I have available).
Eg. if you call;
./openssl s_client -cert somecert.pem -CAfile someca.pem -state -connect
.....[etc]
and someca.pem contains only a valid CA cert (no CRL), then you should get
hit with;
11495:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:639:Expecting:
X509 CRL
11495:error:0B070009:x509 certificate routines:X509_load_crl_file:missing asn1
eos:by_file.c:229:
This is on a pretty recent snapshot but I tracked the problem a while back
to having been introduced Oct 26-27 or thereabouts. It seems (not worth
believing without checking for yourself) that the CA cert *is* added into
the SSL_CTX ok but the errors still get thrown out and
SSL_CTX_load_verify_locations returns with an error code (which is where
s_server and s_client continue ok because I think they ignore it). Any
thoughts?
On another note ...
Is there a way we can incorporate the snprintf from Apache (ap_snprintf)
or any other platform-independant version for use in OpenSSL? A few people
of late seem to be drawing attention to BIO_printf. I decided to steer as
clear as I could of BIOs a while back as too many "odd" things seemed to
be happening that didn't make a lot of sense to me - but I'm a picky ****
so that's my problem :-) However, it only takes one OpenSSL-based app to
use BIO_printf to log something (eg. a one-line version of a cert's DN) to
a file, and causing it to log something that is slightly over 2048 bytes
will make things go bang in a rude (and hacker-controllable) way. With
it's focus heavily on "security" - it doesn't make much sense for OpenSSL
to only offer a "BIO_printf" function that has no buffer-overflow
protection.
There's also the classic ...
crypto/bio/b_print.c, BIO_printf(), line 73;
MS_STATIC char hugebuf[1024*2]; /* 10k in one chunk is the limit */
That's the strangest definition of 10k I've seen for some time. Thankfully
when I checked up on MS_STATIC it turns out it's only "static" on
platforms I doubt could turn that into a race condition as well.
There's a couple of people on this list who are also involved rather
heavily with Apache ... how do the licenses stand up to "code-sharing" of
that sort ... and if the answer is "badly", is there an alternative we
could pull in rather than leaving this as-is or having to code something
from scratch?
cheers,
Geoff
----------------------------------------------------------------------
Geoff Thorpe Email: [EMAIL PROTECTED]
Cryptographic Software Engineer, C2Net Europe http://www.int.c2.net
----------------------------------------------------------------------
May I just take this opportunity to say that of all the people I have
EVER emailed, you are definitely one of them.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
