Re: [openssl.org #1701] Hi (Bug in openssl)
Mirsad Todorovac via RT wrote: Dear Mr. Cristoph Martin, I saw you are the supporter for openssl package. Afaik Mr. Martin is (beside Mr. Roeckx) supporter for the *Debian* OpenSSL package, so if you want to address specifically Mr. Martin, you should try a Debian mailing list. If on the other hand your problem report targets to the original OpenSSL distribution, you should address the OpenSSL team. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Make ssleay_rand_bytes more deterministic
Richard Stoughton wrote: On Tue, May 20, 2008 at 12:09 AM, Bodo Moeller [EMAIL PROTECTED] wrote: As far as I can understand the code, the suggested usage pattern for the RNG would be ssleay_rand_bytes(ssleay_rand_add ^ n) with n 0. If consecutive calls to ssleay_rand_bytes without intermediate calls to ssleay_rand_add are allowed, your objection is obviously more than justified. Many applications call ssleay_rand_add (or one of the wrapper functions) only once at application startup with data for example from /dev/random. People wearing both belt and suspenders may want to call ssleay_rand_add periodically during application runtime, but that's not necessary in the strict sense. - do not mix bits of the given output buffer into the internal entropy pool. Note that the second improvement may totally break already broken client software. Why would it? Clients that do not call ssleay_rand_add at all would probably get a random series with even less variance than the debianized one has. Clients not calling ssleay_rand_add at all get *no* random series, but an error code when calling ssleay_rand_bytes (and an error message requesting to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html). Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
dean gaudet wrote: On Thu, 15 May 2008, Geoff Thorpe wrote: I forgot to mention something; If you're using an up-to-date version of openssl when you see this (ie. a recent CVS snapshot from our website, even if it's from a stable branch for compatibility reasons), then please post details. -DPURIFY exists to facilitate debuggers that don't like reading uninitialised data, so if that's not the case then please provide details. Note however that there are a variety of gotchas that allow you to create little leaks if you're not careful, and valgrind could well be complaining about those instead. Note that you should always build with no-asm if you're doing this kind of debug analysis. The assembly optimisations are likely to operate at granularities and in ways that valgrind could easily complain about. I don't know that this is the case, but it would certainly make sense to compare before posting a bug report. you know, this is sheer stupidity. you're suggesting that testing the no-asm code is a valid way of testing the assembly code? additionally the suggestion of -DPURIFY as a way of testing the code is also completely broken software engineering practice. any special case changes for testing means you're not testing the REAL CODE. Where is the problem with it? When you add debugging print statements for finding an error, you are also not testing the real code, but when you have found the error, you can remove the print statements and are back to the real code. With -DPURIFY you can do the same. for example if you build -DPURIFY then you also won't get notified of problems with other PRNG seeds which are supposed to be providing random *initialized* data. not to mention that a system compiled that way is insecure -- so you either have to link your binaries static (to avoid the danger of an insecure shared lib), or set up a chroot for testing. Why is a system built with -DPURIFY insecure? I presume you don't understand what -DPURIFY does. in any event YOU'RE NOT TESTING THE REAL CODE. which is to say you're wasting your time if you test under any of these conditions. openssl should not be relying on uninitialized data for anything. even if OpenSSL doesn't rely on uninitialized data! it doesn't matter from the point of view of the PRNG, it should be pretty damn clear it's horrible software engineering practice. It's not at all clear that putting uninitialized data into a PRNG is bad software engineering practice, there may be circumstances where it is the last resort (imagine e.g. that the debian developer would have killed /dev/random instead). Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Opening an openssl encripted socket bound to a spcific interface
Thomas Schweikle wrote: Hi! can anyone give me a hint where to look on how I open an openssl encripted socket bound to a specific interface? I found bind(address), but do not have a clue on how it is used correctly! First: the openssl-users mailing list would have been more appropriate. You can create a socket bio with BIO_new_socket and connect this to an SSL object with SSL_set_bio, so that the problem is reduced to the non-SSL-specific one of binding a standard socket to an interface. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1621] [PATCH] - OS390-Unix (EBCDIC) 0.9.7m
JBYTuna wrote: Oh my. So, these patches have not been incorporated? Will they ever get incorporated? I get once or twice a year this question, but every time i have to answer: i don't know. We did not know these patches existed. We've been chasing this problem for a couple of years now. Because we've never received response to postings with regard to this problem, we felt we were on our own. [...] Any advice you might offer would be greatly appreciated. When i look at the long list of entries in http://rt.openssl.org/NoAuth/Buglist.html i can understand, that the EBCDIC patches don't have the highest priority for the OpenSSL team. Therefore the best advice i can give is to use RT entry #843 for collecting all EBCDIC related patches, so one can point the EBCDIC community to it. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1621] [PATCH] - OS390-Unix (EBCDIC) 0.9.7m
JBYTuna via RT wrote: When an OpenSSL server built on z/OS is using client verification, the following error is incurred: 0x140890b2 - error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned From tracing, we found the correct certificate was being returned. We found the code in crypto/x509/x509_vfy.c will not work in an EBCDIC environment, as the data is in ASCII. The solution is to translate the ASCII to EBCDIC, prior to the validation process. John B. Young Here's the patch, in diff -u form: The patch is already contained in #843: EBCDIC patches for 0.9.7c (http://rt.openssl.org/Ticket/Display.html?id=843user=guestpass=guest), which has been updated to 0.9.7j by Jeremy Grieshop. That patch contains also a second ASCII to EBCDIC conversion after the X509_time_adj in the region of line 960. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Any Apache/mod_ssl developers out there?
Victor B. Wagner wrote: Is there somebody involved in development of mod_ssl module for Apache? Probably the mod_ssl mailing list is a better place for finding such person(s), see http://www.modssl.org/support/. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Integration of New cipher algorithms
Omprakash wrote: Hello everybody, I have two symmetric key encryption algorithms Camellia and Seed which is properly integrated and tested with openssl 0.9.6j, which i did it for my project. Will openssl interested in integrating these algorithm with those standard list it already have. If so please tell me the right approach for doing it. According to the CHANGES file these algorithms alre already part of OpenSSL 0.9.8. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1403] rsa_eay.c: Wrong first parameter in RSAerr calls
In the error checks which have added to crypto/rsa_eay.c in version 0.9.7l RSAerr is called in function RSA_eay_public_encrypt with the first parameter RSA_F_RSA_EAY_PUBLIC_DECRYPT and in function RSA_eay_public_decrypt with the first parameter RSA_F_RSA_EAY_PUBLIC_ENCRYPT. -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: session key
DALE REAMER wrote: I should explain further. The client is using openssl, the server is on firmwware and cannot use openssl. The server developer has rc4 code and we want to verify the encryption phase after the handshake phase. If I could give him separately(offline) the session secret he could verify the server rc4 encryption/decryption is correct, (again offline). I find nothing for the session secret key, the closest is the write_mac_secret and read_mac_secret members of s3. That secret should be somewhere I could grab it with Visual C++. ssldump does a decryption if you give it the private RSA key; i don't remember whether it also displays the session secret key, but with the source of ssldump you can it modify to do it anyway. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Support for rfc3546 in openssl?
Rüdiger Plüm wrote: are there any plans to add support for rfc3546 (Transport Layer Security (TLS) Extensions), especially Server Name Indication to openssl in the near future? See the mail in this list from Peter Sylvester with the subject TLS Extension support - Server Name Indication from 13.10.2005 or see http://www.edelweb.fr/EdelKey/files/openssl-0.9.8+SERVERNAME.tar.gz Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Bug report
Cosmin Moldovan wrote: Im not sure about the correct usage pattern of the stack structures, but I think that this is a bug, found in openssl 0.9.7d, in crypto/stack/stack.c. The function sk_insert does not initialize the newly allocated pointers, when it reallocs the data array (lines 146-154). This behaviour ist not consistent with that of sk_new, which initializes the array (lines 128-129). One month ago some bugs in stack.c were corrected, please look into the newest snapshot whether the above error was corrected too. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[PATCH] Missing loop end check in crypto/engine/eng_table.c
In crypto/engine/eng_table.c the size of the accessed stack is not
checked, so regularly non-existent stack elements are tried to access.
Surprisingly often this does not crash (and all seems to function
perfectly), but sometimes it does, as expected. My problems in
connection with stunnel can be put down to this bug, and i think the
problems observed by Robert Urban and Farkas Zsolt too.
Ciao,
Richard
--
Dr. Richard W. Könning
Fujitsu Siemens Computers GmbH
--- openssl-0.9.7d/crypto/engine/eng_table.c.ori2001-11-09 14:15:05.0
+0100
+++ openssl-0.9.7d/crypto/engine/eng_table.c2004-04-08 15:46:21.447594000 +0200
@@ -286,6 +286,11 @@
goto end;
}
trynext:
+ if (loop = sk_num(fnd-sk))
+ {
+ ret = NULL;
+ goto end;
+ }
ret = sk_ENGINE_value(fnd-sk, loop++);
if(!ret)
{
Re: bug in 0.9.7d (on alpha/Tru64 UNIX V4.0F)
Robert Urban wrote: I'm wondering if the following but has been found and fixed. If so, I'd really like to know about it. backtrace: - stunnel dies on a SIGSEGV We have a similar problem on a SOLARIS/SPARC machine. A workaround is the removal of the calls of ENGINE_load_builtin_engines and ENGINE_register_all_complete at the beginning of the function context_init in ssl.c of the stunnel sources. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #843] EBCDIC patches for 0.9.7c
Because Evan Jennings asked in openssl-users for EBCDIC patches for the 0.9.7 branch, i post here my collection of EBCDIC patches for 0.9.7c. This collection comprises also the (slightly extended) patches from Howard Chu posted here some months ago. Because requests for the EBCDIC patches occur regularly, i would appreciate their incorporation into the official OpenSSL sources. We tested them in conjunction with an Apache web server and FTP/Telnet client and server. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
EBCDIC patches for 0.9.7c
Because Evan Jennings asked in openssl-users for EBCDIC patches for the 0.9.7 branch, i post here my collection of EBCDIC patches for 0.9.7c. This collection comprises also the (slightly extended) patches from Howard Chu posted here some months ago. Because requests for the EBCDIC patches occur regularly, i would appreciate their incorporation into the official OpenSSL sources. We tested them in conjunction with an Apache web server and FTP/Telnet client and server. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH ebcdic-patch.tar.gz Description: GNU Zip compressed data
Re: [openssl.org #792] Openssl (crypto) 9.7c md4test fails on Fujitsu -Siemens BS2000
mclellan, dave via RT wrote: Hi everyone: we are a little new to OpenSSL, and recently upgraded our distribution to 9.7c. I'm building on a BS2000 host. Everything builds happliy, and make test runs for a while, then starts reporting errors in MD4 tests. Before I start digging, I'd like to save a little time: Does anyone have any knowledge to share on these errors, particularly related to BS2000 Posix? (big endian, 32-bit, EBCDIC charset). The attached patches for md2test, md4test and md5test convert the test strings to ASCII before hashing them, so their hash values should be equal to the values stored in the test programs. Regards, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH mdtest.tar Description: Unix tar archive
Re: NISCC ASN.1 test suite available ?
Goetz Babin-Ebell wrote: Jostein Tveit wrote: Goetz Babin-Ebell [EMAIL PROTECTED] writes: is the NISCC test suite that found the ASN.1 bugs in OpenSSL somewhere available ? This was the answer I got when I contacted NISCC some days after the ASN.1 bug was discovered: : NISCC has a policy of only releasing the test-suite to recognised : developers of products that provide SSL/TLS services and therefore may be : vulnerable to the generic problems discovered. Unfortunately this means : that we will not be able to release the material to you. :-( Aren't you (Goetz) or your employer developers of products that provide SSL/TLS services? If yes, the problem should only be the verb recognised. In your place i would try contacting NISCC directly. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #545] Problem while compiling openssl 0.49.4
At 15:30 25.03.2003 +0100, you wrote: i've a problem compiling open ssl o.9.4. See the following output: YA7:ffpbld : /eu/ffp/archive/src/openssl-0.9.4 make making all in crypto... make[1]: Entering directory `/eu/ffp/archive/src/openssl-0.9.4/crypto' ( echo #ifndef MK1MF_BUILD; \ echo /* auto-generated by crypto/Makefile.ssl for crypto/cversion.c */; \ echo #define CFLAGS \cc -O\; \ echo #define PLATFORM \cc\; \ echo #define DATE \`date`\; \ echo #endif ) buildinf.h cc -I. -I../include -O -c -o cryptlib.o cryptlib.c make[1]: execvp: cc: Zugriff verweigert ^^ It seems to me, that you don't have the right to access the compiler ;-). Check your permissions please. N.B.: For the non-german-speaking people: Zugriff verweigert means Permission denied. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Benchmarking SSL
At 15:16 28.05.2002 -0600, you wrote: Has anyone seen anything like this that we could leverage off? Is there any source code we could use as a model or even a general discussion of the architecture that we could use in writing our own server that would be optimized to handling as many handshakes per second as possible. Look for example at Chapter 8, Coding with SSL, of Eric Rescorla's book. The source code can also be found at http://www.rtfm.com/sslbook/examples/c-examples.tar.gz. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL on the AS/400
At 10:20 16.04.2002 +0100, you wrote: If I build openssl with CHARSET_EBCDIC not defined, it fails to recognise a certificate, presumably because it fails to find the -BEGIN CERTIFICATE- string. With CHARSET_EBCDIC defined, I get a Base64 decode error, presumably because the encrypted data has been passed through an ASCII/EBCDIC filter as well. Reading certificates works for us (using BS2000). The only problem with ASCII-EBCDIC i encountered was with the X509_NAME_print_ex function: the parts of the output with stem from text strings in the code were converted too and came therefore out as garbage. I made changes to ./crypto/asn1/a_strex.c which solved almost the problem, but there are still some small parts of the output which are garbled. I don't know when i have time for looking further at this problem and making a complete patch for submitting to the mailing list (because i know almost nothing about ASN1 i'm not even sure whether my changes are made at the correct places). Before I look any deeper, can you confirm that this is the case (that CHARSET_EBCDIC just implements a crude ASCII/EBCDIC conversion filter), then I can think about what strategy I need to employ to work around this. It could be a lot more work than I had hoped ... unless I can get the compiler to handle strings as ASCII, which is in theory possible. It could be that this will more of a long-term project if that is the case. Besides the partial garbled output of Certificate Issuer and Subject names i didn't encounter EBCDIC correlated problems. Because Martin (the author of the CHARSET_EBCDIC patches) uses OpenSSL in conjunction with Apache he has made and tested the changes needed for a Web Server. Anything else may need changes at one place or another. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Openssl-09.5
At 17:54 08.04.2002 -0400, you wrote: Received this error after trying to generate key pair using openssl syntax : openssl req -new -nodes -keyout private.key -out public.csr. Error: demo1# openssl req -new -nodes -keyout private.key -out public.csr Using configuration from /usr/local/ssl/openssl.cnf unable to load 'random state' This means that the random number generator has not been seeded with much random data. Generating a 1024 bit RSA private key 1465:error:24064064:random number generator:SSLEAY_RAND_BYTES:prng not seeded:md_rand.c:470: 1465:error:04069003:rsa routines:RSA_generate_key:BN lib:rsa_gen.c:182: Please tell me how to proceed. Look at http://www.openssl.org/support/faq.html#USER1 Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Limiting key size
At 11:54 04.04.2002 -0700, you wrote: Hi folks, how can one limit and enforce the the key size that can be generated and used by openSSL and related utilities. The enforcement has to happen on multiple levels, 1. At generation. See http://www.openssl.org/docs/apps/openssl.html 2. Loading keys into the context. See http://www.openssl.org/docs/ssl/SSL_CTX_set_cipher_list.html# Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
