openssl ca mode
Hi, I have downloaded openssl-engine-0.9.6g I try to run openssl ca -policy policy_anthing -out newcert.pem -passin pass:whatever -key whatever -extensions xpclient_ext -extfile xpextensions \ -infiles newreq.pem It complains that -extfile is not ca's arg. but I check www.openssl.org/docs/apps/ca.html -extfile is described there. Do you have to do something on openssl.cnf to enable that option? Thanks. Augustine __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
All (most?) similar cases clear the 'init' flag *after* having set up
the data structures appropriately, e.g. see ssl/s3_meth.c.
Yes, SSLv3_client_method is the only one I saw which had init set in the
wrong place. I may have missed some.
No locking should be needed because the assignments are idempotent.
However, the assignments are not atomic. The following unprotected
operation:
if (init)
{
memcpy((char *)SSLv3_server_data,(char *)sslv3_base_method(),
sizeof(SSL_METHOD));
SSLv3_server_data.ssl_accept=ssl3_accept;
SSLv3_server_data.get_ssl_method=ssl3_get_server_method;
init=0;
}
can result in a thread calling .ssl_accept or .get_ssl_method after the
memcpy but before the assignment. In this case, ssl_undefined_function is
called and it errors out.
To make this code properly thread-safe, locks and atomic sets should be used
to protect any non-atomic functions working on shared data.
patrick
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #287] [PATCH] no-engine (openssl-0.9.7-stable-SNAP-20020918)
Here is the patch for configuring-out the engine. This one should work; the previous one had a single misplaced #ifndef. I've tested it both with and without the no-engine option for the following platforms: Cygwin VC-WIN32 (dll and static) VC-CE (dll and static) Linux VC-CE is the Windows CE port that I'm working on and the reason that I need the no-engine option, although I imagine that I'll need it in my day job too when we upgrade. Is it possible to get this into a 0.9.7 snapshot soon? I'll need it before I can finalise the port. Regards, Steven __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #274] session ID length bug (in 0.9.6g and 0.9.7beta3)
On Thu, Sep 19, 2002 at 01:44:01PM +0200, Bodo Moeller via RT wrote: I don't know why that message is empty. What I wrote is that this should now be fixed in the current snapshots (0.9.6-stable and 0.9.8-dev -- seems I forgot about 0.9.7-stable, this will have the fix tomorry). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Thu, Sep 19, 2002 at 06:28:16PM -0700, Patrick McCormick wrote:
No locking should be needed because the assignments are idempotent.
However, the assignments are not atomic. The following unprotected
operation:
if (init)
{
memcpy((char *)SSLv3_server_data,(char *)sslv3_base_method(),
sizeof(SSL_METHOD));
SSLv3_server_data.ssl_accept=ssl3_accept;
SSLv3_server_data.get_ssl_method=ssl3_get_server_method;
init=0;
}
can result in a thread calling .ssl_accept or .get_ssl_method after the
memcpy but before the assignment.
Can you elaborate? In such cases the other thread should execute the
'if' body too. A potential problem is not about atomicity, but about
reordering of statements (if the assignment to 'init' happens before
on of the other assignements, we have a problem), so it might be
better to make those static variables 'volatile'.
(I'm aware that the code still is bad in theory, but it should work
for all implementations. There's more stuff like that in OpenSSL, but
I can't rewrite all of it ...)
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Thu, Sep 19, 2002 at 06:28:16PM -0700, Patrick McCormick wrote:
No locking should be needed because the assignments are idempotent.
However, the assignments are not atomic. The following unprotected
operation:
if (init)
{
memcpy((char *)SSLv3_server_data,(char *)sslv3_base_method(),
sizeof(SSL_METHOD));
SSLv3_server_data.ssl_accept=ssl3_accept;
SSLv3_server_data.get_ssl_method=ssl3_get_server_method;
init=0;
}
can result in a thread calling .ssl_accept or .get_ssl_method after the
memcpy but before the assignment.
Can you elaborate? In such cases the other thread should execute the
'if' body too. A potential problem is not about atomicity, but about
reordering of statements (if the assignment to 'init' happens before
on of the other assignements, we have a problem), so it might be
better to make those static variables 'volatile'.
(I'm aware that the code still is bad in theory, but it should work
for all implementations. There's more stuff like that in OpenSSL, but
I can't rewrite all of it ...)
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: openssl ca mode
On Freitag, 20. September 2002 00:43, vze2ksv3 wrote: Hi, I have downloaded openssl-engine-0.9.6g I try to run openssl ca -policy policy_anthing -out newcert.pem -passin pass:whatever -key whatever -extensions xpclient_ext -extfile xpextensions \ -infiles newreq.pem It complains that -extfile is not ca's arg. but I check www.openssl.org/docs/apps/ca.html -extfile is described there. from CHANGES : ... Changes between 0.9.6g and 0.9.7 [XX xxx 2002] ... *) New '-extfile ...' option to 'openssl ca' for reading X.509v3 extensions from a separate configuration file. As when reading extensions from the main configuration file, the '-extensions ...' option may be used for specifying the section to use. [Massimiliano Pala [EMAIL PROTECTED]] ... = it's a new feature in OpenSSL 0.9.7 Do you have to do something on openssl.cnf to enable that option? try OpenSSL 0.9.7 ;-) Regards, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Tue, Sep 03, 2002 at 05:29:41PM -0700, Patrick McCormick wrote:
I needed to add the following calls in my single-thread openssl setup code
to end several race conditions:
SSLv23_client_method();
SSLv2_client_method();
SSLv3_client_method();
TLSv1_client_method();
SSLv23_method();
SSLv2_method();
SSLv3_method();
TLSv1_method();
SSLv23_server_method();
SSLv2_server_method();
SSLv3_server_method();
TLSv1_server_method();
ssl2_get_cipher_by_char(XXX);
ssl3_get_cipher_by_char(XXX);
These functions appear to follow the same pattern (the
..._get_cipher_by_char functions actually use locks because they do
more than just simple assignments and copying).
I also see race conditions in crypto/rand/md_rand.c that I don't see a
workaround for. There's an init race in ssleay_rand_bytes. Multiple
threads can call in and end up in the initialization code if init==0. I'm
not sure why there is a lock around if (init), since this lock doesn't
prevent multiple initialization.
These threads then both call RAND_seed (ssleay_rand_seed, for me) at once.
ssleay_rand_seed modifies globals without any locking, so it doesn't appear
thread safe.
Er, what version of OpenSSL are you looking at? In 0.9.6g, we have
static int ssleay_rand_bytes(unsigned char *buf, int num)
{
[...]
CRYPTO_w_lock(CRYPTO_LOCK_RAND);
/* prevent ssleay_rand_bytes() from trying to obtain the lock again */
CRYPTO_w_lock(CRYPTO_LOCK_RAND2);
locking_thread = CRYPTO_thread_id();
CRYPTO_w_unlock(CRYPTO_LOCK_RAND2);
crypto_lock_rand = 1;
if (!initialized)
{
RAND_poll();
initialized = 1;
}
so the call to RAND_poll() (and eventually to ssleay_rand_see())
happens inside the write lock, meaing that only a single thread can do
this at a time.
ssleay_rand_bytes modifies globals (md, md_count, etc.) without locking, so
the random byte buffer can be filled from md while another thread is
rewriting the contents of md. Also, md_count[0]++ has undefined
results.
md_count[0] += 1 and access to md happens while the thread has the
CRYPTO_LOCK_RAND lock. Some accesses to the state array are not
protected by locking, however, because it does not really matter which
thread wins.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #274] session ID length bug (in 0.9.6g and 0.9.7beta3)
On Fri, Sep 20, 2002 at 10:34:27AM +0200, Bodo Moeller wrote: On Thu, Sep 19, 2002 at 01:44:01PM +0200, Bodo Moeller via RT wrote: I don't know why that message is empty. What I wrote is that this should now be fixed in the current snapshots (0.9.6-stable and 0.9.8-dev -- seems I forgot about 0.9.7-stable, this will have the fix tomorry). RT2 seems to have problems with some MIME messages... But sorry, no, I currently don't have time to look into it.. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
A small correction to avoid a warning in MSVC
Dear OpenSSL developers, I have noticed that a warning is issued when compiling Openssl in MSVC. To remove it I suggest the following two small changes: In file openssl/asn1_mac.h Change in the definition of M_ASN1_D2I_get_EXP_set_opt the line (void (*)())free_func, b,V_ASN1_UNIVERSAL) == NULL) \ to: (void (*)(void *))free_func, b,V_ASN1_UNIVERSAL) == NULL) \ Change in the definition of M_ASN1_D2I_get_imp_set the line (void (*)())free_func,a,b) == NULL) \ to: (void (*)(void *))free_func,a,b) == NULL) \ I hope they are both correct (It's just one month that I am using/digging into the openssl internals ... :-) ) All the best! AndreaS __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL-0.9.7 RSA keys
Using 0.9.7 beta 3, I am attempting to output an RSA public/private key pair created by RSA_generate_key() as ASN.1 encoded strings. For the public key, I am using i2d_RSA_PUBKEY which calls i2d_PUBKEY - i2d_X509_PUBKEY. i2d_X509_PUBKEY seems to execute though I can't find the code anywhere in the source. It returns a correct length but the result string is empty - all zero's. I am using i2d_PKCS8_PRIV_KEY_INFO() to get the ASN.1 encoded private key as a PKCS8 PrivateKeyInfo. This behaves the same way: returns length but empty value. In both cases the data structures were correctly set up with good values. Is the problem that these are phantom functions? I get no error during compiling or linking, so where are they Is there a better way to do this? The opposite functionality using d2i_ works just fine. Chris Brook V-ONE __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: SSL-0.9.7 RSA keys
I have found the problem and fixed it in my code, so please ignore. However, for general info, it seems that the i2d_ low-level functions modify the data pointer passed in (it is an unsigned char **), so I could not see the result. Copying the pointer to another and passing the address of that in solves the problem. I had come across this with decoding so I guess it's a global quirk in the code! Chris Brook -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Brook Sent: Friday, September 20, 2002 10:08 AM To: Openssl-Dev (E-mail) Subject: SSL-0.9.7 RSA keys Using 0.9.7 beta 3, I am attempting to output an RSA public/private key pair created by RSA_generate_key() as ASN.1 encoded strings. For the public key, I am using i2d_RSA_PUBKEY which calls i2d_PUBKEY - i2d_X509_PUBKEY. i2d_X509_PUBKEY seems to execute though I can't find the code anywhere in the source. It returns a correct length but the result string is empty - all zero's. I am using i2d_PKCS8_PRIV_KEY_INFO() to get the ASN.1 encoded private key as a PKCS8 PrivateKeyInfo. This behaves the same way: returns length but empty value. In both cases the data structures were correctly set up with good values. Is the problem that these are phantom functions? I get no error during compiling or linking, so where are they Is there a better way to do this? The opposite functionality using d2i_ works just fine. Chris Brook V-ONE __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL-0.9.7 RSA keys
On Fri, Sep 20, 2002, Chris Brook wrote: I have found the problem and fixed it in my code, so please ignore. However, for general info, it seems that the i2d_ low-level functions modify the data pointer passed in (it is an unsigned char **), so I could not see the result. Copying the pointer to another and passing the address of that in solves the problem. I had come across this with decoding so I guess it's a global quirk in the code! Its intended behaviour and was needed to make the old ASN1 code work. Strictly speaking it isn't needed with the new ASN1 code but it is retained for compatibility. This issue crops up frequently so it was added to the FAQ... Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
However, the assignments are not atomic. The following unprotected
operation:
if (init)
{
memcpy((char *)SSLv3_server_data,(char *)sslv3_base_method(),
sizeof(SSL_METHOD));
SSLv3_server_data.ssl_accept=ssl3_accept;
SSLv3_server_data.get_ssl_method=ssl3_get_server_method;
init=0;
}
can result in a thread calling .ssl_accept or .get_ssl_method after the
memcpy but before the assignment.
Can you elaborate? In such cases the other thread should execute the
'if' body too. A potential problem is not about atomicity, but about
reordering of statements (if the assignment to 'init' happens before
on of the other assignements, we have a problem), so it might be
better to make those static variables 'volatile'.
Here's one step by step scenario.
Thread T1 enters the if block, does the memcpy, does the assignments, and
then a context switch occurs.
Thread T2 enters the if block (since init is still 1) and a context switch
occurs.
Thread T1 sets init=0, exits the function, and a context switch occurs.
Thread T2 performs the memcpy. Context switch.
Thread T1 does some stuff, and eventually calls SSL_set_session, which calls
get_ssl_method. Because get_ssl_method has been reinitialized to
ssl_undefined_function by the memcpy, this method errors out.
There are other scenarios to exploit this race condition. The bottom line
is that you must either use a single atomic function to alter static data,
or a lock around a group of nonatomic operations.
(I'm aware that the code still is bad in theory, but it should work
for all implementations. There's more stuff like that in OpenSSL, but
I can't rewrite all of it ...)
The thread-unsafe code in OpenSSL should be fixed, or you should just advise
users that while OpenSSL happens to work in most cases so far, the code is
not threadsafe.
patrick
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
