Re: Error report
Atom [EMAIL PROTECTED]: In the crypto\bio\bss_bio.c file there is the following function: [...] I tried to compile by MS-VC it but I got error. Try OpenSSL 0.9.5-beta2. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Compilation error on OpenStep 4.0
On Sat, Mar 18, 2000 at 06:42:21PM -0700, Francisco A Tomei Torres wrote: grep clock time.h typedef unsigned long int clock_t; clock_t clock(void); clock_t clock(); And can you locate CLOCKS_PER_SEC anywhere in some header file? Also, what does the clock() manual page say about what the return value means? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Pseudo Random Number Generator
On Fri, Mar 24, 2000 at 10:30:36PM -0800, David Ahrens wrote: [... BSAFE? ...] Bodo Moeller: David Ahrens: Does anyone know if the pseudo random number generator in openssl is FIPS-140 compliant? It doesn't do power-up self tests, so it can't be. If you happen to be a federal agency, I recommend you stay away from it. [...] I don't what components of BSAFE Crypto-C are FIPS 140-1 certified. They certainly have a certified triple-DES implementation (if you look at the Security-Navigator in Netscape you'll see that you DES-based ciphers appear in two variants, one of which mentions FIPS 140-1 and one of which does not), but they don't reveal much more. The certificate is at URL: http://rsasecurity.com/products/images/fips140-1_cert.gif: It is valid "[f]or services provided by the FIPS-approved algorithms listed on the reverse, and Triple DES". Of course they did not bother to scan the reverse :-) I'd be surprised if these certified algorithms include more than DES, SHA[-1], and DSS. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Removing RSA stuff
Peden, George [EMAIL PROTECTED]: I want to disable all the RSA stuff - what do i need to do? The recommended first step is to read the documentation (or at least use grep, less, Emacs, or other tools to find the relevant parts of it); from INSTALL: Configuration Options - There are several options to ./config to customize the build: [...] no-cipher Build without the specified cipher (bf, cast, des, dh, dsa, hmac, md2, md5, mdc2, rc2, rc4, rc5, rsa, sha). The crypto/cipher directory can be removed after running "make depend". If you use OpenSSL 0.9.5a-beta2, then after "./config no-rsa" and "make", "make test" should run without problems. (Up to OpenSSL 0.9.5, the test suite did not work without RSA being available. The Windows test suite still will fail, however.) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Mutlithreading
Praveen Koppula [EMAIL PROTECTED]: How to check if SSLeay/OpenSSL has been compiled in a Multithreaded version ? What flags has to be added in the make file (NTDLL.MAK) to include multithreading support. I use WinNT 4.0 and VC++ On Windows, multi-threading is enabled by default. In general, you can look at "openssl version -f" to look at the compiler flags (or call SSLeay_version(SSLEAY_CFLAGS)); for new versions of OpenSSL, you can also define OPENSSL_THREAD_DEFINES and then include openssl/opensslconf.h and see if it defines THREADS. (The latter possibility obviously looks at header files, not at the installed library, so it doesn't make too much sense when you're using shared libraries.) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Instalation
inma [EMAIL PROTECTED]: Operating system: sun4u-sun-solaris2 WARNING! Do consider upgrading to gcc-2.8 or later (of course it´s imposible for me due to I have a restricted permissions in this machine) This system (solaris-sparcv9-gcc27) is not supported. This error message should not happen. (The warning about gcc is correct, though. Consider asking the administrator to upgrade the gcc compiler, your version cannot generate optimized code for Ultrasparc processors). Please obtain the current beta version OpenSSL 0.9.5a-beta2) and run "./config" again; if you still get the above error message, run "./Configure solaris-sparcv9-gcc27" and tell us what happens. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Compilation error on OpenStep 4.0
Francisco A. Tomei Torres [EMAIL PROTECTED]: cc -I../include -O -Wall -c ssltest.c -o ssltest.o ssltest.c: In function `main': ssltest.c:504: `CLOCKS_PER_SEC' undeclared (first use this function) Weird, this should be defined in time.h on every standard C system (it's not a POSIX special or something). Please grep through the standard header files to see if you can find this symbol anywhere. Also please read the manual page for the C function clock() and look for hints; it should say something like this: RETURN VALUE The value returned is the CPU time used so far as a clock_t; to get the number of seconds used, divide by CLOCKS_PER_SEC. In any case, please tell us if you've found something or not. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: error with make
Kalpesh U. Patel [EMAIL PROTECTED]: I am getting errors when I run make, can someone tell me why and how to fix it. (running on aix) gcc -I. -I../include -O3 -DAIX -DB_ENDIAN -c cryptlib.c In file included from /usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.1.0/2.95.2/inclu de/sys/wait.h:53, from /usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.1.0/2.95.2/inclu de/stdlib.h:227, from cryptlib.h:62, from cryptlib.c:61: /usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.1.0/2.95.2/include/sys/signal.h:580: s ys/m_signal.h: A file or directory in the path name does not exist. Looks like a broken compiler installation. Apparently you won't even be able to compile "hello world" if you include stdlib.h in it. Maybe sys/m_signal.h exists somewhere, but the directory is missing in your include path. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Pseudo Random Number Generator
David Ahrens [EMAIL PROTECTED]: Does anyone know if the pseudo random number generator in openssl is FIPS-140 compliant? It doesn't do power-up self tests, so it can't be. If you happen to be a federal agency, I recommend you stay away from it. Seriously though, if you want to implement the simple statistical tests given in FIPS PUB 140-1, then a small Perl script for examining the output of "openssl rand 25000" should be enough. However the PRNG makes extensive use of hash functions, and even if it were weak you could not expect the FIPS PUB 140-1 tests to detect the weakness; the test makes more sense when applied to PRNGs implemented in hardware (where one of the data lines might be defective or something like that). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL 0.9.5a beta1 released
Holger Reif [EMAIL PROTECTED]: Guillaume Filion: I tried to compile Openssl 0.9.5a beta 1 on SunOS 4.1.4 1 and it didn't worked (note that I never tried to compile an earlier/stable version on SunOS...). bss_bio.c:217: `ssize_t' undeclared (first use this function) Try "./config -Dssize_t=int". It didn't worked either: rupert:~/openssl-0.9.5a-beta1 ./config -Dssize_t=int Operating system: sun4u-sun-solaris2 Configuring for solaris-sparcv9-cc The first time was configured for gcc: [...] Please check, whether the config script really choosed at one tim gcc and the second time cc without any obvious reason. I just noticed that too and sent him an e-mail message asking for clarification -- note that the second time, config reported "Operating system: sun4u-sun-solaris2", which certainly is not the SunOS 4.x environment where the initial attempt failed. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL 0.9.5a beta1 released
On Tue, Mar 21, 2000 at 11:13:02AM -0500, Guillaume Filion wrote: Guillaume Filion [EMAIL PROTECTED]: I tried to compile Openssl 0.9.5a beta 1 on SunOS 4.1.4 1 and it didn't worked (note that I never tried to compile an earlier/stable version on SunOS...). bss_bio.c:217: `ssize_t' undeclared (first use this function) Try "./config -Dssize_t=int". It didn't worked either: [...] "/usr/include/sys/types.h", line 190: invalid type combination "/usr/include/sys/types.h", line 190: warning: useless declaration "/usr/include/sys/types.h", line 190: warning: typedef declares no type name Strange, so ssize_t apparently *is* declared in sys/types.h on that system ... but then the previous error (the problem in crypto/bio/bio_bss.c) should not have happended: bio_bss.c includes e_os.h, which includes sys/types.h. Can you make out any #if's or #ifdef's in /usr/include/sys/types.h that might have something to do with this? Does adding another #include sys/types.h at the beginning of crypto/bio/bio_bss.c change anything? (Run ./config again before testing, without options.) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Fw: Re: memory leaks in SSLeay_add_all_algorithms?
Richard Levitte - VMS Whacker [EMAIL PROTECTED]: Might be a good idea... From: "Richard Dykiel" [EMAIL PROTECTED] To: "Richard Levitte - VMS Whacker" [EMAIL PROTECTED] A suggestion however? Not a top priority, but it would be nice to clean up these leaks, [...] There are no known leaks. Run openssl s_client or anything in a debugging configuration with -DCRYPTO_MDEBUG_ALL and you'll see it yourself. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: installation error
Hong Zhang [EMAIL PROTECTED]: gcc -I. -I../include -DTHREADS -D_REENTRANT -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c cryptlib.c -o cryptlib.o In file included from /usr/include/errno.h:36, from ../include/openssl/err.h:82, from cryptlib.h:74, from cryptlib.c:61: /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory Can anybody tell me what's wrong? Thanks. Presumably you installed a different kernel version than the one that's the default for you distribution, but didn't properly install the header files contained in it. This has nothing to do with OpenSSL, you can just as file experiment with any other C program that uses errno.h. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Compiling Problems OpenSSL 0.9.5
I have problems compiling openSSL 0.9.5 on a Suse 6.2 Linux system. Try today's snapshot, URL: ftp://ftp.openssl.org/snaphost%2fopenssl-SNAP-2312.tar.gz (to appear in a couple of minutes). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: 'prng not seeded' error when changeing RSA private key password
[EMAIL PROTECTED]: Description: Execution of the 'openssl rsa -des3 -in test.pem -out test-1.pem' command caused the following error: 18026:error:24064064:random number generator:SSLEAY_RAND_BYTES:prng not seeded:md_rand.c:470: The current development version (URL:ftp://ftp.openssl.org/snapshot;type=d) avoids this problem. The random number is used only as an encryption IV, so strong seeding is not really necessary. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: install openssl under my directory??
Lingyun Wang [EMAIL PROTECTED]: How can I install openssl under my directory? Step 1: Read INSTALL. Step 2: Use the --openssldir option explained in INSTALL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: s_client
Richard Levitte - VMS Whacker [EMAIL PROTECTED]: [...] I would suggest the following instead: cat DG01.txt dg.txt netscape-4.71-linux | openssl s_client \ -connect 10.0.0.100:5150 -cert EntrustCert1.pem \ -key EntrustKey1.pem However, there's another problem as well. As soon as EOF is reached, s_client will shut down the connection and exit *without waiting for anything*. So, the transfer of your input gets through so quickly that the response won't get through before s_client shutdown the connection... Also of course instead of patching s_client the "-quiet" option should be used. One if its effects is to ignore EOF at stdin, so (cat ...)|openssl s_client should work with it. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Failure!
Ulf Möller [EMAIL PROTECTED]: [...] The compilation failed with cc -I.. -I../../include -O -Wall -c md_rand.c md_rand.c:303: undefined type, found `pid_t' On your Next system, is pid_t defined in some other header file? If it does not exist at all, then try changing pid_t to long. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Failure!
John Badanes [EMAIL PROTECTED]: OpenSSL version: 0.9.5 [...] Target (default): nextstep Target: nextstep Compiler: NeXT Software, Inc. version cc-744.13, gcc version 2.7.2.1 cc -o bntest -I../include -O -Wall bntest.o -L. -L.. -L../.. -L../../.. -L.. -lcrypto /bin/ld: Undefined symbols: _ERR_error_string _ERR_get_error _ERR_load_crypto_strings _ERR_print_errors_fp _RAND_seed _ERR_put_error _ERR_add_error_data _RAND_add _RAND_bytes _RAND_pseudo_bytes Strange. What does the output of 'nm libcrypto.a' look like? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem Compiling OpenSSL for RSA Support
David G. Hesprich [EMAIL PROTECTED]:
./config rsaref
make
make test
make install
it compiles, all tests appear to complete, and installs. However, OpenSSH
complains of the lack of RSA support in the libraries. [...]
I have contacted Damien Miller at the OpenSSH project, and he was kind
enough to send me some test code that he was working on to briefly test the
compiled libs for the necessary RSA functionality:
#include
#include
int main(void)
{
RSA *key;
key=RSA_generate_key(32,3,NULL,NULL);
if(key==NULL)
printf("NO RSA!\n");
else
printf("RSA OK!\n");
return(0);
}
[...] I have tried compliling without the "rsaref" parameter, with
the same results.
In that test program, insert "ERR_print_errors_fp(stdout);" before the
"return(0);" statement and recompile. Running the program then will
output the notorious "prng not seeded" error message, which is
discussed in the OpenSSL FAQ.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: prng no seeded
On Fri, Mar 03, 2000 at 10:00:39PM +0100, Lutz Jaenicke wrote: Maybe future versions of OpenSSL will also have the "-rand" option for s_server... 'openssl rand -rand file:egd-socket:whatever 0' can be used to initialize $RANDFILE or $HOME/.rnd (in future versions of OpenSSL). Or 'openssl rand -rand file:egd-socket:whatever -base64 6' if you need a new Unix password. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Make error
Joe O'Reilly [EMAIL PROTECTED]: a suse 6.2 linux system [...]. I get the same make error each time. (cd asm; /usr/bin/perl sha1-586.pl cpp sx86unix.cpp) gcc -E -DELF asm/sx86unix.cpp | as -o asm/sx86-elf.o gcc: asm/sx86unix.cpp: linker input file unused since linking not done What gcc version is that? gcc -E -DELF asm/sx86unix.cpp is expected to run that file through the pre-processor and output the result at stdout. Do you get any output other than that error when you run gcc -E -DELF asm/sx86unix.cpp manually (in the appropriate directory)? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: prng no seeded
Now I'm a little confuse about the context of RAND_* in FAQ #6. I installed both EGD as well as librand but I am still getting the random number generator has not been seeded error. Can someone explain more about how this actually works? I did the following after I have successfully compile openssl 0.9.5 % openssl s_client connect www.openssl.org:443 and I got the following error: unable to load 'random state' This means that the random number generator has not been seeded with much random data. Consider setting the RANDFILE environment variable to point at a file that 'random' data can be kept in (the file will be overwritten). See the last sentence of that message. If $RANDFILE is not set, file $HOME/.rnd will be used for seeding the PRNG. It will also be written back by those sub-programs of the openssl command that understand the -rand option -- e.g. run "openssl genrsa -rand your_egd_socket 1024" to create $HOME/.rnd, then re-try s_client. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL and non-blocking IO
Jeremy Bennett [EMAIL PROTECTED]: 1) I see that SSL_write and SSL_read can result in errors SSL_ERROR_WANT_READ/WRITE. Since this is the case, can I have simultaneous outstanding SSL_reads and SSL_writes? That is, if I call SSL_read and it results in SSL_ERROR_WANT_WRITE can I go ahead and call SSL_write or should I wait for SSL_read to return success? (and vice versa) Handling such situations is a little complicated, but it can be done. The difficulty is that after you've called SSL_read or SSL_write, the result code of the previous call to on of these functions may no longer be valid. So if the second function reports success, you should just retry the first one, because clearly something happened. If both functions result in an SSL_ERROR_WANT_READ/WRITE result code, then it's not obvious what should be done -- just retrying everything may lead to busy waiting, but if you want to call select() instead you don't know what you should really select() for. We have an event handler that will call a specific function when a socket is readable or writable. I was planning on registering the appropriate callback on these errors. What I needed to know was whether the underlying code could cope with this behavior. It sounds like it can. Question: if I call SSL_write, get WANT_READ, register a callback for the socket being readable, then call SSL_read, get WANT_READ, and register another callback, does it matter if I recall them in the opposite order? ie, when the socket is readable call SSL_read then SSL_write? The order does not matter. If a handshake is currently going on, either of these functions will continue the handshake before attempting to handle application data. Also it is not harmful to call SSL_read or SSL_write when you know the the SSL_ERROR_WANT_... condition is not yet satisfied -- you just have to make sure that you avoid busy waiting, and that the functions are finally called when their conditions are fulfilled. The event-based callback approach will work if no events are ever lost (i.e. if, whenever one of the socket condition becomes true, all waiting handlers for that condition are scheduled to be called). However, if conditions are only tested while none of the handlers is running, it will not work -- then you have the problem described above that the first function's SSL_ERROR code may no longer be true after the call to the second function. The solution is to look at the underlying BIO layer. Before trying SSL_read and SSL_write, record BIO_numer_read(rbio) and BIO_number_written(wbio), where rbio and wbio are initialized as SSL_get_rbio(ssl) and SSL_get_wbio(ssl), respectively. Then call SSL_read and SSL_write. If it is not obvious whether there was any protocol progress (i.e. if you get SSL_ERROR_WANT_READ/WRITE for both calls), then by calling BIO_number_read(rbio) and BIO_number_written(wbio) and comparing these figures with the previous values you can find out whether anything has happened. If one of the values has changed, you can just enter another iteration of the loop without risking busy waiting. If, on the other hand, both values are the same as before SSL_read and SSL_write, then you can be sure that the SSL_ERROR_WANT_READ/WRITE from the first of these SSL_... operations is still valid; so you can select() for the combination of the two SSL_ERROR_WANT_... codes. Looking at the source code of other existing TLS proxies and finding out how they can fail is left as an exercise. If they don't evaluate BIO_number_read() and BIO_number_written(), then probably they're buggy (or their use is restricted to protocols where concurrent I/O in both directions is not possible). Could you point me at one of these opensource proxies? See pointers at URL: http://www.openssl.org/related/apps.html. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Error: SSLEAY_RAND_BYTES:prng not seeded
Michael E Buckley [EMAIL PROTECTED]:
I am getting the "prgn not seeded" message on a Solaris 7 Ultra 10
when I create non-dummy certificates. [...]
STEP 4: Enrypting RSA private key with a pass phrase [...]
Encrypt the private key now? [Y/n]:
read RSA key
writing RSA key
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
unable to write key
13617:error:24064064:random number generator:SSLEAY_RAND_BYTES:prng not seeded:m
d_rand.c:483:
mkcert.sh:Error: Failed to encrypt RSA private key
A couple of times RAND_bytes() is used when RAND_pseudo_bytes(), which
works without strong seeding, should be used. Change pem_lib.c
according to the following patch, then the script should work.
Index: crypto/asn1/p5_pbe.c
===
RCS file: /usr/local/openssl/cvs/openssl/crypto/asn1/p5_pbe.c,v
retrieving revision 1.12
diff -u -r1.12 p5_pbe.c
--- p5_pbe.c2000/01/30 23:32:23 1.12
+++ p5_pbe.c2000/03/02 21:51:05
@@ -129,7 +129,7 @@
}
pbe-salt-length = saltlen;
if (salt) memcpy (pbe-salt-data, salt, saltlen);
- else if (RAND_bytes (pbe-salt-data, saltlen) = 0)
+ else if (RAND_pseudo_bytes (pbe-salt-data, saltlen) = 0)
return NULL;
if (!(astype = ASN1_TYPE_new())) {
Index: crypto/asn1/p5_pbev2.c
===
RCS file: /usr/local/openssl/cvs/openssl/crypto/asn1/p5_pbev2.c,v
retrieving revision 1.14
diff -u -r1.14 p5_pbev2.c
--- p5_pbev2.c 2000/02/22 18:45:09 1.14
+++ p5_pbev2.c 2000/03/02 21:51:17
@@ -212,7 +212,7 @@
if (!(osalt-data = Malloc (saltlen))) goto merr;
osalt-length = saltlen;
if (salt) memcpy (osalt-data, salt, saltlen);
- else if (RAND_bytes (osalt-data, saltlen) = 0) goto merr;
+ else if (RAND_pseudo_bytes (osalt-data, saltlen) = 0) goto merr;
if(iter = 0) iter = PKCS5_DEFAULT_ITER;
if(!ASN1_INTEGER_set(kdf-iter, iter)) goto merr;
Index: crypto/pem/pem_lib.c
===
RCS file: /usr/local/openssl/cvs/openssl/crypto/pem/pem_lib.c,v
retrieving revision 1.27
diff -u -r1.27 pem_lib.c
--- pem_lib.c 2000/02/23 01:10:57 1.27
+++ pem_lib.c 2000/03/02 21:50:31
@@ -373,7 +373,7 @@
kstr=(unsigned char *)buf;
}
RAND_add(data,i,0);/* put in the RSA key. */
- if (RAND_bytes(iv,8) = 0) /* Generate a salt */
+ if (RAND_pseudo_bytes(iv,8) = 0) /* Generate a salt */
goto err;
/* The 'iv' is used as the iv and as a salt. It is
* NOT taken from the BytesToKey function */
Index: crypto/pkcs12/p12_mutl.c
===
RCS file: /usr/local/openssl/cvs/openssl/crypto/pkcs12/p12_mutl.c,v
retrieving revision 1.11
diff -u -r1.11 p12_mutl.c
--- p12_mutl.c 2000/01/21 01:15:53 1.11
+++ p12_mutl.c 2000/03/02 21:51:43
@@ -157,7 +157,7 @@
return 0;
}
if (!salt) {
- if (RAND_bytes (p12-mac-salt-data, saltlen) = 0)
+ if (RAND_pseudo_bytes (p12-mac-salt-data, saltlen) = 0)
return 0;
}
else memcpy (p12-mac-salt-data, salt, saltlen);
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: SSL and non-blocking IO
On Mon, Feb 28, 2000 at 03:54:39PM -0800, Jeremy Bennett wrote:
1) I see that SSL_write and SSL_read can result in errors
SSL_ERROR_WANT_READ/WRITE. Since this is the case, can I have
simultaneous outstanding SSL_reads and SSL_writes? That is, if I call
SSL_read and it results in SSL_ERROR_WANT_WRITE can I go ahead and call
SSL_write or should I wait for SSL_read to return success? (and vice
versa)
Handling such situations is a little complicated, but it can be done.
The difficulty is that after you've called SSL_read or SSL_write, the
result code of the previous call to on of these functions may no
longer be valid. So if the second function reports success, you
should just retry the first one, because clearly something happened.
If both functions result in an SSL_ERROR_WANT_READ/WRITE result code,
then it's not obvious what should be done -- just retrying everything
may lead to busy waiting, but if you want to call select() instead you
don't know what you should really select() for.
The solution is to look at the underlying BIO layer. Before trying
SSL_read and SSL_write, record BIO_numer_read(rbio) and
BIO_number_written(wbio), where rbio and wbio are initialized
as SSL_get_rbio(ssl) and SSL_get_wbio(ssl), respectively.
Then call SSL_read and SSL_write. If it is not obvious whether
there was any protocol progress (i.e. if you get
SSL_ERROR_WANT_READ/WRITE for both calls), then by calling
BIO_number_read(rbio) and BIO_number_written(wbio) and comparing
these figures with the previous values you can find out whether
anything has happened. If one of the values has changed,
you can just enter another iteration of the loop without
risking busy waiting. If, on the other hand, both values
are the same as before SSL_read and SSL_write, then you can
be sure that the SSL_ERROR_WANT_READ/WRITE from the first of
these SSL_... operations is still valid; so you can select()
for the combination of the two SSL_ERROR_WANT_... codes.
Looking at the source code of other existing TLS proxies and
finding out how they can fail is left as an exercise.
If they don't evaluate BIO_number_read() and BIO_number_written(),
then probably they're buggy (or their use is restricted to
protocols where concurrent I/O in both directions is not
possible).
2) Can SSL_shutdown result in WANT_READ/WRITE?
SSL_shutdown still has a weird interface, it will never return -1, and
when it returns 0 this does not indicate an EOF at the network, it
only means that the shutdown has not yet completed. So its return
values are not even suitable for SSL_get_error, i.e. those
SSL_ERROR_WANT_... codes are meaningless in this context.
The strange interface plus bugs in various browsers make this
rather difficult to handle ... Here's what I use in one program
for the case where the closure is initiated by that program
(if the peer initiates the closure, i.e. if SSL_get_error returns
SSL_ERROR_ZERO_RETURN, then calling SSL_shutdown once should suffice):
/* ... */
some_function()
{
/* ... */
{
/* The TLS case.
* Send close_notify to "out", and try to obtain the peer's
* close_notify. */
assert(out != NULL);
#ifdef DEBUG_CLOSE
fprintf(stdout, "%s%s: Trying SSL_shutdown at %s.\n",
Myname, childid, tdef-forward_to_tcp_port.printable_name);
#endif
r = do_tls_shutdown(out, outfd, childid);
if (r == 0) {
/* Clean shutdown */
kill_outfd = 0;
clean_closure = 1;
} else {
tls_output_OpenSSL_errors(" while shutting down connection to ",
tdef-forward_to_tcp_port.printable_name,
childid, "unclean closure");
}
}
/* ... */
/* If kill_outfd has not been set to 0, send TCP RST,
* otherwise just close */
}
/* Returns 0 if the shutdown succeeded, 1 in case of failure.
* Does not close the socket; does not report TLS level failure to stderr
* (but may report lower level problems, i.e. with sockets). */
static int
do_tls_shutdown(SSL *ssl, int sslfd, const char *childid)
{
int r;
int shut;
assert(ssl != NULL);
#if 0 /* In theory, things would work this way. But Netscape (Navigator 4.5)
* does not handle connection closure correctly: When the server has sent
* closure alerts, it does not answer with closure alerts and close
* the connection -- instead, it keeps the connections and tries
* do use them for further requests, even though the server has sent
* closure alerts. Then it just hangs, ignoring the server's alerts,
* and waiting for something to read. */
r = sockets_set_blocking(sslfd, "");
if (r != 0)
return 1; /* didn't work */
shut = SSL_shutdown(ssl) || SSL_shutdown(ssl);
/* SSL_shutdown is repeated because of the silly state machine
* in ssl3_shutdown -- calling it once is never enough even
* with blocking sockets (I think with non-blocking sockets it
*
Re: random number generator:SSLEAY_RAND_BYTES:prng not seeded:md_rand.c:476
On Tue, Feb 29, 2000 at 03:42:09PM +0100, Juergen Moellenhoff wrote: I use the OpenSSL-Lib since version 0.5.1b (SSLeay) for my HTTPS-PlugIn for the OmniWeb-Browser (MacOS X/OPENSTEP) and had no problems to use and compile the OpenSSL-Lib as Framework (shared lib) for MacOS X and OPENSTEP 4.2/NEXTSTEP 3.3, today I tried to use the OpenSSL version 0.9.5 and now I get this error when I try to connect to an SSL-Server: SSL_connect() failed: [8827:error:24064064:random number generator:SSLEAY_RAND_BYTES:prng not seeded:md_rand.c:476: 8827:error:05067003:Diffie-Hellman routines:DH_generate_key:BN lib:dh_key.c:148: 8827:error:14098005:SSL routines:SSL3_SEND_CLIENT_KEY_EXCHANGE:bad asn1 object header:s3_clnt.c:1403] I changed nothing in the source code of the HTTPS-PlugIn and I compiled and created the framework of the OpenSSL-Lib for MacOS X and OPENSTEP 4.2/Mach the same way I did it for the 0.9.4 version. I don't know why SSL_connect() fails inside the md_rand file, I assume that the random number generator can't generate enough random bytes, but what is the difference between 0.9.4 and 0.9.5? [...] See file FAQ. The problem is that your random numbers are as predictable as your question :-) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: session key reuse - server side problems
Raghuram Belur [EMAIL PROTECTED] in ulf.openssl.dev: We have an application for which we are using SSL enabled clients and servers(our own server not a web server). I have been trying to get the session key reuse going for the past several days. [...] Use SSL_CTX_set_session_id_context(). To avoid potential security holes in applications that use a single external session cache in SSL_CTX's with different authentication requirements, the SSL server implementation refuses to reuse sessions unless they were created in a matching context (see occurrences of sid_ctx in ssl/ssl_sess.c). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Adding new cipher suites to TLS with 256+ bit session keys.
Gregory Stark [EMAIL PROTECTED]: You might want to go to http://www.cryptosavvy.com/suggestions.htm and show your boss that 4096 bit RSA is approximately equivalent in strength to 150-160 bit keysize symmetric ciphers. [...] Their estimate is not that 4096 bit RSA is as strong as 150-160 bit symmetric ciphers, it's that it will be as strong. If you cannot tell the difference, you haven't read their paper. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: How to build exportable OpenSSL?
Rich Salz [EMAIL PROTECTED]: I've looked through the documentation, but I can't seem to find how to build an exportable (40 bit) version of OpenSSL? You can't, but the new regulations don't have that limit anyway. sure you can -- set the cipherspec. You cannot build a 40-bit version of OpenSSL. What you are saying ist that OpenSSL is able to interoperate with 40-bit SSL clients and servers. That's true, but it is not what the question was about. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSLv3 handshake problem is a build problem
On Wed, Feb 23, 2000 at 03:19:27PM -0500, Rick W. Porter wrote: 6. from crypto, I did a "make all" [...] 7. from apps, I did a "make all" [...] When you are in a sub-directory and don't want to run make from the top directory, you are supposed to just run "make" (which is equivalent to "make top"), not "make all". "make top" will pick up various definitions from the top level Makefile and finally run "make all" with the required parameters, whereas directly running "make all" will use defaults that are usually wrong. (We could change the sub-Makefiles so that they refuse to do any work if called directly with "make all" ...) Please run "make clean" and "make" from the top level directory to get consistent object files. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [BUG] Snapshot 20000224 EGD problems
On Fri, Feb 25, 2000 at 01:20:36PM +0100, Lutz Jaenicke wrote: if (read(fd, buf, 1) != 1) goto err; + if (buf[0] == 0) goto err; num = read(fd, buf, 255); Of course, the returned buf[0] value must match the later returned "num" value, but what should we do if it does not match instead of using "num" anyway? :-) Presumably reading should happen in O_NONBLOCK mode to make sure that bugs such as an incompatible daemon at the Unix socket don't cause problems? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug !!!!!
On Fri, Feb 25, 2000 at 03:04:14PM +0100, Emanuele La Cognata wrote: Hello, I compiled the OpenSSL library under Windows NT with : -DNO_IDEA -DNO_RC2 -DNO_RC4 -DNO_RC5 -DNO_RSA -DCIPHER_DEBUG When I run the server and client demos on my PC (localhost) I have this error: ERROR in SERVER 265:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:.\ssl\s3_srvr.c:771: Which demos? Presumably no temporary DH parameters are set up by the server; unless RSA is available, DH parameters are required for the handshake. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problems in recent snapshot
On Wed, Feb 23, 2000 at 01:00:27PM -0800, Yoram Meroz wrote:
So what's the matter with www.apache-ssl.org
("openssl s_client -debug -state -connect www.apache-ssl.org:443")?
The error is returned by ssl3_read_bytes (s3_pkt.c, line 912). The comment
says, "In the case where we try to read application data the first time, but
we trigger an SSL handshake, we return -1 with the retry option set." Should
I just be handling this differently than I am?
Apparently your program aborts the connection when SSL_read returns -1;
what it should do is query SSL_get_error with the return value of
SSL_read to see what is going on. See the SSL_get_error man page.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Problems in recent snapshot
On Tue, Feb 22, 2000 at 08:37:12PM +, Ben Laurie wrote: Yoram Meroz wrote: Since moving from the 02-20 to the 02-21 snapshots, I've been consistently unable to connect to www.apache-ssl.org or www.rsasecurity.com . www.verisign.com and www.buy.com work fine. Since I am one of very few working with the mac build, I'd like some confirmation as to whether anyone is having similar problems in the UNIX or Win32 builds, or whether this is unique to the mac build. I imagine this'll be Bodo's frag fixes failing. Can anyone reproduce the errors? www.apache-ssl.org works fine for me; at first I thought I had found a problem at www.rsarecurity.com, but that's just the server closing the connection without having sent a single byte in return to the Client Hello (same problem with OpenSSL 0.9.4, and with Netscape). If there are connection problems, of what kind are they? What happens according to 's_client -debug -state'? You didn't even reveal the error message ... __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Sun compiler problem?
On Wed, Feb 23, 2000 at 12:17:43AM +0100, Ulf Möller wrote: I was trying to compile the current 0.9.5-dev on a Solaris machine. The linker complained about many missing symbols. nm reports libcrypto.a[cryptlib.o]: nm: cryptlib.o: invalid file type and so on for a large part of the archive. Mixture between sparcv8 and sparcv9 configuration? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problems in recent snapshot
On Wed, Feb 23, 2000 at 02:32:32PM +0100, Lutz Jaenicke wrote:
Can anyone reproduce the errors? www.apache-ssl.org works fine for
me; at first I thought I had found a problem at www.rsarecurity.com,
but that's just the server closing the connection without having sent
a single byte in return to the Client Hello (same problem with OpenSSL
0.9.4, and with Netscape).
I have just tried it with latest SNAPSHOT on HP-UX 10.20.
Could reproduce the problems.
www.rsasecurity.com does not count because that site does not even work
with Netscape at the moment. So what's the matter with www.apache-ssl.org
("openssl s_client -debug -state -connect www.apache-ssl.org:443")?
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Problems in recent snapshot
On Wed, Feb 23, 2000 at 06:47:53PM +0100, Lutz Jaenicke wrote:
On Wed, Feb 23, 2000 at 06:45:46PM +0100, Bodo Moeller wrote:
On Wed, Feb 23, 2000 at 02:32:32PM +0100, Lutz Jaenicke wrote:
I have just tried it with latest SNAPSHOT on HP-UX 10.20.
Could reproduce the problems.
www.rsasecurity.com does not count because that site does not even work
with Netscape at the moment. So what's the matter with www.apache-ssl.org
("openssl s_client -debug -state -connect www.apache-ssl.org:443")?
ARRRGGGH!
This should have been "Could NOT reproduce the problem".
Seems the NOT key is defective
I didn't really believe you anyway :-)
SCNR.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: SSLeay-0.6.4 is not thread safe?
Richard Levitte - VMS Whacker [EMAIL PROTECTED]: SSLeay_add_ssl_algorithms ();---*(1) SSL_load_error_strings ();---*(1) (1) These are really only mean to be used ONCE for the whole application. The ssl algorithm table and the error message table is global. [...] Yup. // Cleanup and exit. if (pSsl) SSL_shutdown (pSsl); iRetCode = shutdown (sSocket, SD_BOTH); closesocket (sSocket); if (pSsl) SSL_free (pSsl); THAT sequence gives me the creaps (sp?). You see, the fd's you declared earlier with SSL_set_fd() got "registered" in the SSL structure through a couple of BIOs. SSL_free() will fo a BIO_free_all() on those, and BIO_free_all() will most definitely try to close the socket... Actually not, because SSL_set_fd uses BIO_set_fd(bio,fd,BIO_NOCLOSE). You have to close the sockets yourself when using SSL_set_fd. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_CTX
Chris Bamford [EMAIL PROTECTED]: Do you provide mutexes to the library? For multi-threaded applications, the following calls are required in initialization: CRYPTO_set_id_callback(id_callback); CRYPTO_set_locking_callback(locking_callback); Hmmm. Please bear with me. I have tried to code around the need for serialisation of any kind because I'm trying to recreate a large number of simultaneous hits on this web server. I create one global SSL_CTX structure as a shared resource. I then launch the threads which all create their own SSL structures based on the global SSL_CTX structure. As this is a "read- only" access of the SSL_CTX structure, do I really need mutexes? Yes. The various threads write to several shared data objects, such as variables in the pseudo random number generator, reference counts in various data structures (including that SSL_CTX), etc. If there are no mutexes to synchronize access to all these shared data structures, then things cannot be expected to work smoothly; we cannot promise that the program will quickly crash, either, but you should be surprised if it does. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Latest SNAPSHOT, 2 questions
Lutz Jaenicke [EMAIL PROTECTED]: 1. When loading CAfile data, SSL_CTX_load_verify_locations() returns 0, even if certificates are available (and did work with 0.9.4). There are no errors on the error stack to be printed, so I would have to trace through the code to find the reason. As of know, my software will understand the return value 0 as error indicator and will abort; in s_server.c etc, the return value is only used for possible printout of errors and otherwise silently ignored. Where does this return value 0 come from -- i.e., what happens in X509_STORE_load_locations (in crypto/x509/x509_d2.c)? Does X509_load_cert_crl_file (in crypto/x509/by_file.c; this is what X509_LOOKUP_load_file is based on) return 0? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PERL Module Problem...
Richard Levitte - VMS Whacker [EMAIL PROTECTED]: [...] I would trust passwords passed over stdin before anything passed in the command line or environment, any time. Not that stdin is perfect either, mind you, but still... Environment variables must usually be considered public. PGP evaluates a PGPPASSFD environment variable and reads from the named file descriptor; with this approach, you don't have to send passwords and actual data through the same pipe. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: quick question..
Erik Aronesty [EMAIL PROTECTED]: I have an app working very well... *except* i now want (need?) to accurately determine if it's "ok to write" (will not block) or "ok to read". Without SSL, I could do this with a select().. however a select() is clearly not correct when using SSL. Set the sockets to non-blocking mode. Then you can just attempt the I/O operation you want to perform; if it does not complete, you can use SSL_get_error() to find what you should select() for before trying again. See the SSL_get_error() man page at www.openssl.org/docs. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Buffer overflows in OpenSSL 0.9.4 on Windows
Remo Inverardi [EMAIL PROTECTED]: I'm using OpenSSL 0.9.4, compiled with Visual C++ 6.0 on a Windows [...] I've got the buffer overflows and some leeks. I have found some memory leaks since, but what I thought were buffer overflows turned out to be harmless because the dangerously-looking function was never called with unsafe parameters. Can you locate the apparent buffer overflows? Which data structures, which functions are involved? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Sadistic C compiler...
On Thu, Jan 20, 2000, Richard Levitte - VMS Whacker wrote: babinebell I think we should seperate the functions handling values babinebell and the functions handling callbacks: babinebell babinebell int BIO_ctrl_callback(BIO *bp,int cmd,long larg,int (*cb)()); Hmm, actually, I like that alternative. That allows us to go around the whole union/pass-by-value/and-so-on brouhaha... :-) Looks ok. Will you implement it? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Sadistic C compiler...
On Wed, Jan 26, 2000, Bodo Moeller wrote: On Thu, Jan 20, 2000, Richard Levitte - VMS Whacker wrote: Hmm, actually, I like that alternative. That allows us to go around the whole union/pass-by-value/and-so-on brouhaha... :-) Looks ok. Will you implement it? Here "you" == Richard, in case it wasn't clear. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect() fails on non-blocking sockets.
Matti Aarnio [EMAIL PROTECTED]: It turned out that while the socket the SMTP client code creates is running in non-blocking mode, I must temporarily turn the blocking mode on while the SSL setup negotiations are under way. I don't know if creating some wrapper to retry calls to SSL_connect() would have helped, but such would have been rather massively kludgy thing.. SSL_connect needs multiple I/O operations in both directions, so you cannot expect it to finish at once for non-blocking I/O. SSL_connect returning -1 does not always indicate an error. Use SSL_get_error to find out if the application should select() for readable bytes or for a possibility to write more data. NAME SSL_get_error - obtain result code for SSL I/O operation SYNOPSIS #include openssl/ssl.h int SSL_get_error(SSL *ssl, int ret); DESCRIPTION SSL_get_error() returns a result code (suitable for the C "switch" statement) for a preceding call to SSL_connect(), SSL_accept(), SSL_read(), or SSL_write() on ssl. The value returned by that SSL I/O function must be passed to SSL_get_error() in parameter ret. In addition to ssl and ret, SSL_get_error() inspects the current thread's OpenSSL error queue. Thus, SSL_get_error() must be used in the same thread that performed the SSL I/O operation, and no other OpenSSL function calls should appear inbetween. The current thread's error queue must be empty before the SSL I/O operation is attempted, or SSL_get_error() will not work reliably. RETURN VALUES The following return values can currently occur: SSL_ERROR_NONE The SSL I/O operation completed. This result code is returned if and only if ret 0. SSL_ERROR_ZERO_RETURN The SSL connection has been closed. If the protocol version is SSL 3.0 or TLS 1.0, this result code is returned only if a closure alerts has occured in the protocol, i.e. if the connection has been closed cleanly. SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE The operation did not complete; the same SSL I/O function should be called again later. There will be protocol progress if, by then, the underlying BIO has data available for reading (if the result code is SSL_ERROR_WANT_READ) or allows writing data (SSL_ERROR_WANT_WRITE). For socket BIOs (e.g. when SSL_set_fd() was used) this means that select() or poll() on the underlying socket can be used to find out when the SSL I/O function should be retried. Caveat: Any SSL I/O function can lead to either of SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE, i.e. SSL_read() may want to write data and SSL_write() may want to read data. SSL_ERROR_WANT_X509_LOOKUP The operation did not complete because an application callback set by SSL_CTX_set_client_cert_cb() has asked to be called again. The SSL I/O function should be called again later. Details depend on the application. SSL_ERROR_SYSCALL Some I/O error occurred. The OpenSSL error queue may contain more information on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error: If ret == 0, an EOF was observed that violates the protocol. If ret == -1, the underlying BIO reported an I/O error. (For socket I/O on Unix systems, consult errno.) SSL_ERROR_SSL A failure in the SSL library occured, usually a protocol error. The OpenSSL error queue contains more information on the error. SEE ALSO ssl(3), err(3) HISTORY SSL_get_error() was added in SSLeay 0.8. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Might we have a potential MT-safety problem?
On Mon, Jan 24, 2000 at 12:38:17PM +0100, Richard Levitte - VMS Whacker wrote: [ssl/s2_clnt.c, get_server_hello] if (s-session-peer != NULL) X509_free(s-session-peer); #if 0 /* What is all this meant to accomplish?? */ /* hmmm, can we have the problem of the other session with this * cert, Free's it before we increment the reference count. */ CRYPTO_w_lock(CRYPTO_LOCK_X509); s-session-peer=s-session-sess_cert-key-x509; /* Shouldn't do this: already locked */ /*CRYPTO_add(s-session-peer-references,1,CRYPTO_LOCK_X509);*/ s-session-peer-references++; CRYPTO_w_unlock(CRYPTO_LOCK_X509); #else s-session-peer = s-session-sess_cert-peer_key-x509; /* peer_key-x509 has been set by ssl2_set_certificate. */ CRYPTO_add(s-session-peer-references, 1, CRYPTO_LOCK_X509); #endif Personally, I'd like to do the then clause rather than the else clause, for MT safety's sake. If a second thread exists that uses the same X509 structure, then it owns a second reference count anyway, and CRYPTO_add(s-session-peer-references, 1, CRYPTO_LOCK_X509) leaves the reference count at 3 or more, so there's no problem in this case. A problem exists if you think it should be possible to have two clients trying to reuse the same session using identical s-session pointers. If so, the "then" branch is just a more complicated way to implement essentially the same bug: If s-hit is set and s-session is shared by two processes, X509_free(s-session-peer) is badly wrong; we must not modify anything in s-session. (Thus if s-hit != 0, there's no need for any locking in the first place.) Probably all of the above code should be moved into the "s-hit == 0" branch; I hope it is not needed if s-hit != 0 (when reusing a session, "s-session-peer == s-session-sess_cert-key" should hold anyway, or we have real problems). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Sadistic C compiler...
Richard Levitte - VMS Whacker [EMAIL PROTECTED]:
Let me see if I got it all. So far, I've seen the following
alternatives:
1. ignore the problem (obviously not the right thing to do :-)).
2. take the parameter in question as we do today, but use a union so
the compiler will shut up (which is a fancy way of ignoring the
problem).
3. whenever the passed parameter is a function pointer, use double
indirection and assume the caller has really passed a reference
to a function pointer.
4. Have the caller tuck the parameter in a union that will represent
function pointers as well as other pointers, and pass that union
by value.
5. Have the caller tuck the parameter in a union that will represent
function pointers as well as other pointers, and pass that union
by reference.
Actually, 4 and 5 are basically the same.
No, 5 is to 4 what (for function pointers) 3 is to 1.
Choices 1 and 2 are really just as bad, they're designed to ignore the
problem instead of dealing with it.
Choice 3 assumes that the parameter ni question will be prototyped
and used like this:
int foo (..., void *parg, ...)
{
/* ... */
int (*fptr)() = *(int (**)())parg;
/* ... */
}
It's a good way to deal with the problem in what could be perceived as
a safe way, but for a detail: there's no way to see from the API that
function pointers need to be handled differently than other pointers
when passed down to the functino using them ("doall" and "ctrl"
functions...), and the compiler will not give a hint.
It will give a hint! Just don't use casts, and the compiler will
complain when you try to pass a function pointer directly. Simarly,
the function using the function pointer can be written without casts
if it is using the pointer correctly; if it's incorrect, you need
casts to make the warning go away.
And yes, there will be the problem of binary compatibility in all
choices but 1 and 2...
Choice 4 should be binary compatible as well, because on platforms
where choice 1 and 2 work in practice both types of pointers
have the same length, so probably the union won't be any different.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Sadistic C compiler...
Andy Polyakov [EMAIL PROTECTED]:
5. Have the caller tuck the parameter in a union that will represent
function pointers as well as other pointers, and pass that union
by reference.
Choices 4 and 5 assumes that the parameter in question will be
prototyped and used like this:
int foo(..., union fn_n_data parg, ...)
{
/* ... */
int (*fptr)() = (int (*)())(parg.fn);
/* ... */
}
Why assign? parg.fn() (#4) and parg-fn() (#5) suffice and are perfectly
readable/debuggable, aren't they?
In the above example, yes; but not when it's really
int (*fptr)(int, char) = (int (*)())(parg.fn);
or even
long (*fptr)(int, char) = (int (*)())(parg.fn);
My vote is #5 for crypto/mem_dbg.c, crypto/bio/bss_conn.c, ssl/s3_lib.c
with new calls and separate ctl codes for binary compatibility [...]
I don't think it's worth to blow up the code that much to get binary
compatibility (but by adding a couple of lines of these "switch"
statements we can generate error messages that tell everyone to change
their programs -- then, a version or two later, we can get rid of this
extra code). It's easy to provide source code compatibility except
when SSL_ctrl and the other similar functions are called directly --
to catch these cases we should slightly rename the SSL_ctrl command
codes to cause compiler errors for programs that call it anyway.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Sadistic C compiler...
On Tue, Jan 18, 2000 at 10:59:53AM +0100, Richard Levitte - VMS Whacker wrote: bit data pointers). To force C to convert values between these types, you'd have to cast to some integer type inbetween: (void (*)()) (long) cb This may very well be a problem on architectures where a pointer is 64 bits while a long is 32 bits. Exactly, which is why compilers should complain when someone attempts to do such things (with just one cast, as in OpenSSL -- two casts as above tell the compiler that the user pretends to know what he is doing). But of course this is so complicated because it should never be done and is not guaranteed to do anything useful. cb, on the other hand, is the pointer to some data object; the function that gets this pointer as an argument has to retrieve the actual function pointer from inside this data object, i.e. use *((void (**)()) arg) where arg is the void * argument passed to it. I was pondering such a solution, but I foresaw a problem with it: strcmp is the same as strcmp, and that might be a difficult bug to find... I see, this could become a problem (when using over-tolerant compilers that don't print warnings for such conversions). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Sadistic C compiler...
Richard Levitte - VMS Whacker [EMAIL PROTECTED]:
[...]
The easiest way to avoid the conversions noted above is to have a
union like this:
union foo {
void *simple;
int (*fn)();
};
and use it internally. You put whatever char * you want to convert to
a functino pointer into simple and pull out the function pointer from
fn, and vice versa.
You cannot convert things this way, that would be just as broken as
using casts. What you can do, of course, is put pointers into the
appropriate union member ('simple' for data pointers, 'fn' for
function pointers), pass the union to some function, and, in this
function, take the same union member from the union passed as an
argument. I thought you had done exactly that, but a second look in
the commitlog shows that you have not (and it would make SSL_[CTX_]ctrl
much more complicated, we'd have to change the prototype).
The clean way (and not just another "clever hack") would be
void SSL_CTX_set_tmp_rsa_callback(SSL_CTX *ctx,RSA *(*cb)(SSL *ssl,
int is_export,
int keylength))
{
RSA *(**cb_ptr)(SSL *, int, int) = cb; /* cb_ptr is a data pointer,
* not a function pointer */
SSL_CTX_ctrl(ctx,SSL_CTRL_SET_TMP_RSA_CB,0,cb_ptr); /* no cast necessary as
* SSL_CTX_ctrl should
* have "void *" in the
* final argument */
}
and in ssl3_ctrl (which is what SSL_CTX_ctrl ends up calling):
long ssl3_ctrl(SSL *s, int cmd, long larg, void *parg)
{
[...]
switch (cmd)
{
[...]
case SSL_CTRL_SET_TMP_RSA_CB:
{
RSA *(**cb_ptr)(SSL *, int, int) = parg;
s-cert-rsa_tmp_cb = *cb_ptr;
}
break;
[...]
}
[...]
}
Instead of directly passing function pointers in disguise, a pass
pointers to data objects containing the actual function pointers.
Note that I'm using temporary variables instead of single-line
commands involving casts because this way it can be hoped more
compilers will print warnings or error messages in case of a typo --
the explicit cast from a function pointer value to void * was enough
to bring gcc to silence, but without casts the compiler can see that
you don't really intend to do such evil things.
(SSL_CTX_ctrl, ssl3_ctrl et al. still have a char * argument where
they should have a void * -- it's certainly trivial to change that.)
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Sadistic C compiler...
On Mon, Jan 17, 2000 at 01:06:27AM +0100, Richard Levitte - VMS Whacker wrote: DEC C for VMS is getting really mean. Version 6.2 (latest, as far as I know) spews out a message when a (char *) cast is done to a function pointer and vice versa. Every compiler should print such warnings, such casts are by no means guaranteed to work. It's especially visible in all the places where lh_doall_arg() gets a casted function pointer as last argument (for example, see CRYPTO_mem_leaks_cb() in crypto/mem_dbg.c)... I can imagine using silly things like a struct around the function pointer to get rid of that warning. The function pointer *must* be inside a data object to make such constructs legal, so this is not silly at all. An alternative would be to use unions of a function pointer and a data pointer (casts between different function pointer types are legal, you just have to make sure that you call the function as the same type as it was originally defined -- OpenSSL even fails at this) instead of just a void *, but that's probably more complicated than depositing the function pointer in a struct. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Sadistic C compiler...
Andy Polyakov [EMAIL PROTECTED]:
The function pointer *must* be inside a data object to make such constructs
legal,
But that's what Richard (subconsciously?) attempted to do in first
place:
static void (*mem_cb)()=NULL;
void CRYPTO_mem_leaks_cb(void (*cb)())
{
...
mem_cb=cb;
lh_doall_arg(mh,(void (*)())cb_leak,(char *)mem_cb);
mem_cb=NULL;
...
}
That's weird, I did not notice this and don't know why he did it this way
(and probably he doesn't either :-).
This is however not what I meant, this is just like calling
lh_doall_arg(mh,(void (*)())cb_leak,(char *)cb);
without using the extra static variable. We're still passing
a function pointer value. What would work, however, is
void CRYPTO_mem_leaks_cb(void (*cb)())
{
...
void *cb_ptr=cb;
lh_doall_arg(mh,(void (*)())cb_leak,cb);
...
}
(there's no reason to introduce a struct unless one wants to do things
over-complicated, I don't know why I mentioned structs before).
The point is that C doesn't like mixing function pointers and data
object pointers; they don't necessarily have identical
representations (you could have 32 bit function pointers, but 64
bit data pointers). To force C to convert values between these types,
you'd have to cast to some integer type inbetween:
(void (*)()) (long) cb
But of course this is so complicated because it should never be done
and is not guaranteed to do anything useful. cb, on the other hand,
is the pointer to some data object; the function that gets this
pointer as an argument has to retrieve the actual function pointer
from inside this data object, i.e. use *((void (**)()) arg)
where arg is the void * argument passed to it.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Windows Sockets
Remo Inverardi [EMAIL PROTECTED]: [...] windows sockets [...] blocking or non-blocking? The SSL library can work with both blocking and non-blocking socket I/O; this should be basically the same on NT as on Unix. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Checking for memory leaks
Remo Inverardi [EMAIL PROTECTED]: With OpenSSL 0.9.4, Visual C++ reports memory leaks even if I only use these two lines of OpenSSL code: SSL_CTX *ctx = SSL_CTX_new(SSLv2_server_method()); SSL_CTX_free(ctx); Question is: do I have to free anything else manually or is the leak caused by a OpenSSL "bug". At the end of a program, always delete OpenSSL's per-thread error queue by calling ERR_remove_state(0) (0 means the current thread). Under Windows, if you use multiple threads, each thread that exits will automatically have its error queue deleted, but presumably your memory-leak checking takes place before the main thread has exited. The reason that you get an error message from SSL_CTX_new (and ctx == NULL) in your example is that you did not load the algorithms by calling SSLeay_add_ssl_algorithms(). (You probably also want to load the error strings so that you won't have to decipher numerical OpenSSL error codes manually: call ERR_load_crypto_strings() and SSL_load_error_strings()). Before the program exits, call EVP_cleanup() and ERR_free_strings() to free the memory allocated in these steps. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Doubt about OPENSSL config file
Richard Levitte - VMS Whacker [EMAIL PROTECTED]: raulg What is the meanig of field raulg raulg RANDFILE = $ENV::HOME/.rnd raulg oid_file = $ENV::HOME/.oid raulg raulg in the openssl config file? raulg raulg If i have the OpenSSL on a MS NT 4 PC, what value can i assign to it? If you make sure that each user has a HOME environment variable, the above lines will work as intended. Of course, you need to make sure each user gets a *different* HOME :-). $ENV::foo is the notation in the configuration file to fetch the value of the environment variable foo. Therefore $ENV::HOME will get the value of HOME... Also you can put a definition "HOME = whatever" into the main section of the configuration file, and it will be used if there's no environment variable of that name (that's the usual fallback to the default section, $ENV::HOME means "look up HOME in section ENV"). The current development versions have "HOME = .", i.e. use the working directory, which is a lot better than having applications fail with an obscure error messages when HOME is not defined. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
So any preferences or alternative suggestions? peek for iget and copy for rget I like the peek thing, but "copy" is not a perfect choice of words: [...] Also note that we need a convention not just for "get" functions, there are also "set" functions. SSL_CTX_set_tmp_dh and SSL_CTX_set_tmp_rsa (macros actually, not functions) behave differently, and this should reflect in the names. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem with RSA routines
Simon Edwards [EMAIL PROTECTED]: I'm having problems using the RSA routines from openssl 0.9.4. I've got a very simple C program which generates and RSA key (I'm not worried about the randomness of the key at this stage) and then proceeds to read data from a file encrypting the data and then decrypting it and comparing the output with the original text. (See attached C file) Whenever I pass straight ASCII text to the program it works fine and all the output matches the input. However, when I pass a binary file the first dozen or so blocks encrypt and decrypt fine, but after that I get *some* blocks (on some files it can be most blocks but not all) that don't decrypt back to the original data. You are not using RSA properly. Read in some cryptography FAQ or textbook about padding. What is happening in your program is that after decryption you have the original data block modulo n, which means no change when it is pure ASCII (and n's size in bits is a multiple of 8), but can lead to corrupt data when the first byte has the MSB set: then possibly the plaintext block P is = n, and the decryption result is P - n instead of P. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
Arne Ansper [EMAIL PROTECTED]: So any preferences or alternative suggestions? peek for iget and copy for rget I like the peek thing, but "copy" is not a perfect choice of words: There's a difference between really copying a structure on the one hand and just providing another pointer and a reference count on the other hand. When a structure is copied, you can change values without interfering with the owners of other copies; not so if just a reference count is incremented. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: obj_dat.c problems in OpenSSL
cc: "obj_dat.c", line 96: error 1588: "NUM_NID" undefined. or obj_dat.c:96: `NUM_NID' undeclared here (not in a function) The macro NUM_NID should be defined in file crypto/objects/obj_dat.h, which is automatically generated by a Perl script. cd to crypto/objects and run "perl obj_dat.pl objects.h obj_dat.h". If this does not help, please mail us the contents of file obj_dat.h so that we can see what is going wrong. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
dep/
Does anyone want to keep the dep/ directory and its contents? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [patch] 56bit cipher handling patch Version B.03
Lutz Jaenicke [EMAIL PROTECTED]: [...] This patch enhances the SSL/TLS cipher mechanism to correctly handle the TLS 56bit ciphers. Without this patch the 56bit ciphers can be enabled, but the sorting is wrong (visible in client mode, since the first cipher the client lists and that is available on the server will be used). It also enhances the the cipher-list commands by a sorting by strength-bits (as of version B.02) and it fixes a bug in the cipher-command parser (possible endless loop) (as of version B.03). Are the any comments one this patch? Should we apply it in existing form? (I haven't yet carefully read the complete patch myself, so these questions are directed to myself as well :-) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CRYPTO_malloc_init undefined in latest snapshot
Richard Levitte - VMS Whacker [EMAIL PROTECTED]: If the LIBEAY32.DLL is linked to the MSVCRT.DLL library and the app is linked to MSVCRTD.DLL it is necessary for CRYTPO_malloc_init() to be executed by the app so that the proper memory allocation/deallocations routines are used. CRYPTO_malloc_init() did the following: CRYPTO_set_mem_functions(malloc,realloc,free) This in turn initialises five function pointers in mem.c. However, those variables are already initialised with exactly those values. Logically, this makes the CRYPTO_malloc_init() macro redudant and needless. Is this possibly some kind of glitch in Win32 when it links things in runtime, or is it some other mystery? The perversion here is that 'malloc' can be one function when the library is linked and a different one for the application (note that CRYPTO_malloc_init is a macro, so it uses the application's version of 'malloc'); i.e. the pointer actually changes although it is twice set to 'malloc'. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Session caching bug
Kyle R. Rose [EMAIL PROTECTED]: In the course of using OpenSSL for a client application, I would regularly get a SEGV in the client session caching code under high load. After some examination, I traced it to SSL_CTX_add_session, where two data structures (a hash and a list) are not being kept in sync: when a session is deleted from the hash, it is not correspondingly deleted from the list, causing that memory to be freed twice (once as a dangling pointer, of course) when it is finally taken off the list. If you are writing a *client*, then why is SSL_CTX_add_session used at all? Usually it is only used for servers unless you set the SSL_SESS_CACHE_CLIENT bit in the SSL_CTX's session_cache_mode. Assuming that you're actually writing a server -- does your application set SSL_SESS_CACHE_NO_INTERNAL_LOOKUP? While examining ssl_sess.c I found that it cannot work because it can violate some invariants that other functions rely on (there may not be multiple SSL_SESSIONs with the same session ID). Also a multi-threaded server with external cache can run into problems for similar reasons. And applications that directly call SSL_CTX_add_session can run into the same kind of problems. Does anything of this apply to your application? If so, the next OpenSSL snapshot should solve the problem; otherwise I haven't yet found the real cause of your problem. I submit the following patch, which has solved our SEGV problems: The patch should work, but the list will be reordered each time a session is reused. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug report with patch
Peter 'Luna' Runestig [EMAIL PROTECTED]: Problem: If the negotiated cipher is ADH (ie, the SSL_aNULL flag is set) and if the verify mode is SSL_VERIFY_PEER, the server will send a certificate request to the client. The receipt of this request by the client is considered a fatal protocol error in TLS. Therefore, the request should not be sent. Fix: The following patch to s3_srvr.c prevents the sending of the certificate request by the server when the cipher suite is anonymous. Probably ADH ciphers should be automatically excluded if SSL_VERIFY_PEER is set. SSL_VERIFY_PEER usually means that the application *wants* the handshake to fail unless the peer can be authenticated; they should never set SSL_VERIFY_PEER if they want anonymous ciphers. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug report with patch
On Wed, Dec 29, 1999 at 10:37:24AM -0500, Jeffrey Altman wrote: Probably ADH ciphers should be automatically excluded if SSL_VERIFY_PEER is set. SSL_VERIFY_PEER usually means that the application *wants* the handshake to fail unless the peer can be authenticated; they should never set SSL_VERIFY_PEER if they want anonymous ciphers. Not true. SSL_VERIFY_PEER means that the application is requesting the peer to send a certificate (if possible). Only if SSL_VERIFY_FAIL_IF_NO_PEER_CERT does a certificate become required. Yes, you're right of course. Sorry for the confusion. Anonymous ciphers should be excluded if SSL_VERIFY_FAIL_IF_NO_PEER_CERT is set but not if only SSL_VERIFY_PEER is set. Yes. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Other quetion..
Shmuel Siegel wrote: I have tried porting a recent version ( say two weeks old) to a Macintosh. I am having problems with certificate verification in ssltest. SSL2 verification of both server and client certificates works. However for SSL3 the client complains about the server certificate chain. What are the differences between SSL2 and SSL3 that this should happen, or did I have the misfortune of picking up a set of files that were in transition. I think I did change a few things around then and there was one snapshot that was definitely broken. Also the chain verify code rejected the test chains because they were invalid: the certificates have been changed in the latest snapshot. Also there were multiple reports on problems on MacOS X that caused a handshake in ssltest.c to fail; it looked very much like a compiler error according to my remote debugging. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: X509 reference counts
Geoff Thorpe [EMAIL PROTECTED]: The idea is that you hand those BIOs over to the SSL library, you usually don't keep pointers of your own. SSL_free(ssl) will call BIO_free for each of them, but just once if bio_read == bio_write, so usually everything works as intended. Obviously this is not the cleanest interface conceivable ... Well as I mentioned repeatedly on the SSL_SESSION discussion a while back, "the idea is that ..." seems to be common justification for deliberate and lazy inconsistency, both from the point of view of the library design, and from the point of view of library-usage. No, there are also inconsistencies that cannot be justified this way :-) (SSL_CTX_set_tmp_dh does not increase a reference count or copy the structure, while SSL_CTX_set_tmp_rsa does. There is an explanation for this, but I would not call it a "justification".) In this case I think the programmer(s) just wanted to "throw the BIOs into the SSL and forget about them" ... ie. why free your reference when you can just pass it over to another structure and forget about your references? Whilst this "works" it makes a mockery of the so-called "reference counting mechanism" and leaves programmers constantly in a quandry as how to correctly manage references - and occasionally how to avoid race-conditions too! Which is why, one day, we should provide variants of all those "set"s and "get"s that somehow encode in there names whether reference counts are increased or not. [...] "handing over" references and such cutting of corners leads to these inflexibilities in the way these objects/structures can be used. Agreed. [...] If you keep only the bio_ssl pointer, BIO_free_all will free everything (bio_read will be freed twice because it's also at the next_bio pointer, so its reference count goes down to zero). But I don't want to "keep only the bio_ssl pointer" ... for one thing, once that handshake is complete I want to examine the session negotiated, grab the peer certificate (both of which reveal further reference counting anomalies but that's another soap-box), and possibly other SSL things that have nothing to do with the BIO which is simply an IO device. If you want to do those SSL things, then the easiest thing is not to use a bio_ssl in the first place. Many programs work directly with SSL pointers without adding the extra BIO layer; probably this is why the reference-counting problems inherent in bio_ssl's don't seem to disturb too many people. (Or, they avoid bio_ssl's *because* they look strange.) Similarly, using memory BIOs like ssl_test.s does always looked like an ugly kludge to me, presumably because it is -- thus usually the read and write BIOs are the same and the reference counting problems in this area are not visible to the library user. [...] That's why the comment in bio.h says "WARNING WARNING ... make sure you are doing a BIO_free_all()" since SSLeay 0.9.0b. BIO_free_all follows the next_bio chain, BIO_free does not; I'm not sure if BIO_free has any use at all except when you are sure that that next_bio == NULL in which case both functions do the same anyway. Hardly bodes well when one has to sift through the .h file to discover API design comments that themselves admit to being a tad obscure and, even after finding and reading, leaves us in some doubt as to how things work and what the point is. Finding out how things work is usually possible given that the source is available; I'm not always sure what the point is though. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Maintaining an SSL server cache
James Darwin [EMAIL PROTECTED]: I'm having trouble makeing the server side cache hang on to SSL sessions when all connections from the client are lost. If the client maintains one open connection, and re-uses its ssl session, the cache on the server knows to use the same session - i.e. the SSL_get_session() gives me the same number. But if the client drops its last connection, and creates a new connection to the server, still using the same ssl session as before, the server sees this as a new ssl session. BTW, SSL_free() is called when a connection is dropped in order to clean up memory. Do you create all server SSLs from the same SSL_CTX? If so, sessions should survive automatically; but you should set a session ID context for the SSL_CTX (it is used only if you do client verification, i.e. when SSL_VERIFY_PEER is set). If this does not work, then use a debugger to see what is happening (ssl/ssl_sess.c is the most important OpenSSL source code file for this): Is ssl_clear_bad_session ever called when your program is run? What happens inside ssl_get_prev_session (i.e. what "if" conditions there are true)? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: How to timeout a SSL_connect?
Alexey Melnikov [EMAIL PROTECTED]: You should use select() with timeout, however this will require modifications to OpenSSL. Why? What modifications? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: How to use OpenSSL with nonblocking IO
On Thu, Dec 16, 1999 at 05:40:18PM -0700, Alexey Melnikov wrote: I am developing multithreaded server that uses asynchronous socket IO. I would like to add SSL support, however it seems that OpenSSL handles socket IO itself. Server architecture requires that all socket operations are controlled by socket IO subsystem, but not by OpenSSL. Does anybody use OpenSSL with nonblocking sockets? Non-blocking sockets (of the O_NONBLOCK kind) are no problem even if OpenSSL does all the socket I/O itself. If you need some other variety of I/O and don't want to write a special BIO module for it, then look at BIO pairs (crypto/bio/bss_bio.c, example code in ssl/ssltest.c, more example code [in Lisp] available from URL: ftp://ftp.lavielle.com/pub%2fcl-https%2f1999-10-15;type=d). They are pipe-like -- you can give one end to the SSL library for writing and reading, at the other end your application relays between the SSL library and the actual I/O mechanisms. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Is OpenSSL thread-safe?
Sean O'Dell [EMAIL PROTECTED]: I'm using a single CTX for each SSL. I perform the accept() in the main thread and then spawn a new thread. In the new thread, I create a new SSL with the one common CTX, then perform SSL_accept, etc., including SSL_shutdown; all in the new thread. Does that sound OK? Yes. You have to provide a number of mutexes to OpenSSL -- look at the stunnel source for an example. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: make test troubles
On Wed, Dec 08, 1999 at 10:10:10AM -0800, Michael DeMan wrote: I have built openssl on a PowerPC running MacOSX server. The build works under the following configure: ./Configure gcc no-threads But when I run 'make test' it stops as show below. I am absolutely clueless on where to go from here. Certificate details subject=/C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 issuer= /C=AU/O=Dodgy Brothers/CN=Dodgy CA notBefore=Dec 8 02:52:32 1999 GMT notAfter=Jan 7 02:52:32 2000 GMT The generated CA certificate is certCA.ss The generated CA private key is keyCA.ss The generated user certificate is certU.ss The generated user private key is keyU.ss test SSL protocol test sslv2 ERROR in CLIENT 4158:error:1406D0D8:SSL routines:GET_SERVER_HELLO:reuse cert length not zero:s2_clnt.c:337: Protocol SSLv2, cipher (NONE), (NONE) This likely is a strange compiler error on that platform. The problem has been reported before, and I tried to hand-debug it via e-mail, but at some point I did not get replies to my e-mail messages. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem with import PKCS12 to Windows
From: Dr Stephen Henson [EMAIL PROTECTED] To: [EMAIL PROTECTED] From: Ziacek Martin [EMAIL PROTECTED] To: "'[EMAIL PROTECTED] '" [EMAIL PROTECTED] Remember that messages to openssl-bugs usually come from people who are not subscribed to openssl-dev, and without Cc's to them they won't be able to read the replies. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA BSAFE kit Vs OpenSSL
Gilles LERAT [EMAIL PROTECTED]: Michael Ströder [EMAIL PROTECTED]: OpenSSL and BSAFE SSL-C both are derived from SSLeay. The most important difference between the two is the price. ;-) And the RSA license. You mean the use of the OpenSSL toolkit does not require a licence for the RSA algorithm ?? No, he means that BSAFE SSL-C is available with RSA patent licenses (where needed). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: make test fails on IRIX 6.5
John A. Reed [EMAIL PROTECTED]: I am attempting to install OpenSSL 0.9.5-dev (from the openssl-SNAP-19991202 snapshot) on an SGI running IRIX 6.5. make runs fine, but when I run make test, it fails when attempting to test sslv2 server authentication: test SSL protocol test sslv2 Protocol SSLv2, cipher SSLv2, DES-CBC3-MD5 test sslv2 with server authentication server authentication ./testssl[7]: 98299 Memory fault You have to expect problems with snapshots; OpenSSL 0.9.5-dev is work in progress. Try the OpenSSL 0.9.4 distribution. (Of course you are also welcome to help debug OpenSSL 0.9.5-dev, but you'd have to provide more details then -- e.g. the stack at time of the crash.) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: no-rsa
On Thu, Dec 02, 1999 at 02:09:08PM -0800, Sean Walker wrote: [...] I can't use SSLv2 without RSA. Is this normal? Yes, SSLv2 has only RSA ciphersuites. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: no-rsa
On Wed, Dec 01, 1999 at 12:39:26PM -0800, Sean Walker wrote: Has anyone been able to compile using the "no-rsa" flag under WindowNT. I get 26 unresolved functions at link time. This appears to happen because there are functions in libeay32.def that are from files that are not compiled. Not a chance. The defines are incorrect and remove essential functions. There are several functions that get removed by the defines that are required elsewhere in the code that is non-rsa dependant code. Removing the entries from the .def files will not fix it as they are used in the code. I don't know enough about the code to fix it, or else I would have already. Some time ago I verified that, for some version of OpenSSL 0.9.4-dev or 0.9.5-dev, compiling the software with no-rsa works (and DSA/DH connections work with the resulting software). I used Mingw32 then, and it may use the DEF files differently, but certainly the software linked as expected. Did you run all the appropriate script in the ms subdirectory to build the DEF files? Did it correctly read the options from Makefile.ssl in the top directory (you can insert a line "print;" in the function definition for read_options in util/mk1mf.pl to verify what options reach the program)? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/ssl ssl_sess.c
On Tue, Nov 16, 1999 at 10:30:10PM +, Geoff Thorpe wrote: Maybe we should have a naming convention for ..._set_... calls too? There are already such ambiguities for them, e.g. SSL_CTX_set_tmp_rsa vs. SSL_CTX_set_tmp_dh. It seems to be a play-off between backwards compatibility, and having a good library-API. I prefer the latter, but I don't have as much legacy code to maintain as some others do, and I probably find the current "inconsistencies" a little more distasteful than some others do. I don't like them either (especially the SSL_CTX_set_tmp_rsa / dh example because they are "obviously" similar, but behave quite differently), but if we change this and get rid of the existing API then we have to change function names so that old code does not even compile, or there'll be tons of _non-obviously_ broken applications, which would be really, really bad. It seems that everything works if you make the calls the way the authors had intended rather than making the calls the way the authors made available. How can you tell what is the "intended" way? For SSL_get_session, the code consistently assumes that no free-ing is necessary (cf. apps/s_*.c), althoughly surely it would have made sense to demand it. If 0.9.4 has faults, surely it is preferable to fix them in 0.9.5 and for dependant code to stick with 0.9.4 until it has been brought in line with 0.9.5's fixes. The trouble is that 0.9.4 has various bugs which should be fixed for all applications before upgrading to the new library version becomes too difficult. [...] As SSL_get_session is an exported API function and SSL_SESSION has reference counting, it seemed only reasonable that what I was returned would be a valid reference, and not just a copy of a pointer. There seems no reason why there should be any assumption that the SSL_SESSION lifespan sits within the SSL structure - it's an object with a reference count! If SSL_get_session was a newly invented function, it should increase the reference count. Unfortunately, it already exists and has a different behaviour. Now why an SSL can't have a reference count higher than one, and be relevant to multiple threads each wanting a safe reference to it is beyond me. There's no locking done for accesses on SSL structures. Unlike with standard Unix file descriptors you cannot have one thread read and another thread write at the same time, or have multiple threads read at the same time or something like that, so it's best not to give the SSL pointer to more than one thread in the first place. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSLeay equivalent...
On Thu, Nov 11, 1999 at 03:36:01PM +, Geoff Thorpe wrote: [...] So, if SSL_CTX_set_session_id_context doesn't exist then that's probably because it hadn't been introduced at that point and isn't needed. I belive this issue only applies to session caches you implement yourself via callbacks - a default session cache is contained within each SSL_CTX and they are not shared unless you implement some mechanism to do it. Correct, but note that SSL_CTX_set_session_id_context must be set anyway in these cases. The rationale is that if we did not look at a session context for objects that come from the internal session cache, we'd likely see programs where much effort is put in implementing an external cache but where this cache is totally disfunctional because during testing only the internal cache was ever used, any items stored in the external cache being refused. Always insisting on a session ID context makes such errors obvious because you will never get a reused session. To check whether an SSL *ssl has a reused session, look at SSL_session_reused(ssl). If you have a debug logfile, you definitely should log this. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL nasty shared library issue...
On Wed, Oct 27, 1999 at 05:04:25PM +0100, Dr Stephen Henson wrote: While developing some chain verify code (yes it'll get there eventually!) and always on the lookout for problems with shared libraries something nasty has become apparent. Its been decided that OpenSSL should be made more "shared library friendly" so that software designed to work with older versions of OpenSSL can still work with newer version by just upgrading OpenSSL shared libs and not recompiling the sofware. [...] X509_STORE_CTX ctx; X509_STORE_CTX_init(ctx,...); This isn't the only place where this construction occurs digest and cipher code and several other areas have this general construction: SOME_STRUCTURE x; SOME_STRUCTURE_init(x,...); This is a problem because the size of 'x' is determined at compile time. If a new version of the library increases the size of the structure the functions could end up walking over memory they shouldn't. Can't we just add SOME_STRUCTURE_new and SOME_STRUCTURE_free functions for programs that want to be portable across versions? I don't think that we have to break programs that currently use the above construct. Where it is used in the library itself there is no problem, except that the SSL library ought to check that it is running with a matching version of the crypto library. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL nasty shared library issue...
Richard Levitte - VMS Whacker [EMAIL PROTECTED]: Can't we just add SOME_STRUCTURE_new and SOME_STRUCTURE_free functions for programs that want to be portable across versions? I see that you're volunteering to take the support questions that will arise every time libcrypto.so and libssl.so are upgraded somewhere in the world :-). Proposal: Turn SOME_STRUCTURE_init into a macro that calls SOME_STRUCTURE_init_internal with the same arguments plus an additional one that contains the version number. The implementation is like what SOME_STRUCTURE_init does now, but additionally checks whether this additional argument matches the current version number; if not, it pokes fun at the user for trying to mix incompatible library versions. There is no need to disturb programs that are only meant to be used with statically linked libraries. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Is OpenSSL thread safe?
Hannes Reinecke [EMAIL PROTECTED]: [...] I've been using OpenSSL for about 1 year now in a multi-threaded application without any problems and special precautions. You do need special precautions -- callbacks for mutexes and for querying the thread ID. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: References: where ?
Massimiliano Pala [EMAIL PROTECTED]: I am in search of the following references. Does anybody know where them can be found? ISO/IEC 8824-1:1995: [... etc. ...] See http://www.iso.ch. None of these standards are available for free. Note that the OSI standards by ISO have equivalent ITU recommendations -- those might be easier to obtain. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Clean install with no-idea fails
[EMAIL PROTECTED] [EMAIL PROTECTED]: On unix, - Do a clean install of the current snapshot source code - config no-idea - Symbolic links for the includes are created in include/openssl/, but one is not created for idea.h. - make - Make stops with an error in crypto/hmac because it can't find ../../include/openssl/idea.h which is listed as a dependency for hmac.o. Workaround: Do "config" before "config no-idea", so all the links are created. Fix: "make links" should ignore -DNO_* defines and create all links unconditionally. You can run "make depend" between "config no-idea" and "make" to avoid that error. The library source code is meant to be able to handle even situations where the whole subdirectory of some cipher has been deleted, so we cannot just always make all the links. We could use more complicated Makefiles that always make links for every subdirectory that is there, though. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug in BIO_should_retry() under Win32 with non-blocking sockets (sconnect.c)
On Sat, Oct 09, 1999 at 09:52:09PM -0500, Richard Wagner wrote:
I compiled and ran demos/bio/sconnect.c. In this I found a problem
with BIO_should_retry() [on Windows]
for (;;)
{
i=BIO_write(out,(p[off]),len);
if (i = 0)
{
if (BIO_should_retry(out))
{
fprintf(stderr,"write DELAY\n");
sleep(1);
continue;
}
else
{
goto err;
}
}
off+=i;
len-=i;
if (len = 0) break;
}
Under Win32 when BIO_write() is first called it returns -1 and the
BIO_should_rety() returns 8. The next time it is called (after the 1
second sleep) BIO_write() again returns -1 but this time
BIO_should_retry() returns 0! It does this for a few seconds before
starting to return 8 again. [...]
Can you look what's going on inside crypto/bio/bss_sock.c, function
BIO_sock_should_retry (which is queried by the function that BIO_write
ends up calling when that function decides whether to set the retry
flag)? There's some disabled code there; maybe switching it on again
helps here (which would mean that WSAGetLastError(), aka
get_last_socket_error(), returned 0 for that retry)?
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Problems using browsers with OpenSSL Server
On Fri, Sep 24, 1999 at 10:05:28AM -0400, Jim Miller wrote:
Anyone had any problems with a browser trying to connect to an OpenSSL
server? I seem to be getting upset down in the code because of a
version conflict.
Call trace:
mycode()
SSL_accept()
ssl3_accept()
ssl3_get_message()
ssl3_read_bytes()
ssl3_get_record()
{
snip
p = s-packet; // my packet looks like this at the beginning 80 40 01
03 00
You're using one of these:
SSL_METHOD *SSLv3_method(void); /* SSLv3 */
SSL_METHOD *SSLv3_server_method(void); /* SSLv3 */
but should be using one of these:
SSL_METHOD *SSLv23_method(void);/* SSLv3 but can rollback to v2 */
SSL_METHOD *SSLv23_server_method(void); /* SSLv3 but can rollback to v2 */
SSLv23_[server_]method supports the backwards compatible client hello
format that most clients use by default. SSLv3_[server_]method
supports *only* native SSL 3.0 -- no TLS 1.0 (which already exists in
many browsers), no backward compatible client hellos.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: s_server.c: ugly behavior in debug mode
René G. Eberhard [EMAIL PROTECTED]:
File: s_server.c
Version: OpenSSL 0.9.4
Starting line: 633
System: VC++ 6 SP3, NT 4 SP5
It should be checked whether 'CAfile' is NULL or not. In debug mode
I run into a'_ASSERTE(file != NULL);' in VC98\CRT\SRC\FOPEN.C.
It's not a bug but ugly to use in debug mode.
if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
(!SSL_CTX_set_default_verify_paths(ctx)))
{
It is a bug, but not in that line (the functions called from this one
don't try to open the file when given NULL).
diff -u -r1.31 s_server.c
--- s_server.c 1999/09/20 22:09:17 1.31
+++ s_server.c 1999/09/24 08:01:12
@@ -699,7 +699,8 @@
SSL_CTX_set_session_id_context(ctx,(void*)s_server_session_id_context,
sizeof s_server_session_id_context);
- SSL_CTX_set_client_CA_list(ctx,SSL_load_client_CA_file(CAfile));
+ if (CAfile != NULL)
+ SSL_CTX_set_client_CA_list(ctx,SSL_load_client_CA_file(CAfile));
BIO_printf(bio_s_out,"ACCEPT\n");
if (www)
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [David Engel: Bug#43196: SSL telnet sessions pause unexpectedly]
Create an SSL connection to localhost. View a file with less or emacs. For best results, use a file with long lines that fill the screen. Hit ^L to redraw the screen repeatedly, Eventually, only a partial redraw will take place and won't complete until another key is pressed. FWIW, this problem has existed since the switch to the openssl based libssl09 and telnet(d)-ssl packages were introduced. This sounds like an application bug -- probably it uses select() when the SSL buffers still have data. (Even s_client had this bug.) Solution: Use non-blocking I/O and try SSL_read just in case (or skip it if SSL_pending returns 0 -- but SSL_pending returning non-0 does not mean that there's actually any application data available); use select() only if SSL_read asks for it. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: make fails when try to compile OpenSSL
On Wed, Sep 15, 1999 at 04:13:50PM -0700, Cominetti, Lisa B wrote: I'm trying to compile OpenSSL version 0.9.4. ./config -t :Operating system: sun4u-sun-solaris2 Configuring for solaris-sparcv9-cc /usr/bin/perl ./Configure solaris-sparcv9-cc The error message is: "making all in crypto... /bin/sh: make: not found make: ***[all] Error 1" Your PATH is set incorrectly. Probably you should add /usr/ccs/bin to it. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Compiling on Mac OS X Server works but fails test
On Fri, Sep 17, 1999 at 01:53:11AM -0400, Dave Wu wrote: I'm trying to compile OpenSSL-0.9.4 on the Mac OS X Server platform. [...] However when I "make test" I get the following error: The generated CA certificate is certCA.ss The generated CA private key is keyCA.ss The generated user certificate is certU.ss The generated user private key is keyU.ss test SSL protocol test sslv2 ERROR in LCIENT 5471:error:1406D0D8:SSL routines:GET_SERVER_HELLO:reuse cert length not zero:s2_clnt.c:337: Protocol SSLv2, cipher (NONE), (NONE) make[1]: *** [test_ssl] Error 1 make: *** [tests] Error 2 Can anyone help with this? Has anyone successfully installed OpenSSL on OSXS? This problem has been reported before, but none of us has access to a Mac OS X Server system to look at this in detail. After my previous investigation, my bet is that this is an egcs bug; but no solution is known yet. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [REPOST] internal SSL session cache question(s)
On Tue, Sep 14, 1999 at 12:22:56PM -0700, [EMAIL PROTECTED] wrote: [...] This is all theory at this point, but it seems as though there is a problem with SSL_set_timeout(...) (or my use of it). What functions and macros do you use? Usually you should not need SSL_set_timeout; what you need is SSL_CTX_set_timeout on the SSL_CTX before any sessions are created. SSL_set_timeout on an SSL_SESSION does not affect the copy of that session that may be in an external cache. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [REPOST] internal SSL session cache question(s)
On Tue, Sep 14, 1999 at 10:25:55AM +0100, Ben Laurie wrote: [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Bodo Moeller) writes: I have not looked too closesly at this issue, but shouldn't this part of ssl_get_prev_session (which is exectuted right before the succesful return) appropriately take care of it? Hmm... The behavior is a bit more like what I would expect if this is moved up so that it is invoked /before/ the get_session_cb? I'll have to look into this a bit more closely. In the case of an external session cache, it is its responsibility to enforce whatever aging policy it has. You have to implement your own policy for getting rid of stale entries, but I don't think the SSL library will continue to actually use them when the timeout has expired. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [REPOST] internal SSL session cache question(s)
[EMAIL PROTECTED] [EMAIL PROTECTED]:
As best as I can tell, in versions 0.9.2b and 0.9.4, OpenSSL's internal SSL
session cache does not bother to pay attention to the SSL session timeout
value as set by SSL_set_timeout(...). [...]
The relevant code seems to be in ssl_get_prev_session(...). The call to
lh_retrieve is made without any timeout checks.
I have not looked too closesly at this issue, but shouldn't this part
of ssl_get_prev_session (which is exectuted right before the succesful
return) appropriately take care of it?
if ((long)(ret-time+ret-timeout) (long)time(NULL)) /* timeout */
{
s-ctx-stats.sess_timeout++;
/* remove it from the cache */
SSL_CTX_remove_session(s-ctx,ret);
goto err;
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: trying to add SSL to a web client
Jef Poskanzer [EMAIL PROTECTED]: Still haven't gotten this to work. I moved the new SSL code into an even simpler client program, similar to the ones in the demos directories. Now at least ERR_print_errors_fp() tells me something, instead of just doing nothing like it did in the previous program. No idea why that wasn't working before. Anyway, on SSL_connect() it now says: 4012:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:463: This is when trying to connect to https://www.apache-ssl.org/ Are you really connecting to port 443? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: trying to add SSL to a web client
On Mon, Sep 06, 1999 at 08:07:59PM -0700, Jef Poskanzer wrote: [...] When I run it, the SSL_connect() always returns -1. Probably it's a non-blocking socket? Either switch to blocking I/O if that is appropriate, or browse the openssl-dev mailing list archives for information on how to use non-blocking I/O correctly. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug in bn_mul.c/bn_lcl.h
Axel Beckert [EMAIL PROTECTED]: Just had a problem compiling openssl 0.9.1c [...] Try OpenSSL 0.9.4. 0.9.1c has millions of bugs. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Macintosh Port diffs
Andy Polyakov [EMAIL PROTECTED]: -#include sys/types.h -#include sys/stat.h + +#ifndef macintosh +# include sys/types.h +# include sys/stat.h +#endif [...] I'd suggest to replace #ifdef macintosh with #ifdef MAC_OS Maybe MAC_OS is not quite an appropriate symbol, Maybe... How about MAC_OS_pre_X then? as things change with MacOS X. Do they:-) Did you know that it comes without X11? Sure. But it comes with sys/types.h and sys/stat.h, which is what these patches are about. (Also it comes with built-in deadlocks -- if you believe the package design: The toothed wheels are so arranged that they cannot turn at all because between pairs of neighbouring large wheels there's often a small one that touches both, meaning that it would have to turn clockwise and counterclockwise at the same time if the large wheels were moved.) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Macintosh Port diffs
Andy Polyakov [EMAIL PROTECTED]: -#include sys/types.h -#include sys/stat.h + +#ifndef macintosh +# include sys/types.h +# include sys/stat.h +#endif [...] I'd suggest to replace #ifdef macintosh with #ifdef MAC_OS and put something like following into e_os.h: #if defined(__MWERKS__) defined(macintosh) # if macintosh==1 # define MAC_OS # endif #endif Maybe MAC_OS is not quite an appropriate symbol, as things change with MacOS X. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
