Error in creating Server request.
Hi, We have installed 64 bit SSL-enabled Apache 2.2.6 on solaris 10(64 bit). Used CFLAGS=-O3 -m64 LDFLAGS=-m64 When tried to create server request as:- At apacheinstallroot/openssl/openssl$openssl req -new -key server.key -out server.csr gives an error openssl req -new -key server.key -out server.csr Unable to load config info Enter pass phrase for server.key: unable to find 'distinguished_name' in config problems making Certificate Request 371:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or envir onment variable:conf_lib Please suggest. Thanks. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
Re: Static global - bug? (Re: Two valgrind warnings in OpenSSL -possible bug???)
Well my hybrid threaded app now seems to be stable - even under extreme loads. Here is what I did for others to refer: Comments *most* welcome. These steps allow me to link both builds of my program with the same non-threaded OpenSSL build. I.e. both the fork() and pthread_create() builds of my software. 1. Use my own BIO object (BIO_new) so that OpenSSL does not use socket ops - allows me to use the library asyncronously and avoids errno+threading issues. 2. Use my own RAND object (RAND_set_rand_method) so that OpenSSL does not try lock static globals. 3. Use my own EXDATA object (CRYPTO_set_ex_data_implementation(my_impl)) - this is a problem because the st_CRYPTO_EX_DATA_IMPL object is not declared in the header - you have to copy and paste it from the OpenSSL source. My EXDATA object is a dummy opject - it does nothing and asserts when you try do a dup. I'm not using ex_data in my app - and quite honestly I'm not really sure what it's for. 4. Disable all OpenSSL caching of sessions - (SSL_CTX_set_session_cache_mode (ctx, SSL_SESS_CACHE_NO_INTERNAL | SSL_SESS_CACHE_SERVER | SSL_SESS_CACHE_NO_AUTO_CLEAR)) use the callbacks ( SSL_CTX_sess_set_new_cb etc.) and handle session caching and session expiry myself. 5. Declare only one SSL_CTX context per thread. 6. Build OpenSSL with no-threads and -DOPENSSL_NO_LOCKING Am I doing anything completely insane here? -paul
Re: Two valgrind warnings in OpenSSL - possible bug???
Paul Sheer wrote: I valgrind'ed OpenSSL as follows: I compiled OpenSSL (0.9.8g) with my own random number engine - in order to generate pseudo random numbers that are not based on unitialized values (if you run openssl without doing this you get infinite warnings - of course). The results are as follows ==26139== Conditional jump or move depends on uninitialised value(s) ==26139==at 0x81095FF: BN_mod_inverse (bn_gcd.c:215) ==26139==by 0x810D29F: BN_MONT_CTX_set (bn_mont.c:406) ==26139==by 0x8103E8F: BN_mod_exp_mont (bn_exp.c:417) ==26139==by 0x81036E9: BN_mod_exp (bn_exp.c:223) ==26139==by 0x81090FD: BN_BLINDING_create_param (bn_blind.c:352) ==26139==by 0x80C9844: RSA_setup_blinding (rsa_lib.c:413) ==26139== ==26139== Conditional jump or move depends on uninitialised value(s) ==26139==at 0x8128F5A: BN_div (bn_div.c:190) ==26139==by 0x810D318: BN_MONT_CTX_set (bn_mont.c:417) ==26139==by 0x8103E8F: BN_mod_exp_mont (bn_exp.c:417) ==26139==by 0x81036E9: BN_mod_exp (bn_exp.c:223) ==26139==by 0x81090FD: BN_BLINDING_create_param (bn_blind.c:352) ==26139==by 0x80C9844: RSA_setup_blinding (rsa_lib.c:413) ...above repeated several times. The code that gives the error is the BN_get_flags() macro (see bn_div.c extract about line 190 below): Could this be highlighting a bug in OpenSSL? Kind regards -paul Reading the 0.9.8g code I see no uninitialized variables in these code paths.The BIGNUM pointers which are passed to the BN_get_flags() macro are parameters passed into the BN_mod_inverse() and BN_div() functions. In BN_MONT_CTX_set() those BIGNUM objects are initialized. I do not see why this warning is being triggered. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
RE: Static global - bug? (Re: Two valgrind warnings in OpenSSL -possible bug???)
Am I doing anything completely insane here? IMO, writing security software by doing something that is specifically not documented or guaranteed to work and then trying to fix every problem it creates (at least, that you can find) is completely insane. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Static global - bug? (Re: Two valgrind warnings in OpenSSL -possible bug???)
IMO, writing security software by doing something that is specifically not documented or guaranteed to work and then trying to fix every problem it creates (at least, that you can find) is completely insane. Guaranteed to work? Who's doing the indemnification? Security's all about trade-offs. If you can make some simplifying assumptions that cut out large parts of code you might well be better off. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Static global - bug? (Re: Two valgrind warnings in OpenSSL -possible bug???)
IMO, writing security software by doing something that is specifically not documented or guaranteed to work and then trying to fix every problem it creates (at least, that you can find) is completely insane. Ok, I managed to find another problem: error setting/getting (eg. ERR_clear_error) is done on a per-thread basis - requiring proper locking to access a global hash table. -paul
Re: Static global - bug? (Re: Two valgrind warnings in OpenSSL -possible bug???)
Paul Sheer wrote: Well my hybrid threaded app now seems to be stable - even under extreme loads. 2. Use my own RAND object (RAND_set_rand_method) so that OpenSSL does not try lock static globals. How are you sure of this ? Did you manually remove the object code from the library, or place an abort(); call at the points -DPURIFY is listed to you can be sure that execution never gets there. 6. Build OpenSSL with no-threads and -DOPENSSL_NO_LOCKING Am I doing anything completely insane here? If you are rebuilding OpenSSL why don't you throw in -DPURIFY and piece by piece undo each point you listed until the problem comes back. That would be far more useful to the mailing-list than all this other information. If I read things correctly, You have a hybrid threaded app but OpenSSL does not have any threading support. Maybe this is okay since all the things you disabled might end up causing no thread sensitive code path to execute. To no-threads option is intended for a single threaded execution environment. Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Static global - bug? (Re: Two valgrind warnings in OpenSSL -possible bug???)
Guaranteed to work? Who's doing the indemnification? The point of a guarantee is that it is much less likely to change on another machine or if a library is upgraded and compatability is claimed. Of course, things can still go wrong. When bugs are fixed in a library or a new version claims compatability with an old version, every effort it made to ensure that whatever guarantees were provided with the old version are still met by the new version. If you stick to those guarantees, and they are sufficient that you don't need additional assumptions, you are much less likely to run into a problem if the library is upgraded or otherwise different from the one you tested with. Security's all about trade-offs. If you can make some simplifying assumptions that cut out large parts of code you might well be better off. The risk that a dynamic library on another machine will break his assumptions is greater than any benefit from eliminating code. This is especially true in this case, where it's hard to imagine any risk created by adding locks (other than deadlock, which would seem to be very unlikely to pose a security risk). Removing all the problems you can find is simply not a reliable way to develop software. You have to design the software such that there aren't problems, then remove any that slipped through. You can't use testing as the way to create the guarantee in the first place. The design has to be bug-resistant in the first place. To use an engineering analogy, imagine if you design a bridge. You fail to specify what type of steel to use, but when you test, you pick a very high-quality steel. Did you validate the bridge design? The answer is no, because you tested with only one steel, and the design isn't limited to that one steel. On the flip side, if you design to the guarantees the steel manufacturer provides, specify steel that meets those guarantees, and test with that steel, then you have a validated design. Responding to Paul: Since OpenSSL can be compiled as a non-locking, single-threaded library, I'm trying to answer the question: If I have one context per thread, will these contexts trash each others data when OpenSSL is compiled with no locking. The first 4 points of my list are the trashings that could take place. Now I just need the complete list :-) You missed step 1. As far as I know, *no* platform provides that code compiled single-threaded is thread-safe in fundamental ways. For example, AFAIK, there is no guarantee that 'malloc' won't be optimized in a single-threaded compile in ways that break horribly on multi-threaded code. You need the completel list for your *platform* and an assurance that no new entries will be added to that list on any platform your code will compile on or run on. Absent such a guarantee, your attempt is a disaster waiting to happen even if it works in the first place. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
