[openssl.org #515] 0.9.7a
Did Stephens fix solve the problem? Please answer so we can decide if there's more to this issue or if we can resolve it. Thank you. [EMAIL PROTECTED] - Wed Mar 12 10:27:11 2003]: Stephen, On Wed, 12 Mar 2003, Stephen Henson via RT wrote: [EMAIL PROTECTED] - Thu Feb 20 11:16:21 2003]: Hello, try ./config shared no-engine, then compile. Apache 1.3.27/mod_ssl crashes with segmentation fault. if i remove 'no-engine' - all ok, linux 2.4.19/gcc 2.95.3/glibc 2.1.3 I've just committed a fix which may well be the cause of this. Please try the next stable snapshot. ok, will try it. tnx. Steve. --- WBR, Alexey. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #515] 0.9.7a
Richard, I'll try as soon as fix will be available with new release - 0.9.7b I suppose. Did Stephens fix solve the problem? Please answer so we can decide if there's more to this issue or if we can resolve it. Thank you. [EMAIL PROTECTED] - Wed Mar 12 10:27:11 2003]: Stephen, On Wed, 12 Mar 2003, Stephen Henson via RT wrote: [EMAIL PROTECTED] - Thu Feb 20 11:16:21 2003]: Hello, try ./config shared no-engine, then compile. Apache 1.3.27/mod_ssl crashes with segmentation fault. if i remove 'no-engine' - all ok, linux 2.4.19/gcc 2.95.3/glibc 2.1.3 I've just committed a fix which may well be the cause of this. Please try the next stable snapshot. ok, will try it. tnx. Steve. --- WBR, Alexey. -- Richard Levitte [EMAIL PROTECTED] --- WBR, Alexey. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #516] OpenSSL-0.9.7a on IA64 with Intel compiler
[EMAIL PROTECTED] - Thu Feb 20 11:59:09 2003]: System: IA-64, SuSE SLES-8 Compiler: Intel(R) C++ Itanium(R) Compiler for Itanium(R)-based applications Version 7.0, Build 20021210 I've patched the Configure script by adding a new configuration, linux-ia64-ecc. It's based on the linux-ia64 configuration with the following changes: I just committed your patch. Also, one of the compiler warnings points to a possible bug. The file crypto/mem_clr.c contains the following: cleanse_ctr += (17 + (unsigned char)((int)p 0xF)); where p is an unsigned char*. The cast of p to type int will lose significant bits, since int is 32 bits and pointers are 64 bits. I don't know of any symptoms of this bug; in particular, casting to unsigned long rather than int doesn't fix the BN_sqr problem. Considering we only use the 4 lowest bits ( 0xF), the loss of the upper bits is a non-issue. This ticket is now resolved. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #515] 0.9.7a
In message [EMAIL PROTECTED] on Thu, 20 Mar 2003 11:51:20 +0100 (MET), Alexey Semenov via RT [EMAIL PROTECTED] said: rt I'll try as soon as fix will be available with new release - rt 0.9.7b I suppose. I'd like to ask you to please consider fetching ftp://ftp.openssl.org/snapshot/openssl-0.9.7-stable-SNAP-20030319.tar.gz and test it, to determine if we need to do more fixing *before* release of 0.9.7b (if possible). Otherwise, you just delay the fix (if one is needed) to 0.9.7c. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #515] 0.9.7a
In message [EMAIL PROTECTED] on Thu, 20 Mar 2003 11:51:20 +0100 (MET), Alexey Semenov via RT [EMAIL PROTECTED] said: rt I'll try as soon as fix will be available with new release - rt 0.9.7b I suppose. I'd like to ask you to please consider fetching ftp://ftp.openssl.org/snapshot/openssl-0.9.7-stable-SNAP-20030319.tar.gz and test it, to determine if we need to do more fixing *before* release of 0.9.7b (if possible). Otherwise, you just delay the fix (if one is needed) to 0.9.7c. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #517] Compiler warnings from crypto/pkcs12/p12_npas.c with HP ANSI comp iler
Patch applied and committed. This ticket is now resolved.
Thank you.
[EMAIL PROTECTED] - Fri Feb 21 08:30:00 2003]:
This isn't a big one, but the HP ANSI C (and the HP ANSI C++) compiler give
the following warnings when building crypto/pkcs12/p12_npas.c:
cc: warning 5004: Uninitialized variable pbe_iter in function
newpass_p12 (5004)
cc: warning 5004: Uninitialized variable pbe_saltlen in function
newpass_p12 (5004)
cc: warning 5004: Uninitialized variable pbe_nid in function newpass_p12
(5004)
This is easily addressed with the following one-line change:
$ diff -c p12_npas.c.orig p12_npas.c
*** p12_npas.c.orig Sat Dec 30 20:12:57 2000
--- p12_npas.c Thu Feb 20 17:12:51 2003
***
*** 107,113
{
STACK_OF(PKCS7) *asafes, *newsafes;
STACK_OF(PKCS12_SAFEBAG) *bags;
! int i, bagnid, pbe_nid, pbe_iter, pbe_saltlen;
PKCS7 *p7, *p7new;
ASN1_OCTET_STRING *p12_data_tmp = NULL, *macnew = NULL;
unsigned char mac[EVP_MAX_MD_SIZE];
--- 107,113
{
STACK_OF(PKCS7) *asafes, *newsafes;
STACK_OF(PKCS12_SAFEBAG) *bags;
! int i, bagnid, pbe_nid = 0, pbe_iter = 0, pbe_saltlen = 0;
PKCS7 *p7, *p7new;
ASN1_OCTET_STRING *p12_data_tmp = NULL, *macnew = NULL;
unsigned char mac[EVP_MAX_MD_SIZE];
I've been doing this for the past few 0.9.6* releases (and 0.9.7) without
introducing any problems, so I thought I'd pass it back to you.
Regards,
James
--
James A. Drenter
Planning, Architecture, and Technology Infrastructure Team
Hewlett-Packard Services Americas / Operations and I.T.
Internet: [EMAIL PROTECTED]
--
Richard Levitte
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #518] Request about OpennSSL use
Uhmmm, I don't believe this is a question for the request database. It would be a good idea if you directed your question to [EMAIL PROTECTED] I'm killing this ticket now. [EMAIL PROTECTED] - Fri Feb 21 14:30:37 2003]: Dear Sir, I'm working in a small company. We have developed a product Client(Windows)/Server(Solaris). Could you tell me if we can use the OpenSSL with ONC RPC ? I don't see any questions about it in your FAQ on your interent page ? Thanks for your interest to my question and maybe your answers. Gérard Duré Ingénieur Système et Développement. oneReason SA * Avenue des Baumettes 7 CH-1020 Renens ' +41 21 631 8835 * +41 79 608 1834 * +41 21 631 8840 * mailto:[EMAIL PROTECTED] -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #520] bug: misconfiguration on IRIX 6.5.16f with 64 CPUs
I've inserted | head -1 between the hinv command and the pipe to sed. HTH. Please try the next snapshot of 0.9.7. This ticket is now resolved. [EMAIL PROTECTED] - Wed Feb 26 09:11:56 2003]: The config script in openssl-0.9.7a uses the command 'hinv -t cpu' to determine which type of CPU is being used. It expects that the output of this command will be only for a single CPU, e.g.: CPU: MIPS R1 Processor Chip Revision: 3.4 However, on our particular system, running IRIX 6.5.16f that command instead returns a list of *all* CPUs, e.g.: CPU: MIPS R12000 Processor Chip Revision: 3.5 CPU: MIPS R12000 Processor Chip Revision: 3.5 CPU: MIPS R12000 Processor Chip Revision: 3.5 CPU: MIPS R12000 Processor Chip Revision: 3.5 CPU: MIPS R12000 Processor Chip Revision: 3.5 CPU: MIPS R12000 Processor Chip Revision: 3.5 CPU: MIPS R12000 Processor Chip Revision: 3.5 CPU: MIPS R12000 Processor Chip Revision: 3.5 . When that happens the test that determines what type of CPU is being used fails and the wrong compiler flag is used (i.e. -mips3 instead of -mips4). Not a big deal... Jeff Long -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #527] openssl-0.9.7a under Solaris needs -lxnet -lnsl
Interesting, since all our Solaris targets have -lsocket -lnsl -ldl as extra linking flags... So just to check, is -lnsl really missing in your builds, or is it just -lxnet? [EMAIL PROTECTED] - Wed Mar 5 14:00:08 2003]: Hi building openssl under Solaris 2.6 (probably also other versions) fails when linking the executable apps/openssl because library flags -lxnet -lnsl are missing (needed for socket(), connect(), etc...) Arto openssl version: 0.9.7a solaris version: 2.6 compiler version: gcc-3.1.1 -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #528]
I think I've fixed the problem. Please try tomorrows snapshot and tell me how it worked. [guest - Thu Mar 6 15:34:46 2003]: Solaris 8 [SPARC] gcc 3.3.2 openssl 0.9.7a Using ./config everything works as expected, however with ./config shared make test fails as we use LD_LIBRARY_PATH The Makefiles in ./ and ./tests set LD_LIBRARY_PATH to `pwd` rather than `pwd`:$$LD_LIBRARY_PATH Is this a bug or an error on my part many thanks iain morrison [EMAIL PROTECTED] -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #538] Errors in SSL_CTX_set_options.3
Fixed. Thanks. This ticket is now resolve. [EMAIL PROTECTED] - Sun Mar 16 19:26:20 2003]: self-sighed should be self-signed it's should be its -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #540] Changes in config
Done. Thanks. This ticket is now resolved. [EMAIL PROTECTED] - Tue Mar 18 19:23:21 2003]: OpenSSL version 0.9.7a AIX version 4.3.3 ML10 AIX does NOT respond command not found when a command can't be found. It respond with ksh: cc: not found.. Change line 461 in config (cc) 21 | grep -iv not found /dev/null CC=cc Hälsningar / Regards Kent Thureson CAE System Supervisor *Lear Corporation Sweden AB Box 942 Installatörvägen 21 SE-461 29 Trollhättan Sweden __ Desk phone: +46 (0)520 48 51 21 Fax : +46 (0)520 48 54 97 Mobile: +46 (0)704 28 68 52 E-mail: [EMAIL PROTECTED] Thureson, Kent Email address: [EMAIL PROTECTED] Lear Corporation Sweden -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #542] 0.9.7a: doc/apps/pod page omissions
Fixed. Thanks. This ticket is now resolved. [EMAIL PROTECTED] - Wed Mar 19 13:04:48 2003]: doc/apps/s_client.pod:The following command option is not mentioned -starttls prot - use the STARTTLS command before starting TLS for those protocols that support it, where 'prot' defines which one to assume. Currently, only smtp is supported. doc/apps/s_server.pod:The following command option is not mentioned -id_prefix arg - Generate SSL/TLS session IDs prefixed by 'arg' OpenSSL self-test report: OpenSSL version: 0.9.7a Last change: In ssl3_get_record (ssl/s3_pkt.c), minimize information... Options: no-krb5 OS (uname): Linux test 2.4.20 #16 Sun Mar 9 01:57:21 GMT 2003 i686 unknown OS (config): i686-whatever-linux2 Target (default): linux-elf Target: linux-elf Compiler: gcc version 2.95.2 19991024 (release) Test passed. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #527] openssl-0.9.7a under Solaris needs -lxnet -lnsl
Hi just checked: yes, all 3 flags (-lsocket -lnsl -ldl) are missing. -lsocket and -ldl seem not needed, anyway (ldd openssl also shows that they are absent, but ./openssl still runs). Only -lxnet and -lnsl are necessary. When adding these to the compiler flags, it works. Probably have done it during configure, but can't remember anymore. In any case, now, with these flags added, after deleting target apps/openssl and re-running a gmake, it compiles with the following options (without the 3 library flags you mentioned; the string -fPIC -O3 -msupersparc -Qn -Wa,-Qn -fno-ident -s -lxnet -lnsl is from my usual compiler flags where I must have added -lxnet -lnsl at some stage): gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -fPIC -O3 -msupersparc -Qn -Wa,-Qn -fno-ident -s -lxnet -lnsl -o openssl -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -DOPENSSL_NO_KRB5 openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o -L.. -lssl -L.. -lcrypto ; \ Arto - Begin Included Message - Date: Thu, 20 Mar 2003 12:24:00 +0100 (MET) From: Richard Levitte via RT [EMAIL PROTECTED] Subject: [openssl.org #527] openssl-0.9.7a under Solaris needs -lxnet -lnsl In-reply-to: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Interesting, since all our Solaris targets have -lsocket -lnsl -ldl as extra linking flags... So just to check, is -lnsl really missing in your builds, or is it just -lxnet? [EMAIL PROTECTED] - Wed Mar 5 14:00:08 2003]: Hi building openssl under Solaris 2.6 (probably also other versions) fails when linking the executable apps/openssl because library flags -lxnet -lnsl are missing (needed for socket(), connect(), etc...) Arto openssl version: 0.9.7a solaris version: 2.6 compiler version: gcc-3.1.1 -- Richard Levitte [EMAIL PROTECTED] - End Included Message - __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
2nd Re: [openssl.org #527] openssl-0.9.7a under Solaris needs -lxnet -lnsl
Hey, just found the script with which I seem to have successfully generated openssl in the end, confirming my email from just a few minutes ago: - #!/bin/csh ./Configure solaris-sparcv8:gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -fPIC -O3 -msupersparc -Qn -Wa,-Qn -fno-ident -s -lxnet -lnsl gmake - Arto - Previous Message - Hi just checked: yes, all 3 flags (-lsocket -lnsl -ldl) are missing. -lsocket and -ldl seem not needed, anyway (ldd openssl also shows that they are absent, but ./openssl still runs). Only -lxnet and -lnsl are necessary. When adding these to the compiler flags, it works. Probably have done it during configure, but can't remember anymore. In any case, now, with these flags added, after deleting target apps/openssl and re-running a gmake, it compiles with the following options (without the 3 library flags you mentioned; the string -fPIC -O3 -msupersparc -Qn -Wa,-Qn -fno-ident -s -lxnet -lnsl is from my usual compiler flags where I must have added -lxnet -lnsl at some stage): gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -fPIC -O3 -msupersparc -Qn -Wa,-Qn -fno-ident -s -lxnet -lnsl -o openssl -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -DOPENSSL_NO_KRB5 openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o -L.. -lssl -L.. -lcrypto ; \ Arto - Begin Included Message - Date: Thu, 20 Mar 2003 12:24:00 +0100 (MET) From: Richard Levitte via RT [EMAIL PROTECTED] Subject: [openssl.org #527] openssl-0.9.7a under Solaris needs -lxnet -lnsl In-reply-to: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Interesting, since all our Solaris targets have -lsocket -lnsl -ldl as extra linking flags... So just to check, is -lnsl really missing in your builds, or is it just -lxnet? [EMAIL PROTECTED] - Wed Mar 5 14:00:08 2003]: Hi building openssl under Solaris 2.6 (probably also other versions) fails when linking the executable apps/openssl because library flags -lxnet -lnsl are missing (needed for socket(), connect(), etc...) Arto openssl version: 0.9.7a solaris version: 2.6 compiler version: gcc-3.1.1 -- Richard Levitte [EMAIL PROTECTED] - End Included Message - __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Thread Question
I knew I had not explained myself well enough given your last response. I did not mean to attempt to abort the current chunck, but rather to be able to read the cancel between chunks so I could do just what you suggest. Of course, the definition of current chunk is part of my problem. I was thinking of the fact that when I do an SSL_write on a very large buffer, OpenSSL breaks it up into 16k pieces. Can I somehow do a read in between writing those 16k pieces or do I have to step back and do it between just between the chunks I sent to OpenSSL through SSL_write? BTW, we are using non-blocking sockets so I could clearly read from the socket between socket writes, but if I SSL_read from the socket during a long SSL_write operation, I am asking for trouble (with the internal state) so I don't think I can do the synchronization down at the BIO level unless I am still missing a big piece of the puzzle. Thanks again for taking the time to respond to my questions. Your feedback is very helpful. I apologize that this discussion has taken on a user tone rather than a developer tone. That was not my original intent. Verdon [EMAIL PROTECTED] 3/19/2003 5:54:04 PM On Wed, 19 Mar 2003 16:53:32 -0700, Verdon Walker wrote: First, thank you for your responses. I appreciate the feedback, but I don't think I understand the points you are making in your last email. Perhaps, I did not explain myself well enough, but the idea of allowing long operations to be cancelled is hardly rare. Suppose for example, you want to search for a friend in the phone book. Whatever criteria you specify you are going to want to stop excessive search results from continuing once you have found the person you are looking for. Supporting that in a clear text mode, but not in an SSL mode doesn't make sense. You try to send 2Mb but then interrupt it. 1,503,257 bytes have been sent. Now what do you do? Do you go back retrospectively and say, oh, I'm 39 bytes into a 512 byte protocol structure, I'll have to send 473 bytes to recover synchronization so I can start another block? I have written code layered on top of TCP for more than 16 years and I've never seen anything like this. Much more common is to stop feeding data to the socket by not sending additional chunks to the sender. In other words, you finish the current 'chunk' and don't send anymore chunks. This requires no special support from the socket code and will work fine with OpenSSL. It would seem that the SSL structure could be shared between reads and writes if we could guarantee that they didn't use the same members of the structure. Does anyone know which members are shared between both reads and writes. I know the rwstate is, but I'm not sure what else. You are barking up the wrong tree. Sending on an SSL link can require receiving from the underlying TCP stream and vice versa. You can't easily make them independent and I don't think you should want to. If you must, you can write your own send and receive functions that acquire a single lock while they're waiting for the send or receive to be possible using non-blocking sockets or BIO pairs. DS __ 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: [openssl.org #475] [Fwd: patch to 0.9.7 -performacne]
FYI - This patch doesn't appear in the source for 0.9.7a that I just downloaded. My guess is the patch would offset the cost somewhat of blinding...Recalculating Ri is expensive :) -david On Tue, 2003-02-04 at 13:57, Geoff Thorpe via RT wrote: [EMAIL PROTECTED] - Tue Feb 4 18:36:33 2003]: Attached is my patch to openssl 0.9.7. This message is CC'ed to the appropriate US gov't parties. OK. Thanks David for sorting out the US obligations, and for bringing the missing _method_mod_n initialisation to our attention. I've attached an alternative diff to yours - it includes your changes verbatim, but wraps up all _method_mod_whatever initialisations with macro-wrappers to a helper function and #if 0's out the existing code (including your additional one). BTW: This buys about 1.5% speed-up for RSA private key ops on my desktop which is of course better than a kick in the pants :-) Thanks again. I'll let this patch linger for a day or two in case anyone wants to sanity-check first. BTW: the patch is for the head of CVS but should apply to 0.9.7 with an offset of 3 lines or so, though I haven't tried (migrating your original patch the other direction worked in this fashion, however). -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #541] Problem with the blinding patch
Terry Kennedy via RT [EMAIL PROTECTED]: I downloaded and configured/built/tested 0.9.7a on BSD/OS 4.3.1 with no problems, using the following commands: [...] The tests completed with no errors. I then applied the blinding patch from http://www.openssl.org//news/secadv_20030317.txt, did make clean and then the same commands as shown above. One of the certificate request tests failed with the following output: [...] 20476:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:md_rand.c:503:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html Please try again using the latest 0.9.7a snapshot, which is available from ftp://ftp.openssl.org/snapshot;type=d (don't apply the patch, the countermeasure is included with that snapshot). The problem should now be solved; please confirm if the snapshot works for you. -- 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]
Setting RSA_blinding_on via SSL_use_RSAPrivateKey_file
Researchers have discovered a timing attack on RSA keys, to which OpenSSL is generally vulnerable, unless RSA blinding has been turned on. Typically, it will not have been, because it is not easily possible to do so when using OpenSSL to provide SSL or TLS. ... That 'not easily possible part' is definately true... I'm trying to create a patch for Stunnel that will do this in the case where someone needs to use an older version of OpenSSL for whatever reason. RSA_blinding_on is easy to set if you have access to the RSA key itself. However Stunnel uses the SSL_use_RSA_PrivateKey_file function to read the key. This function creates an RSA which it passed to SSL_use_RSAPrivateKey, but I don't see any good way to get access to that RSA data outside of the OpenSSL code itself. (If I'm reading things right, the RSA struct ends up stuck into an EVP_PKEY inside the cert_str struct inside the SSL/CTX, and it's deep enough that there seems no easy public way to get at it any more.) Does anyone have any method aside from mods to OpenSSL itself to get at the RSA that needs blinding? I'd rather not reimplement SSL_use_RSA_PrivateKEY_file s.t. I have access to the RSA struct before I send it to SSL_use_RSAPrivateKey. -- Brian Hatch A well made button Systems andhole is the only link Security Engineer between art and nature. http://www.ifokr.org/bri/ Every message PGP signed pgp0.pgp Description: PGP signature
