SSL session resumption not working after upgrading from openssl-0.9.7e to openssl-0.9.8g
Please help am I missing something Baig
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Hi David,
that is really nice.. although.. after I gave it a try... it does not really
work :(
Actually, it seems that the dynamic functions are never called... :(
Investigating...
Later,
Max
David Schwartz wrote:
Hi all,
it seems that I am missing the usage of the set of obscure functions:
CRYPTO_set_dynlock_create_callback()
CRYPTO_set_dynlock_lock_callback()
CRYPTO_set_dynlock_destroy_callback()
but I have no idea how to initialize those functions - is there
any example
on how to do that by using pthreads ?
Ciao,
Max
Off the top of my head, and untested, but it should give you the idea:
struct CRYPTO_dynlock_value
{
pthread_rwlock_t lock;
};
#ifndef CRYPTO_LOCK
#define CRYPTO_LOCK 0x01
#define CRYPTO_UNLOCK 0x02
#define CRYPTO_READ 0x04
#define CRYPTO_WRITE0x08
#endif
void locking_callback(int mode, struct CRYPTO_dynlock_value *l,
const char *, int)
{
if(mode==(CRYPTO_LOCK|CRYPTO_READ))
pthread_rwlock_rdlock(l-lock);
else if(mode==(CRYPTO_LOCK|CRYPTO_WRITE))
pthread_rwlock_wrlock(l-lock);
else if(mode==(CRYPTO_UNLOCK|CRYPTO_READ))
pthread_rwlock_unlock(l-lock);
else if(mode==(CRYPTO_UNLOCK|CRYPTO_WRITE))
pthread_rwlock_unlock(l-lock);
}
struct CRYPTO_dynlock_value *create_callback(const char *, int)
{
CRYPTO_dynlock_value *l=(CRYPTO_dynlock_value *)
malloc(sizeof(CRYPTO_dynlock_value));
pthread_rwlock_init(l-lock, NULL);
return l;
}
void destroy_callback(struct CRYPTO_dynlock_value *l, const char *, int)
{
pthread_rwlock_destroy(l-lock);
free(l);
}
void InitDynLocks(void)
{
CRYPTO_set_dynlock_create_callback(create_callback);
CRYPTO_set_dynlock_lock_callback(locking_callback);
CRYPTO_set_dynlock_destroy_callback(destroy_callback);
}
DS
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
Best Regards,
Massimiliano Pala
--o
Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED]
[EMAIL PROTECTED]
Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory Work Phone: +1 (603) 646-9179
--o
People who think they know everything are a great annoyance to those of us
who do.
-- Isaac Asimov
smime.p7s
Description: S/MIME Cryptographic Signature
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Max, Hi David, that is really nice.. although.. after I gave it a try... it does not really work :( Actually, it seems that the dynamic functions are never called... :( Investigating... Later, Max It seems, that indeed the dynamic locking functions are not doing the trick here. I have encountered a similar problem with pthreads and nShield 500 when performing X.509 cert. signing. nCipher recommended to put dynamic locks in place but as in your case - it did not help. Try to create your own static mutex and put it around your code right where you perform the signing/verification operation - that should help I think. Without looking at the code, I am not sure what is the exact problem at your end but in my case (although I never went to properly investigate this matter) it looked like it was related to simultaneous communications between the application and the nfast server which sits in the middle between the application and the actual hardware device. I also remember, that nCipher provides a patch for OpenSSL 0.9.8x that makes some small changes to the original OpenSSL implementation of CHIL. P.M. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client verify failing - continued
Dave Thompson wrote:
As a note: The certificates are *fine* I have used them successfully
with s_client and s_server tests. They verify perfectly well.
The one you've attached, yes; the one you are generating in code,
maybe not, because s_client (and s_server) never does that.
Right, although I dont want to verify the generated one, which would
be pointless cos it isnt signed by a ca. The autogenerated one is just
there for encryption and does not provide any verification, it isnt
designed to.
So, the conversation goes as follows.
It seems overwhelmingly likely, but just to be absolutely clear,
I presume private_key and public_key are buffers containing
the servercert.pem and serverkey.pem files you posted.
You could read the files directly with _use_certificate_file
and _use_PrivateKey_file, which is usually more convenient.
Also, you don't show BIO_free for second bio (mem leak).
The bio free was omitted accidentally, it is done in the code. Its
done this way as this is all part of a library, which needs to accept
keys from memory, to allow greatest flexibility.
Ive just run a test changing the code to use a file, and no change.
SERVER: SSL_accept(sssl) //Keep on doing this until WANT_READ
stops
Server didn't do (SSL_CTX|SSL)_set_verify ? If so (as previously noted)
it shouldn't be requesting client to authenticate at all.
The server doesnt request the client verify. It would fail if it did
as the keys arent signed by a ca, just auto generated.
CLIENT: len=i2d_RSAPublicKey(rsakey,correct_sized_buf)
//Move correct_sized_buf back to its start
CLIENT: pubrsa=d2i_RSAPublicKey(NULL,correct_sized_buf,len)
Aside: I THINK you don't actually need this i2d-d2i conversion,
if you just set a (tagged) RSA* that happens to be a privatekey
it can be encoded as a publickey (because of how RSA works).
Right, this is one of those things I got after many hours trawling
through websites.
CLIENT: X509_set_version(ccert,3);
Aside: I'm pretty sure that should be 2. X.509 version 3 is
the version of the standard but the certs actually have a
version field value of 2. In fact you apparently aren't using
extensions, so a value of 0 meaning version 1 would work.
Fair enough
CLIENT: X509_set_notBefore(ccert,timebound);
CLIENT: X509_set_notAfter(ccert,timebound);
Aside: the same time? Normally you want notBefore=some_time
and notAfter=some_later_time (typically +3mo/2yr/10yr, etc.)
Yeah, I do set those values to proper times (yesterday/yext year), I
just didnt think it was worth mentioning, as its all for the generated
key
CLIENT: SSL_CTX_use_PrivateKey(cctx,ckey);
CLIENT: SSL_CTX_use_certificate(cctx,ckey)
I hope that's a typo and you meant ccert there.
Yeah, I did. Sorry
So your client has created its own selfsigned cert, using (and for)
a key the server knows nothing about. If this was actually used
for authentication it should fail, because the server has no reason
to trust it. But per above the server is probably not requesting it,
and per below you are getting an error before client auth anyway.
Yeah, the server doesnt need to know who the client is in this
instance. The generated keys are for encryption only.
CLIENT: SSL_connect(cssl);//Keep on doing this until WANT_READ
stops
**HERE** We get the error on SSL_connect after a few WANT_READS
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
So, thats the routine used. The exact reverse, where the client uses
the same keys and the server has the same ca, works just fine.
I'm not sure what you mean by client uses 'same keys' since you show
client generating a different, and probably useless, key on each run.
Yes, I mean, if the process is reversed. Giving the verifiable keys to
the client and having the server generate random keys. The library is
designed to work with both, either, or none of the parties having
verifiable keys.
But if server has use_privatekey/certificate of serverkey/cert.pem
and client has load_verify_locations of rootcert.pem, it should pass
this step = server authentication. (I suspect you will still have
a problem with client authentication, but that's a different matter.)
You could try writing a verify callback used in the client that logs
or displays some convenient bits of the received cert/chain and check
they are as they should be, or just debug it and look at the same.
Maybe you have a bug in your multithreading, but those tend to be erratic;
could you perhaps configure one process to run only the client thread
and a different one to run only the server thread?
Same happens on different processes.
Thanks, I'll go look at how on earth to write a verify callback, which
I have no idea how to do, but the oreilly and the source code should
be able to give me a clue. Only problem is, Im not really sure what Im
looking for {:-)
Thanks
--
Michael Simms
Re: SSL session resumption not working after upgrading from openssl-0.9.7e to openssl-0.9.8g
Baig, Attaullah wrote: Please help am I missing something You are most likely not using the correct header files. Some constants changed. -- Arno Garrels Baig __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
OpenSSL 0.9.8i breaks SMIME sign/verify ??
Hi forks,
I've been using OpenSSL 0.9.8h, I use it for SMIME sign/verify. I've just
upgraded to OpenSSL 0.9.8i and my code doesn't work anymore.
The error is: [error:21075081:PKCS7 routines:PKCS7_verify:smime text error]
After spending sometime to investigate, I see the only diff is: the SMIME_text
function (crypto/asn1/asn_mime.c) in 0.9.8i was added the check for len
variable:
if (len 0)
return 0;
I don't know why we need this check. But my code works on 0.9.8h (the one
without the check). Could someone give me a hint?
Here's is the code for signing:
...
flags = PKCS7_DETACHED;
flags |= PKCS7_STREAM;
flags |= PKCS7_NOCERTS;
flags |= PKCS7_TEXT;
p7 = PKCS7_sign(pCert,pPrivKey,NULL,in, flags);
if (!p7){
ret = ERRROR_INVALID;
goto done;
}
SMIME_write_PKCS7(out,p7,in, flags);
And here the code for verifying:
...
flags = PKCS7_NOVERIFY;
flags |= PKCS7_TEXT;
p7 = SMIME_read_PKCS7(in, indata);
if (!p7){
ret = ERROR_INVALID;
goto done;
}
certs = sk_X509_new_null();
sk_X509_push(certs,pCert);
if (PKCS7_verify(p7,certs,NULL,indata,out,flags)){
...
Thanks!
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL 0.9.8i breaks SMIME sign/verify ??
On Fri, Nov 21, 2008, ThanhTrung Do wrote: Hi forks, I've been using OpenSSL 0.9.8h, I use it for SMIME sign/verify. I've just upgraded to OpenSSL 0.9.8i and my code doesn't work anymore. The error is: [error:21075081:PKCS7 routines:PKCS7_verify:smime text error] After spending sometime to investigate, I see the only diff is: the SMIME_text function (crypto/asn1/asn_mime.c) in 0.9.8i was added the check for len variable: if (len 0) return 0; I don't know why we need this check. But my code works on 0.9.8h (the one without the check). Could someone give me a hint? The reason for that is to detect I/O errors in the stream. The only reason I can think of for different behaviour is if you have a memory BIO: http://www.openssl.org/support/faq.html#PROG15 If that isn't the case do you get this problem with the command line utility too? If so post the message and command line you used, privately if you wish. 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL 0.9.8i breaks SMIME sign/verify ??
The reason for that is to detect I/O errors in the stream.
The only reason I can think of for different behaviour is
if you have a memory
BIO:
http://www.openssl.org/support/faq.html#PROG15
Thanks for your quick reply.
Yes, I'm using memory BIO, I tried to call BIO_set_mem_eof_return(), but got
the same error. Here is what I tried in my verifying routing:
...
BIO_set_mem_eof_return(indata, 0);
if (PKCS7_verify(p7,certs,NULL,indata,out,flags)){
...
Did I miss anything?
Thank you.
From: Dr. Stephen Henson [EMAIL PROTECTED]
Subject: Re: OpenSSL 0.9.8i breaks SMIME sign/verify ??
To: openssl-users@openssl.org
Date: Friday, November 21, 2008, 7:41 PM
On Fri, Nov 21, 2008, ThanhTrung Do wrote:
Hi forks,
I've been using OpenSSL 0.9.8h, I use it for SMIME
sign/verify. I've just upgraded to OpenSSL 0.9.8i and my
code doesn't work anymore.
The error is: [error:21075081:PKCS7
routines:PKCS7_verify:smime text error]
After spending sometime to investigate, I see the only
diff is: the SMIME_text function (crypto/asn1/asn_mime.c) in
0.9.8i was added the check for len variable:
if (len 0)
return 0;
I don't know why we need this check. But my code
works on 0.9.8h (the one without the check). Could someone
give me a hint?
The reason for that is to detect I/O errors in the stream.
The only reason I can think of for different behaviour is
if you have a memory
BIO:
http://www.openssl.org/support/faq.html#PROG15
If that isn't the case do you get this problem with the
command line utility
too? If so post the message and command line you used,
privately if you wish.
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@openssl.org
Automated List Manager
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
How can I select selected cipher suites...
Dear All, Thank you Dr. Stephen Henson for your Help. I want to enable some selected cipher suite like TLS_RSA_WITH_AES_256_CBC_SHA. Can it is possible. I selected some specific Algorithm RSA, 3DES, AES,DES, SHA and MD5. So I want to enable cipher suite which support to above algorithms only. Can I use any API? Please guide me on this. Thank you. Regards, --Ajeet Kumar Singh image001.jpg
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
On Friday 21 November 2008 03:01:33 Massimiliano Pala wrote:
Hi David,
that is really nice.. although.. after I gave it a try... it does not
really work :(
Actually, it seems that the dynamic functions are never called... :(
Investigating...
The attached example seems to work. I put it in the top-level directory
of the (built) openssl tree and compiled with;
gcc -Wall -Iinclude -o foobar foobar.c -L. -lcrypto
The output shows that dynamic lockids are negative;
About to test
Created lock 'dyn_lck.c:257'
Created lock 'dyn_lck.c:257'
Got new locks -1, -2
Doing mode 9 lock on 'dyn_lck.c:257' from foobar.c:47
Locked the lock
Doing mode 10 lock on 'dyn_lck.c:257' from foobar.c:49
Unlocked the lock
Destroying lock 'dyn_lck.c:257' from dyn_lck.c:329
Destroying lock 'dyn_lck.c:257' from dyn_lck.c:329
Destroyed the locks, DONE
Perhaps that'll help distinguish what's going on in your code?
Cheers,
Geoff
--
Un terrien, c'est un singe avec des clefs de char...
#include stdlib.h
#include stdio.h
#include string.h
#include openssl/crypto.h
struct CRYPTO_dynlock_value;
static struct CRYPTO_dynlock_value *l_create(const char *f, int l)
{
char *foo = malloc(256);
if (!foo)
return NULL;
snprintf(foo, 255, %s:%d, f, l);
printf(Created lock '%s'\n, foo);
return (void *)foo;
}
static void l_lock(int mode, struct CRYPTO_dynlock_value *v,
const char *f, int l)
{
char *foo = (char *)v;
printf(Doing mode %d lock on '%s' from %s:%d\n,
mode, foo, f, l);
}
static void l_destroy(struct CRYPTO_dynlock_value *v,
const char *f, int l)
{
char *foo = (char *)v;
printf(Destroying lock '%s' from %s:%d\n,
foo, f, l);
free(foo);
}
int main(int argc, char *argv[])
{
int lock, lock2;
CRYPTO_set_dynlock_create_callback(l_create);
CRYPTO_set_dynlock_lock_callback(l_lock);
CRYPTO_set_dynlock_destroy_callback(l_destroy);
printf(About to test\n);
lock = CRYPTO_get_new_dynlockid();
lock2 = CRYPTO_get_new_dynlockid();
printf(Got new locks %d, %d\n, lock, lock2);
CRYPTO_w_lock(lock);
printf(Locked the lock\n);
CRYPTO_w_unlock(lock);
printf(Unlocked the lock\n);
CRYPTO_destroy_dynlockid(lock);
CRYPTO_destroy_dynlockid(lock2);
printf(Destroyed the locks, DONE\n);
return 0;
}
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Hello Przemek, thanks for the advice - I already tried to use a mutex to protect the OCSP_basic_sign(), but I wanted to avoid it as this will just use only one thread at a time. It seems that nCipher is best used with a simple fork() daemon... if it wasn't for the shared memories, still today a forked daemon is more robust than a multi-threaded one.. :( Thanks for the advice - I will now put the locks back in place and see if the server does not crash anymore... :D Later, Max Przemek Michalski wrote: Max, Hi David, that is really nice.. although.. after I gave it a try... it does not really work :( Actually, it seems that the dynamic functions are never called... :( Investigating... Later, Max It seems, that indeed the dynamic locking functions are not doing the trick here. I have encountered a similar problem with pthreads and nShield 500 when performing X.509 cert. signing. nCipher recommended to put dynamic locks in place but as in your case - it did not help. Try to create your own static mutex and put it around your code right where you perform the signing/verification operation - that should help I think. Without looking at the code, I am not sure what is the exact problem at your end but in my case (although I never went to properly investigate this matter) it looked like it was related to simultaneous communications between the application and the nfast server which sits in the middle between the application and the actual hardware device. I also remember, that nCipher provides a patch for OpenSSL 0.9.8x that makes some small changes to the original OpenSSL implementation of CHIL. P.M. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-9179 --o People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov smime.p7s Description: S/MIME Cryptographic Signature
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Hello Przemek, thanks for the advice - I already tried to use a mutex to protect the OCSP_basic_sign(), but I wanted to avoid it as this will just use only one thread at a time. It seems that nCipher is best used with a simple fork() daemon... if it wasn't for the shared memories, still today a forked daemon is more robust than a multi-threaded one.. :( Thanks for the advice - I will now put the locks back in place and see if the server does not crash anymore... :D Later, Max Przemek Michalski wrote: Max, Hi David, that is really nice.. although.. after I gave it a try... it does not really work :( Actually, it seems that the dynamic functions are never called... :( Investigating... Later, Max It seems, that indeed the dynamic locking functions are not doing the trick here. I have encountered a similar problem with pthreads and nShield 500 when performing X.509 cert. signing. nCipher recommended to put dynamic locks in place but as in your case - it did not help. Try to create your own static mutex and put it around your code right where you perform the signing/verification operation - that should help I think. Without looking at the code, I am not sure what is the exact problem at your end but in my case (although I never went to properly investigate this matter) it looked like it was related to simultaneous communications between the application and the nfast server which sits in the middle between the application and the actual hardware device. I also remember, that nCipher provides a patch for OpenSSL 0.9.8x that makes some small changes to the original OpenSSL implementation of CHIL. P.M. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Hi Sander, I definitely did - now I do initialize all the static locks in OpenSSL *and* the dynamic functions. But they are never called by the chil - the assert fails and the SIGABRT is sent to my daemon forcing it to exit. For some reason it seems the dynamic locking functions do not function properly, I am trying to investigate further... Anybody knows where can I find the patched OpenSSL version from nCipher ? Later, Max P.S.: As this code is basically the same for every application, what about integrating a nice OPENSSL_init_pthread() function that will initiate all the static locks and the dynamic functions ? That would save *a lot of time* to many people.. :D If you do not use pthreads, then you might want to provide your own.. but at least 90% of apps can be safely ported to be multi threaded... Sander Temme wrote: You don't need that if you set the dynamic upcalls. Did you apply that patch? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Hi Geoff, I actually tried the same approach, I had a small test function that I call at the start of each thread that initializes, locks, unlocks and destroys the dyn locks.. and the functions are properly called. unsigned long lock, lock2 = 0; printf(About to test\n); lock = CRYPTO_get_new_dynlockid(); lock2 = CRYPTO_get_new_dynlockid(); printf(Got new locks %lu, %lu\n, lock, lock2); CRYPTO_w_lock(lock); printf(Locked the lock\n); CRYPTO_w_unlock(lock); printf(Unlocked the lock\n); CRYPTO_destroy_dynlockid(lock); CRYPTO_destroy_dynlockid(lock2); printf(Destroyed the locks, DONE\n); the result, for each new thread is: Got new locks 4294967283, 4294967295 Locked the lock Unlocked the lock Destroyed the locks, DONE and in the logs, the functions properly log the start and end of each _dyn_ function, that is: ... Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_create_callback() start Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_create_callback() stop Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_lock_callback() start Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_lock_callback() end ... Therefore it seems that the callbacks are properly registered! The problem is that they are not called by the nCipher driver - no sign at all in the logs... :( How come they are not called ??? Later, Max Geoff Thorpe wrote: On Friday 21 November 2008 03:01:33 Massimiliano Pala wrote: Hi David, that is really nice.. although.. after I gave it a try... it does not really work :( Actually, it seems that the dynamic functions are never called... :( Investigating... The attached example seems to work. I put it in the top-level directory of the (built) openssl tree and compiled with; gcc -Wall -Iinclude -o foobar foobar.c -L. -lcrypto The output shows that dynamic lockids are negative; About to test Created lock 'dyn_lck.c:257' Created lock 'dyn_lck.c:257' Got new locks -1, -2 Doing mode 9 lock on 'dyn_lck.c:257' from foobar.c:47 Locked the lock Doing mode 10 lock on 'dyn_lck.c:257' from foobar.c:49 Unlocked the lock Destroying lock 'dyn_lck.c:257' from dyn_lck.c:329 Destroying lock 'dyn_lck.c:257' from dyn_lck.c:329 Destroyed the locks, DONE Perhaps that'll help distinguish what's going on in your code? Cheers, Geoff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
On Nov 21, 2008, at 8:50 AM, Max Pala wrote: The problem is that they are not called by the nCipher driver - no sign at all in the logs... :( How come they are not called ??? Can you set a breakpoint in engines/e_chil.c:581 and inspect the value of disable_mutex_callbacks? It should be 0 and if it isn't, libnfhwcrhk never learns about the existence of the locks. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
On Nov 21, 2008, at 8:07 AM, Max Pala wrote: I definitely did - now I do initialize all the static locks in OpenSSL *and* the dynamic functions. But they are never called by the chil - the assert fails and the SIGABRT is sent to my daemon forcing it to exit. The library needs both the static locks and the dynamic locking upcalls. Anybody knows where can I find the patched OpenSSL version from nCipher ? /opt/nfast/toolkits/openssl/openssl098e-patch.txt Should apply cleanly to newer versions of OpenSSL, with patch -p1. It creates a static lock for CHIL to use so it doesn't need the dynamic ones available. I personally think the dynamic locking concept is more elegant, but I do agree it smells of duplicated code because everyone has to set up the same scaffolding. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Have observed a similar problem despite the fact the nCipher patch is applied and crypto locks (both static and dynamic) are set. Have never properly investigated it so perhaps now is the time... I checked this with two versions of OpenSSL 0.9.8h (without nCipher patch and with the patch). BTW - the most part of the patch is that it adds support for static locks. My application has also all necessary dynamic as well as static crypto locks setup. scenario 1: - without nCipher patch - without my own static mutex around signing operation - result: application aborts and the nCipher CHIL client library generates an error: ../client.c:762: receive: Assertion `!!(((void)multiple threads active, but no synchronization upcalls, u.app-mutexcreateupcall))' failed. (also some times the nfast server fails to respond or at least this is the error message that I am getting from time to time from the CHIL client library) scenario 2: - without nCipher patch - with my own static mutex around signing operation - result: everything works well with many threads however in fact only single thread accesses the device at a time (which is not really ideal but in the same way does not greatly reduce the performance) scenario 3: - with nCipher patch - without my own static mutex around signing operation - result: application aborts (abort signal) but no library error is generated this time scenario 4: - with nCipher patch - with my own static mutex around signing operation - result: everything works well with many threads however in fact only single thread accesses the device at a time While debugging the application, I can see static crypto locks being used but the dynamic ones not. P.M. - Original Message - From: Max Pala [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Friday, November 21, 2008 5:50 PM Subject: Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500) Hi Geoff, I actually tried the same approach, I had a small test function that I call at the start of each thread that initializes, locks, unlocks and destroys the dyn locks.. and the functions are properly called. unsigned long lock, lock2 = 0; printf(About to test\n); lock = CRYPTO_get_new_dynlockid(); lock2 = CRYPTO_get_new_dynlockid(); printf(Got new locks %lu, %lu\n, lock, lock2); CRYPTO_w_lock(lock); printf(Locked the lock\n); CRYPTO_w_unlock(lock); printf(Unlocked the lock\n); CRYPTO_destroy_dynlockid(lock); CRYPTO_destroy_dynlockid(lock2); printf(Destroyed the locks, DONE\n); the result, for each new thread is: Got new locks 4294967283, 4294967295 Locked the lock Unlocked the lock Destroyed the locks, DONE and in the logs, the functions properly log the start and end of each _dyn_ function, that is: ... Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_create_callback() start Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_create_callback() stop Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_lock_callback() start Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_lock_callback() end ... Therefore it seems that the callbacks are properly registered! The problem is that they are not called by the nCipher driver - no sign at all in the logs... :( How come they are not called ??? Later, Max Geoff Thorpe wrote: On Friday 21 November 2008 03:01:33 Massimiliano Pala wrote: Hi David, that is really nice.. although.. after I gave it a try... it does not really work :( Actually, it seems that the dynamic functions are never called... :( Investigating... The attached example seems to work. I put it in the top-level directory of the (built) openssl tree and compiled with; gcc -Wall -Iinclude -o foobar foobar.c -L. -lcrypto The output shows that dynamic lockids are negative; About to test Created lock 'dyn_lck.c:257' Created lock 'dyn_lck.c:257' Got new locks -1, -2 Doing mode 9 lock on 'dyn_lck.c:257' from foobar.c:47 Locked the lock Doing mode 10 lock on 'dyn_lck.c:257' from foobar.c:49 Unlocked the lock Destroying lock 'dyn_lck.c:257' from dyn_lck.c:329 Destroying lock 'dyn_lck.c:257' from dyn_lck.c:329 Destroyed the locks, DONE Perhaps that'll help distinguish what's going on in your code? Cheers, Geoff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Sander, /opt/nfast/toolkits/openssl/openssl098e-patch.txt Could you send/post the nCipher patch 0.9.8e - I am using one supplied originally by nCipher for 0.9.8a Although the patch I have works well with all 0.9.8x versions I would be keen to compare them just for my own curiosity. thanks, P.M. - Original Message - From: Sander Temme [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Friday, November 21, 2008 6:09 PM Subject: Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500) On Nov 21, 2008, at 8:07 AM, Max Pala wrote: I definitely did - now I do initialize all the static locks in OpenSSL *and* the dynamic functions. But they are never called by the chil - the assert fails and the SIGABRT is sent to my daemon forcing it to exit. The library needs both the static locks and the dynamic locking upcalls. Anybody knows where can I find the patched OpenSSL version from nCipher ? /opt/nfast/toolkits/openssl/openssl098e-patch.txt Should apply cleanly to newer versions of OpenSSL, with patch -p1. It creates a static lock for CHIL to use so it doesn't need the dynamic ones available. I personally think the dynamic locking concept is more elegant, but I do agree it smells of duplicated code because everyone has to set up the same scaffolding. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
On Nov 21, 2008, at 9:45 AM, Przemek Michalski wrote: /opt/nfast/toolkits/openssl/openssl098e-patch.txt Could you send/post the nCipher patch 0.9.8e - I am using one supplied originally by nCipher for 0.9.8a The source code bits in the patch are the same. The 'a' patch is better, the 'e' version clobbers your openssl.cnf. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
On Friday 21 November 2008 11:07:19 Max Pala wrote: P.S.: As this code is basically the same for every application, what about integrating a nice OPENSSL_init_pthread() function that will initiate all the static locks and the dynamic functions ? That would save *a lot of time* to many people.. :D If you do not use pthreads, then you might want to provide your own.. but at least 90% of apps can be safely ported to be multi threaded... This is part of some overhauls I'm hoping to put together for the next release, if I can achieve that before 0.9.9 is tagged and released. It's won't be possible to do this is for the 0.9.8-stable branch though. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Engine Issue: nShield 500
On Nov 20, 2008, at 5:13 PM, Max Pala wrote:
Hi Sander,
yep the order is correct - the thread callbacks (pthread) init
function
is before the Engine initialization (which happens before the spawning
of the threads).
The error you are describing sounds definitely familiar - although my
magic number is 12 (if I use 13 threads then... crash...). The
backtrace
is not really useful as well - unless you have the source code:
Thank you for the backtrace. This does not give us any insight in the
parts that are your code, just the OpenSSL and libnfhwcrhk bits.
Would you mind compiling with -g to include debug symbols in your
binary, and then running the backtrace again? It would be nice to see
what code path triggers this assert(), and what parameter values you
pass in.
Thanks,
S.
0xb7fe5410 in ?? ()
(gdb) backtrace
#0 0xb7fe5410 in ?? ()
#1 0xb5a3e3f8 in ?? ()
#2 0x0006 in ?? ()
#3 0x27a0 in ?? ()
#4 0xb7cd8811 in raise () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7cd9fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7cd1fbf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#7 0xb7adbada in receive (conn=0x8086380, cctx=0xb5a3ebf0,
replyp=0xb5a3e86c,
tctx_r=0x0, nonblocking=0, functionname=0xb7b41ce0 Wait)
at ../client.c:945
#8 0xb7adc3eb in NFastApp_Wait (conn=0x8086380, cctx=0xb5a3ebf0,
replyp=0x0,
tctx_r=0x0) at ../client.c:982
#9 0xb7adaa1b in NFastApp_Transact (conn=0x8086380, cctx=0xb5a3ebf0,
command=0x0, reply=0xb5a3e9e0, tctx=0x0) at ../client.c:211
#10 0xb7ab40e9 in nfast_hwch_command (upc=0xb5a3ebf0, conn=0x0,
remember=0,
command=0xb5a3eaa0, reply=0xb5a3e9e0, status_r=0x0, ebuf=0x0,
ebuflen=0)
at ../command.c:15
#11 0xb7ab42a1 in nfast_hwch_command_chk (upc=0xb5a3ebf0, conn=0x0,
remember=0, command=0x0, reply=0x0, what=0x0) at ../command.c:59
#12 0xb7aaf338 in nfast_hwch_raw_rsa (upc=0xb5a3ebf0, conn=0x0,
remember=0,
key=0, msg=
{buf = 0x808ba68 \210E\032��\234�6�ED*\220�h��2Bʸ
\217, size = 128},
result=0x0) at ../keys.c:260
#13 0xb7aaf214 in HWCryptoHook_RSA (msg=
{buf = 0x808ba68 \210E\032��\234�6�ED*\220�h��2Bʸ
\217, size = 128},
k=0x806c858, result=0x0, errors=0xb5a3f0c0) at ../keys.c:260
#14 0xb7b7bc1f in bind_engine () from /usr/lib/ssl/engines/libchil.so
#15 0xb7ee7736 in RSA_PKCS1_SSLeay ()
from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#16 0x0808bf10 in ?? ()
#17 0x0808bee8 in ?? ()
#18 0x08072078 in ?? ()
#19 0x0808be30 in ?? ()
#20 0xce86bb62 in ?? ()
#21 0x03d508e8 in ?? ()
#22 0x0021 in ?? ()
#23 0xb7f8d830 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#24 0xb7f7c048 in CAST_S_table7 () from /usr/lib/i686/cmov/
libcrypto.so.0.9.8
#25 0x0080 in ?? ()
#26 0x0808bee8 in ?? ()
#27 0x0808bf10 in ?? ()
#28 0x0808befc in ?? ()
#29 0x0807eed8 in ?? ()
#30 0x08085558 in ?? ()
#31 0x0010 in ?? ()
#32 0x in ?? ()
Any Idea ???
Later,
Max
Sander Temme wrote:
On Nov 19, 2008, at 11:24 PM, Max Pala wrote:
The software that I am writing is a multi-threaded OCSP responder.
Please make sure you initialize the engine correctly, and set up
your locking callbacks before you actually initialize the engine.
If you look at Apache:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?view=markup
the invocation of ssl_init_Engine() and ssl_util_thread_setup()
used to be in the wrong order, which led to Apache children
crashing on an assert() from within the Hardware Crypto Hook
library (libnfhwcrhk) whenever more than five threads were used.
Sounds familiar?
If that is all in order, perhaps you can trap that assert() in gdb
and take a backtrace.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
smime.p7s
Description: S/MIME cryptographic signature
Re: OpenSSL 0.9.8i breaks SMIME sign/verify ??
On Fri, Nov 21, 2008, ThanhTrung Do wrote:
The reason for that is to detect I/O errors in the stream.
The only reason I can think of for different behaviour is
if you have a memory
BIO:
http://www.openssl.org/support/faq.html#PROG15
Thanks for your quick reply.
Yes, I'm using memory BIO, I tried to call BIO_set_mem_eof_return(), but got
the same error. Here is what I tried in my verifying routing:
...
BIO_set_mem_eof_return(indata, 0);
if (PKCS7_verify(p7,certs,NULL,indata,out,flags)){
...
Did I miss anything?
Ah there's a bug in the handling of the SMIME_TEXT flag which was only
apparent when error checking was performed on the I/O functions. I've just
committed a fix to CVS. It is:
http://cvs.openssl.org/chngview?cn=17654
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 Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Sander Temme wrote: /opt/nfast/toolkits/openssl/openssl098e-patch.txt I found a 'openssl098-patch.txt' is that ok ? Should apply cleanly to newer versions of OpenSSL, with patch -p1. It creates a static lock for CHIL to use so it doesn't need the dynamic ones available. It did. I personally think the dynamic locking concept is more elegant, but I do agree it smells of duplicated code because everyone has to set up the same scaffolding. Yes, I agree. Callbacks are really elegant (but a pain to debug!). And I think that a default function that would fit most users would be nice.. :D I just installed the patched version - but no changes in the behavior.. I will try to inspect the `disable_mutex_callbacks`.. but if that is the case, how shall I fix it ??? Later, Max __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
FIXED - CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Hi Sander, I debugged the init process and it seems that you were right. The disable_mutex_callbacks is set to 1 at e_chil.c:578. Definitely it is due to initialization, at this point... ... looked into that, and... et voilas! Found the problem! The PRE commands were wrong. Indeed the following: 5.engine_pre = THREAD_LOCKING:1 caused the disable_mutex_callbacks to be set to 1, therefore no callbacks were used! A... what a nightmare! If you want to be sure, you can set it to 0: 5.engine_pre = THREAD_LOCKING:0 Przemek, this should solve also your problem - so you can enable multiple threads and get rid of your 'lock' around the signing function. I think that the config variable should have been called: DISABLE_THREAD_LOCKING because if THREAD_LOCKING is set to 1 - then the disable_mutex_callbacks is set to 1.. which should be the contrary (developer's error ?). Very confusing... and besides, it should give out some warning!!! Anyhow, now the callbacks are called, and the server seems to run pretty ok with a relatively large amount of threads (150). But I still have to stress-test it... Thanks to all of you who helped me - now I have a single file with the code for OpenSSL and pthreads, both static and dynamic locks.. Shall we include it into OpenSSL ? void OpenSSL_pthread_init( void ); .. that would make it more usable for the average developer! :D Later, Max Sander Temme wrote: On Nov 21, 2008, at 8:50 AM, Max Pala wrote: The problem is that they are not called by the nCipher driver - no sign at all in the logs... :( How come they are not called ??? Can you set a breakpoint in engines/e_chil.c:581 and inspect the value of disable_mutex_callbacks? It should be 0 and if it isn't, libnfhwcrhk never learns about the existence of the locks. S. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIXED - CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
On Nov 21, 2008, at 11:12 AM, Massimiliano Pala wrote:
Hi Sander,
I debugged the init process and it seems that you were right. The
disable_mutex_callbacks is set to 1 at e_chil.c:578. Definitely it
is due to initialization, at this point...
... looked into that, and... et voilas! Found the problem! The PRE
commands were wrong. Indeed the following:
5.engine_pre = THREAD_LOCKING:1
caused the disable_mutex_callbacks to be set to 1, therefore no
callbacks were used! A... what a nightmare! If you want to be
sure, you can set it to 0:
5.engine_pre = THREAD_LOCKING:0
Przemek, this should solve also your problem - so you can enable
multiple threads and get rid of your 'lock' around the signing
function.
I think that the config variable should have been called:
DISABLE_THREAD_LOCKING
because if THREAD_LOCKING is set to 1 - then the
disable_mutex_callbacks
is set to 1.. which should be the contrary (developer's error ?).
Yes, this is confusing. The problem is that it's been like this for
years and years, so you can't just turn the name or value around like
that. At least not in the Stable branch. I think that would cause
almost as much confusion as the present situation. I would suggest a
documentation fix, like so:
Index: engines/e_chil.c
===
RCS file: /home/openssl/cvs/openssl/engines/e_chil.c,v
retrieving revision 1.9
diff -u -r1.9 e_chil.c
--- engines/e_chil.c19 Nov 2008 14:21:26 - 1.9
+++ engines/e_chil.c21 Nov 2008 19:24:37 -
@@ -164,11 +164,11 @@
ENGINE_CMD_FLAG_STRING},
{HWCRHK_CMD_FORK_CHECK,
FORK_CHECK,
- Turns fork() checking on or off (boolean),
+ Turns fork() checking on (non-zero) or off (0),
ENGINE_CMD_FLAG_NUMERIC},
{HWCRHK_CMD_THREAD_LOCKING,
THREAD_LOCKING,
- Turns thread-safe locking on or off (boolean),
+ Turns thread-safe locking on (0) or off (non-zero),
ENGINE_CMD_FLAG_NUMERIC},
{HWCRHK_CMD_SET_USER_INTERFACE,
SET_USER_INTERFACE,
Very confusing... and besides, it should give out some warning!!!
Anyhow,
now the callbacks are called, and the server seems to run pretty ok
with a relatively large amount of threads (150). But I still have
to stress-test it...
Thanks to all of you who helped me - now I have a single file with
the code for OpenSSL and pthreads, both static and dynamic locks..
Shall we include it into OpenSSL ?
void OpenSSL_pthread_init( void );
.. that would make it more usable for the average developer! :D
We discussed this a while back, when I proposed setting the callbacks
from the CHIL engine as a fallback option when the application didn't
provide them. It breaks down on platforms where, for instance,
pthreads are scarily broken. Howerver, it would be neat if OpenSSL
could provide this scaffolding for the vast majority of users who have
a working implementation.
S.
--
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
smime.p7s
Description: S/MIME cryptographic signature
Re: FIXED - CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
On Friday 21 November 2008 14:41:08 Max Pala wrote: Hi Sander, I debugged the init process and it seems that you were right. The disable_mutex_callbacks is set to 1 at e_chil.c:578. Definitely it is due to initialization, at this point... ... looked into that, and... et voilas! Found the problem! The PRE commands were wrong. Indeed the following: 5.engine_pre = THREAD_LOCKING:1 caused the disable_mutex_callbacks to be set to 1, therefore no callbacks were used! A... what a nightmare! If you want to be sure, you can set it to 0: 5.engine_pre = THREAD_LOCKING:0 Przemek, this should solve also your problem - so you can enable multiple threads and get rid of your 'lock' around the signing function. I think that the config variable should have been called: DISABLE_THREAD_LOCKING because if THREAD_LOCKING is set to 1 - then the disable_mutex_callbacks is set to 1.. which should be the contrary (developer's error ?). Yeah, that's unfortunate. Glad you found the problem. Very confusing... and besides, it should give out some warning!!! Anyhow, now the callbacks are called, and the server seems to run pretty ok with a relatively large amount of threads (150). But I still have to stress-test it... Thanks to all of you who helped me - now I have a single file with the code for OpenSSL and pthreads, both static and dynamic locks.. Shall we include it into OpenSSL ? void OpenSSL_pthread_init( void ); As I stated in another post, I'm looking to overhaul the way certain infrastructure is setup - ie. right now; static locks, dynamic locks, memory allocation, thread IDs, ex_data, [...] are all specified independently - despite the fact they often need to be mutually-compatible. So I'm looking at combining these into platforms. My motivation is async-crypto, which requires additional infrastructure that adds to the mutual-compatibility requirements. In doing so, it'll be easier to provide pre-packaged platforms that include plug-in implementations for these things (eg. a pthreads platform, win32 platform, whatever). It should also be possible to specify default platforms from the Configure target, without limiting application ability to override. If only there were more hours in the day ... Do you agree with Sander's patch suggestion? If so, I'll put that into 0.9.8-stable and HEAD. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Server Name Indication interface
The server-side SNI support in OpenSSL seems to be targeted at HTTPS virtual host configurations, in which each Virtual host is associated with its own SSL_CTX object, initialized not only with a separate key+cert+trust chain, but also with a separate cipherlist, list of trusted CAs (really X509_STORE), plus various flags, options, ... This works reasonably well for a suitably-small set of preloaded virtual hosts. With Postfix, I'd like to not pre-load all virtual (non-default name) keys, certs and trust chains, and of course not pre-initialize multiple SSL_CTX objects. Rather, I'd like to construct the necessary state on-the-fly, using essentially a table (disk-resident indexed file) of (domain, PKCS#12 blob) pairs. There will be no support for separately tunable SSL options per target hostname, the only variables from name to name are the contents of the PKCS#12 containers associated with each name. I'd like to (if it were possible) to share the X509_STORE, cipherlist and all the other attributes of the primary (aka initial) SSL context with the SSL contexts created (on the fly) for each non-default server name. This would save the need to parse and load trusted CAs into memory multiple times and to perform unnecessarily detailed initialization of the virtual SSL_CTX objects to mirror already performed configuration of the initial SSL_CTX. One way to do this is to create stub SSL contexts that share all state other than key+cert+extra_certs with the initial SSL_CTX. /* * create stub cert with no keys, certs or extra certs, * but otherwise sharing all state with (for flags, ... cloning * all state from) a full parent context. */ SSL_CTX *stub = SSL_CTX_new_stub(initial_ctx); SSL_CTX_use_certificate(stub, cert); SSL_CTX_use_PrivateKey(stub, pkey); SSL_check_private_key(stub); .. foreach chaining cert x ... SSL_CTX_add_extra_chain_cert(stub, x); This could be used with SSL_set_SSL_CTX() in the servername callback, to associated the right certs and keys with the connection, without otherwise perturbing the SSL state. When a stub context is freed, only the key/cert/extra_certs would be freed, the rest would be owned by and freed with the initial context. This would significantly simplify the management of virtual hosts that differ only in the cert. A related question is how long the SSL_CTX created for a virtual host needs to remain in memory. Can I destroy this context after the connection is closed, or will that break session resumption? I want to keep a small number of active virtual contexts in memory, and discard them when the cache limit is reached, re-creating the context on the fly. Does resumption of cached sessions require the original virtual session to still be in memory? How are cipherlists handled when sessions are resumed? Is the client limited to the ciphers of the initial context or the ciphers of the virtual context? There may be other ways of achieving the same goal (light-weight creation/destruction of virtual host contexts), I am open to suggestions and willing to contribute code 0.9.9 if that moves this forward. Not sure whether this can be done while keeping the resulting interface binary compatible with the existing (still tentative I gather, and in any case not documented) SNI interfaces. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
