Re: Tiny bug on OpenSSL crypto/lhash/lh_test.c
On Thu, Mar 21, 2002 at 04:29:29AM +, Justin Fletcher wrote:
Hiya,
This isn't at all serious; it's only in test code, but it might cause
false negatives under pathological circumstances. The code reads :
--8
main()
{
LHASH *conf;
char buf[256];
int i;
conf=lh_new(lh_strhash,strcmp);
for (;;)
{
char *p;
buf[0]='\0';
fgets(buf,256,stdin);
if (buf[0] == '\0') break;
buf[256]='\0'; /* JRF: THIS IS A FAULT */
i=strlen(buf);
p=OPENSSL_malloc(i+1);
memcpy(p,buf,i+1);
lh_insert(conf,p);
}
lh_node_stats(conf,stdout);
lh_stats(conf,stdout);
lh_node_usage_stats(conf,stdout);
exit(0);
}
--8
buf[256] cannot be referenced because it is outside the array allocated
in the automatic variables. This raises an 'array out of bounds' warning
on Norcroft C.
Hmm. fgets(buf,256,stdin) will read at most 256-1 bytes and will
append the trailing '\0', at least according to KR 2.
Therefore the offending statement could simply be removed...
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: ssl_verify_alarm_type
On Sat, Mar 16, 2002 at 12:06:15AM -0800, Tom Wu wrote: In both 0.9.6c and 0.9.7-SNAP, the function ssl_verify_alarm_type in ssl/s3_both.c seems to be missing the newest x509 verification error codes, like X509_V_ERR_INVALID_PURPOSE, in the switch statment. If such a verification error is encountered, the switch will fall through and an unknown ca alert (SSL_AD_CERTIFICATE_UNKNOWN) will be returned, instead of SSL_AD_UNSUPPORTED_CERTIFICATE in this case. I can submit a patch, if anyone is interested. Indeed. If you have it at hand, please submit it to openssl-dev. (Don't forget to CC to [EMAIL PROTECTED]). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: -ciphers bug
On Wed, Mar 06, 2002 at 04:43:20PM +, Ben Laurie wrote: Adam Back wrote: It seems that if you enable ADH but disable MEDIUM ciphersuites, they get left on anyway. I guess not too many people enable ADH, but there are scenarios where it is useful, and so this seems like a security bug. What I did: % openssl s_server -state -CApath certs -cipher 'ALL' and connect to it with % openssl s_client -cipher ADH:\!EXP:\!LOW:!'MEDIUM then the server prints: Shared ciphers:ADH-DES-CBC3-SHA:ADH-DES-CBC-SHA:ADH-RC4-MD5 ADH-DES-CBC-SHA is single DES and so fails LOW, and shouldn't be in the list. Quite so, and this will fix it: Index: ssl/s3_lib.c === RCS file: /e/openssl/cvs/openssl/ssl/s3_lib.c,v retrieving revision 1.57 diff -u -r1.57 s3_lib.c --- ssl/s3_lib.c2001/10/20 17:56:35 1.57 +++ ssl/s3_lib.c2002/03/06 16:41:55 @@ -196,7 +196,7 @@ SSL3_TXT_ADH_DES_64_CBC_SHA, SSL3_CK_ADH_DES_64_CBC_SHA, SSL_kEDH |SSL_aNULL|SSL_DES |SSL_SHA1|SSL_SSLV3, - SSL_NOT_EXP, + SSL_NOT_EXP|SSL_LOW, 0, 56, 56, Just committing now. I left your message in my queue, because I wanted to check it out again. * DES_64 is 56 bits long, so it would also qualify as SSL_EXP56!? instead of SSL_LOW. This is probably a question of definition. Opinions? (The exportability is handled seperately by the SSL_NOT_EXP flag...) * Some other ciphers are also missing the strength class setting. But I would like the first point discussed before filling in. * Technically, this fix should not only go into 0.9.7-stable but also into -dev. Should it also go into 0.9.6-stable? Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_clear code
On Wed, Feb 27, 2002 at 12:16:13PM +0200, Yoram Zahavi wrote:
Hi Lutz,
I've just checked your last patch. I guess additional fix is required.
setting :
s-shutdown=0;
should be done only after calling:
if (ssl_clear_bad_session(s))
{
SSL_SESSION_free(s-session);
s-session=NULL;
}
Otherwise, the SSL_SENT_SHUTDOWN flag is not taken into account when
checking out if session should be removed from cache.
Seems you are right again. Moved the bad-session-removal to the top...
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Fix for linking shared libraries on HPUX
On Sat, Feb 16, 2002 at 06:15:36PM -0500, Tom Lane wrote: Hi folks, I was pleased to see that openssl 0.9.6c finally tries to support building shared libraries on HPUX. It's not quite there yet, though. I recommend the attached patch. I see that in your CVS head the hpux make targets have been patched in a different way, but I consider that solution inferior: it's gratuitously different from all the other platforms, it deliberately breaks HPUX's shared lib dependency records, and it still doesn't fix the *real* problem, which is to make sure that libssl.sl contains the correct absolute path for libcrypto.sl so that the latter can be found when the former is loaded. The right way to make that happen, IMHO, is to set the absolute path in libcrypto.sl's internal name --- see +h switch in the attached. Did you try to run make test without prior installing OpenSSL? Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: session reuse in 0.9.6c
On Mon, Feb 18, 2002 at 02:01:29PM -, Craig Hellon wrote: Looks like the problem is already known as 0.9.7 is not released yet can anyone send me this fixed s3_svr.c ? You can access the CVSweb interface at www.openssl.org and download the version for 0.9.6-stable with the fix in it yourself. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL (openssl-0.9.1c)
On Thu, Feb 14, 2002 at 04:16:40PM +0100, Richard Levitte - VMS Whacker wrote: From: Khan Alamgir [EMAIL PROTECTED] akh Please help! Use a more modern OpenSSL. The current release is 0.9.6c. And call SSL_library_init() :-) Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: bug in openssl session cache
On Thu, Feb 07, 2002 at 03:38:32PM +0200, Izhar Shoshani Levi wrote: I found a bug in ssl session cache, please check it. SSL_CTX_session_remove trying to find the session in the cache and delete it but when calling SSL_SESSION_list_remove, in case that r != NULL the wrong session is sent to the function, instead of sending r which is the one that is in the cache c is been sent. I have just checked in an appropriate fix, it will be included in the next snapshots. Please check out your test case again. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Futher debug of race condition in 0.9.6b/c
On Fri, Feb 08, 2002 at 01:53:11AM -0700, Dax Kelson wrote: sshd/ftpd/telnetd - pam_ldap - libldap - libssl/libcrypto To recap, when my dual processor Pentium III is idle, I *always* get a return value of 0 from SSL_connect. If I bog down the box, I get 1 and everything works (login sucessful). I added a check for SSL_get_error, and I get SSL_ERROR_SYSCALL. I check the error queue with ERR_get_error() My luck, I get 0 back from ERR_get_error(). The man page says, if ERR_get_error returns 0, an EOF was observed that violates the protocol. sigh I just want my LDAP authentication to work on these two machines out of about a dozen where it works fine. The machines that work are slower 500Mhz boxes, and the failure on a dual P3, and a single CPU AMD 1700+. pam_ldap is using libldap (further using OpenSSL) to do a starttls connection against a remote OpenLDAP server. I'm just banging my head against the keyboard here. Start by using ssldump (http://www.rtfm.com/ssldump). We really need to see what is going over the wire... (an EOF... would mean that it is the peer closing the connection... is this really true?). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: bug in openssl session cache
On Thu, Feb 07, 2002 at 03:38:32PM +0200, Izhar Shoshani Levi wrote:
I found a bug in ssl session cache, please check it.
SSL_CTX_session_remove trying to find the session in the cache and delete it
but when calling SSL_SESSION_list_remove, in case that r != NULL the wrong
session is
sent to the function, instead of sending r which is the one that is in the
cache c is been sent.
I had a look into the problem in the meantime. The problem seems to arrive
from the following construct:
* One can pass a copy of a session to SSL_CTX_remove_session() that
is not in the internal session cache. Normally the operation would
simply fail.
* The session could have been created by copying a session, so that a
SSL_SESSION with the same contents is available inside the session
cache.
* lh_delete() will only check the hash value of the contents and will
thus react by removing the session that is inside the session cache.
Consequently, the bug report above is correct.
However, I would consider making a different change: if the (pointer to
an SSL_SESSION object) passed to SSL_CTX_remove_session() is not
a part of the session cache, the removal is not performed.
Thus:
if(lck) CRYPTO_w_lock(CRYPTO_LOCK_SSL_CTX);
+ if ((r = (SSL_SESSION *)lh_retrieve(ctx-sessions,c)) == c)
r=(SSL_SESSION *)lh_delete(ctx-sessions,c);
if (r != NULL)
{
ret=1;
SSL_SESSION_list_remove(ctx,c);
}
Any other opinions on what is the correct solution?
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: bug in openssl session cache
On Thu, Feb 07, 2002 at 03:38:32PM +0200, Izhar Shoshani Levi wrote: I found a bug in ssl session cache, please check it. SSL_CTX_session_remove trying to find the session in the cache and delete it but when calling SSL_SESSION_list_remove, in case that r != NULL the wrong session is sent to the function, instead of sending r which is the one that is in the cache c is been sent. Thanks for your report. I have added your report to my TODO list. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: test_sid fails!
On Sat, Jan 26, 2002 at 06:33:46AM +0100, Richard Levitte wrote: I just made a test run of the main trunk, and it ended like this: testing session-id conversions p - d p - p d - d make[2]: *** [test_sid] Error 1 make[2]: Leaving directory `/home/levitte/cvswork/dev.openssl.org/openssl/openssl/test' make[1]: *** [alltests] Error 2 make[1]: Leaving directory `/home/levitte/cvswork/dev.openssl.org/openssl/openssl/test' make: *** [tests] Error 2 Running the testing script itself gave this: : ; (cd test; sh ./tsid) testing session-id conversions p - d p - p d - d unable to load SSL_SESSION 30123:error:0D06703E:asn1 encoding routines:a2i_ASN1_STRING:asn1 length mismatch:ssl_asn1.c:375:address=136036320 offset=33 Anyone wanna look into this? I've tried, but can't really grasp what goes on... Hmm. As you may have seen from openssl-cvs I found another problem when running make test, but I could not reproduce your problem... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSH and OpenSSL snapshots
On Wed, Jan 23, 2002 at 11:21:49AM -0800, Booker C. Bense wrote: On Wed, 23 Jan 2002, Lutz Jaenicke wrote: On Wed, Jan 23, 2002 at 07:03:20AM -0800, Booker C. Bense wrote: On Wed, 23 Jan 2002, Lutz Jaenicke wrote: Ok, the behaviour of the OpenSSL-0.9.7 has been adjusted: The old interface is now working again by default, as long as OPENSSL_NO_OLD_DES_SUPPORT is not defined. Applications should be changed to the DES_* interface in the long run, as the old interface will go away at some point in the future. (Please note, that 0.9.7 providing the new interface is not even out...) - Just to confirm, the routines will be DES_foo , but you are playing cpp macro games to provide the old interface? No cpp macro games but real functions just calling the new functions. - I was afraid you'd say that... It defeats the whole point of changing the names in the first place[1]. Oh well, I'll just have to figure a way to install openssl without them. At least you tried to do the right thing. - BTW, the cpp macro trick works. I've used it in the kerberos code to allow openssl compatiblity. Looks like I'll have to keep those patches around. - Booker C. Bense [1] Unless you put them in separate library. Hmm, hmm. I actually didn't look into this issue personally (Richard Levitte handled it) and I only pointed out the state-as-is. Your point makes complete sense: as long as the des_* functions are in the library, the linker might take them. So actually it should be macros replacing the des_* calls with DES_* calls... But I am tired now, maybe not seeing the forest because there are so many trees around :-), so I will crosspost this issue to openssl-dev... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSH and OpenSSL snapshots
On Thu, Jan 24, 2002 at 02:32:24AM -0500, Jeffrey Altman wrote: djm The other problem is applications djm that link either with libdes or with openssl's libcrypto. The latter djm will very suddenly fail. djm djm How? These apps would need to be recompiled anyway - that way they would djm pick up the macros. If we retain the old symbols in the library, which is currently expected, they don't need to recompile. Re*linking* would be sufficient to satisfy the linkers idea of what the program needs. Hmm. OpenSSL 0.9.7 is not binary/API compatible with the 0.9.6x series. Applications must be recompiled anyway. djm But, this isn't the end of the story. On some architectures, there djm are binary incompatibilities between openssl's libcrypto and libdes. djm djm Aren't these what you are trying to avoid in the first place? djm The libdes shipped with MIT krbIV is an ongoing source of frustration for djm the portable OpenSSH developers. Yes, you're right, that's what we try to avoid. However, we've already had complaints about not providing the old symbols by default, so guess how people will react if they are missing in the library as well. It should not matter, as they need to recompile anyway, so macros to redefine the functions would be picked up. If the des_old functionality cannot be achieved using macros, we can still leave the wrapper functions but rename them: #define des_ecb3_encrypt(input,output,ks1,ks2,ks3) \ DES_old_ecb3_encrypt(input,output,ks1,ks2,ks3) and then call the wrapper functions des_old_*(). In this way the argument handling can be done in real functions, but in the library they are found as des_old_*, so we will never see a problem of the linker finding the wrong functions. Looks ugly? But it would help to solve the conflict. We knew there were going to be complaints no matter what was decided. However, I thought the consensus was that OpenSSL pre-1.0 is not api compatible between releases. Therefore, it didn't matter that the function names would change and the libraries would not be compatible. The longer this change gets put off the more difficult it will be to fix because there will be an ever increasing number of applications relying on it. I agree on that this problem must be solved. In former times with export restrictions the amount of cryptographic code and options (kerberos etc) was much smaller. Now that much more code of this type is available the amount of possible conflicts should be minimized. OpenSSL already cleared its namespace by moving include files into openssl/*.h allowing inclusion of similar header files with the same name, now the contents must also be worked out :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL doubts
On Mon, Jan 07, 2002 at 01:50:26PM +, Tushar wrote: 1. Cipher Selection: If the Client sends a weaker cipher (export), followed by a stronger cipher, then openssl selects the first (weaker) cipher as preferred by the client (as per the RFC). Note in the above case, an attacker can influence the order of client's cipher preference, thereby causing the peers to decide on weaker ciphers. Shouldn't there be logic to protect from such attacks? Hmm. I vaguely remember that all of the handshake is protected by cryptographic hashes, so that the modification would be noted at the end of the handshake... Given a set of ciphers, the server should be able to decide on the most strongest one, need not be the first one always. The term strongest may be technically difficult to judge on (is AES-128 stronger than 128bit-RC4?). Anyway, as of OpenSSL 0.9.7, the new SSL_OP_CIPHER_SERVER_PREFERENCE has been realized, so that the server chooses according his preferred list of ciphers. 3. What should be ideal response (RFC) of server in this situation: Server has only SSLv2 support and Client comes with SSLv3 Client-hello. Currently openssl terminates such connections. There is nothing that can be done in this case. An SSLv2 server was written (or at least implements just the technique) before SSLv3 was made available, so it cannot know how to handle the SSLv3 client hello. It is the job of the client to be backward compatible. The first official standard is RFC2246 and it describes TLSv1. Everything before it never became an official standard. It can be expected that future extensions will stay compatible with respect to the client hello. 4. session-peer cert refers to client certificate used in Client-Authentication. Is it required to store this cert once the session is establish? The main purpose of this cert is to authenticate client and verify the client's Certificate-Verify message. Once this is done, is it okay to free the cert. In session re-use there is no exchange of client's cert or cert-verify message. The client certificate is stored inside the session cache. It may be necessary to not only know certificate passed or not, but to also allow special action (e.g. login) based on the contents of the certificate. Eventually too many peer certs may hog-on server resources. Memory and hard disk became cheap these days. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EAP-TLS
On Thu, Dec 20, 2001 at 08:16:26PM -0800, Raghu wrote: From sockets perspective these are really simple questions, Since EAP handles every basic data transfer, there are no sockets/file descriptors involved. I am really finding hard to get the answers. I don't know anything about EAP. I however can offer you the standard answer for cases without sockets: use BIO-pairs. This way you have full control over the complete I/O process. I do use BIO-pairs in my Postfix/TLS patchkit available at http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/ Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: client authentication prob
On Fri, Dec 14, 2001 at 04:19:41PM +0530, ratan.sarkar wrote: I am trying to implement Client authentication through SSL .. but I am lil bit confused abt the verify callback function ... what I want is ,at the time of handshake server will get the client cerificate and server will check the DN and timestamp of the client cerificate .. I have set the SSL_CTX_set_verify(m_ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT,SSLCallBack); to get the client certificate in the server and implemented the callback function ... this is working fine but the call back finction has been called 3 times every time I am asking for client authentication ... inside the call back function I am getting the peer certificate ...but even though I am checking out the X509_notAfter field ...with an out dated certificate this the whole authentication process is working smoothly ... here is my call back function ... SSLCallBack(int ok,X509_STORE_CTX *ctx) Here the ok value shows, whether OpenSSL's internal checking routines detected a problem. Please check out, whether ok is 1 (passed verification) or 0 (verification failure). Only when ok is set to 0, the return value of X509_STORE_CTX_get_error(ctx); is significant. If not sure, you should start without a callback function and see, whether the certificate verification fails (it should). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Clarification??
On Thu, Dec 13, 2001 at 10:06:45AM +0100, Srikanta Nayak wrote: How openSSL will looks EGD ? Is there any such documentation available on net related to it? http://www.openssl.org/support/faq.html#USER1 Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: prob using the d2i_x509_fp();
On Thu, Dec 13, 2001 at 11:10:09AM +0530, ratan.sarkar wrote: pCert=PEM_read_X509(fp,NULL,0,NULL); Here bytes are read from fp and the file pointer is not reset. if(pCert==NULL) d2i_X509_fp(fp,pCert); Here the first bytes are missing, as they have already been read by PEM_read_X509(). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: segmentation violations and bus errors with OpenSSL and OpenSSH
On Tue, Dec 11, 2001 at 09:06:12AM -0600, VanWagner, Lyndon wrote: I know that this does not follow the normal bug reporting procedures, but I don't have the necessary forms/reports at my fingertips. I wanted to let you know, that I've had problems using OpenSSH (v3.0.1p1 and v3.0.2p1) with OpenSSL (v0.9.6b). Mainly, when I try generating DSA keys with ssh-keygen and running the ssh client, I get coredumps with Segmentation Violations and Bus Error signals. In both cases, the code died in OpenSSL code - the DSA and DH modules. I'm using gcc v3.0.2 and GNU make to build the stuff on older SPARC (sun4m) hardware, under Solaris 6 and 8. I took a look at the code and fixed it on my end by doing several things in mem.c, dsa_gen.c, dsa_lib.c, dh_gen.c, dh_key.c, dh_lib.c. 1) Initialized all automatic variables, including structures and arrays. 2) Added null pointer tests. 3) Increased automatic buffer allocations by 1. We have seen problems on Solaris 8 caused by buggy initialization of variables. I have checked in some workarounds for the 0.9.6c release, which is to be released really, really, really soon now. Anyway I may have missed an initialization (I hope not), so I would be interested in receiving your patch via openssl-dev. Anyway I think, that the changed you made under 1) should be sufficient. 2) should not help much, as dereferencing NULL pointers identifies program errors in the calling program and should be fixed within it. (I personally run OpenSSH on a lot of hosts on both HP-UX and Linux and have not seen corresponding bugs.) Errors falling under category 3 identify buffer overruns. Dynamic memory must be allocated as required. If increasing the size by an arbitrary number fixes a problem, there is a bug around that must be fixed. Just increasing buffer allocations only hides the problem, it does not solve it. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: argument to app_verify_callback function
On Fri, Dec 07, 2001 at 04:30:21PM -0800, D. K. Smetters wrote: I was wondering about the state of support for the argument to app_verify_callback. This callback is set by SSL_CTX_set_cert_verify_callback to allow the application to override the standard verification behavior and was supposed to take an app-supplied argument. I had a short look into the source. Your statement is correct. I also do not see a reason, why it should not be supported. You are welcome to submit a patch for inclusion into 0.9.7 (I could also write one myself, but my time is pretty limited these days). The OpenSSL code currently stores that argument and then ignores it -- it doesn't pass it on to the callback function at all. Comments in the code indicate that people know this, and vary as to whether they indicate that it ought to be fixed. The documentation still mentions the argument, but has a hasty add-on noting that it is currently ignored. Comments in the openssl-user mailing list indicate that this is not heavily used, so it wouldn't break the world to fix it. (In contrast to adding a similar argument to the default_verify_callback, which would be nice, but would probably break too much of the world.) With respect to the verify_callback: changing the API would probably break too many applications. For Postfix/TLS I utilize the ex_data feature of the SSL object, for which the verification process is being performed. This allows to pass connection related verification information. I wanted to know whether someone had decided at some point that it ought to stay this way, or whether there was any hope of getting a fix into 0.9.7 (it's a ~3-line change, and I'd be happy to supply diffs). (And before you ask, yes, I do have a perfectly reasonable reason for wanting to use this which I am happy to explain, but left out for brevity's sake.) You are invited to explain your reasons, if you consider it to be of interested for other readers of this list. One advantage of mailing lists is that they can be very informative and stimulating, because you get an insight into other peoples work. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: platform hpux-m68k-gcc
On Thu, Dec 06, 2001 at 01:09:43PM +0100, Anton J. Gamel wrote: Compilation and tests succeeded in following (old) platform: Machine: HP 9000/400 m68040@25 HP-UX 9.1y2k 64Mb Compiler: cc, version A.B9.00.2A, HP series S300/S400 Configure: hpux-m68k-gcc no-threads Thanks, applied. I have also made the entry for 0.9.7 (under developement). * Would you kindly also test the 0.9.7-snapshot version? (The change will of course take until the next snapshot build.) * Do you think that you could easily build an autodetection for config? It is the only m68k version of HP-UX, so it should be detectable... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: bug and solution wrt SSL_set_verify()
On Wed, Dec 05, 2001 at 04:57:17PM -0500, nicholas black wrote: hey there. my software's operating in both client and server mode, and needs a different verify function depending on the two. i've used SSL_CTX_set_verify() to set the default callback. i'm usually acting as a server, so i set it to my client cert verification function. when i want to connect to my server, i first get a new SSL * with SSL_new(), then attempt to change the callback function via SSL_set_verify(). said function is never called. From the CHANGES file: *) Modified SSL library such that the verify_callback that has been set specificly for an SSL object with SSL_set_verify() is actually being used. Before the change, a verify_callback set with this function was ignored and the verify_callback() set in the SSL_CTX at the time of the call was used. New function X509_STORE_CTX_set_verify_cb() introduced to allow the necessary settings. [Lutz Jaenicke] The fix will be available in 0.9.6c (due out in the next days!?) and 0.9.7. Nevertheless: thanks for your effort! Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Creating PEM file from peer cert
On Mon, Nov 19, 2001 at 11:56:05PM -0800, ct l wrote: During peer cert verification stage, I need to store the peer cert info in PEM file format for future reference. May I know: Based on info in ssl-cert, what fields and how should I arrange the fields so that I can store the peer cert as a PEM file for future verification ? The intention is to store this file so that it can be used in load_verify_location. Do not access members of the SSL object (ssl-...) directly, as these structures may change. Please use the offical API SSL_get_peer_certificate(), SSL_get_peer_cert_chain() to obtain the X509 objects. You can then simply write them to file using the PEM_write_X509()/PEM_write_bio_X509() function. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: session reuse from client side
On Tue, Nov 20, 2001 at 06:09:04PM +0200, Arne Ansper wrote:
we have a client program that uses external session database for session
caching. we have found a bug in client side session caching. or actually a
missing functionality.
after decoding stored session using d2i function the cipher parameter of
SSL_SESSION structure is zero. on server side the cipher field is filled
from cipher_id in ssl_sess.c function ssl_get_prev_session (this function
is used only in server side). in openssl 0.9.6b the relevant code looks
like this:
if (ret-cipher == NULL)
{
unsigned char buf[5],*p;
unsigned long l;
p=buf;
l=ret-cipher_id;
l2n(l,p);
if ((ret-ssl_version8) == SSL3_VERSION_MAJOR)
ret-cipher=ssl_get_cipher_by_char(s,(buf[2]));
else
ret-cipher=ssl_get_cipher_by_char(s,(buf[1]));
if (ret-cipher == NULL)
goto err;
}
but there is no function to do it on the client side.
The SSL client will receive the selected cipher from the server in the
server hello message (RFC2246, Section 7.4.1):
cipher_suite
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions this field is the
value from the state of the session being resumed.
The OpenSSL client does set the cipher based on this returned value.
It is therefore not necessary to set the cipher in advance.
Do you have any problems due to this behaviour?
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Documentation of SSL_get1_session()
On Sun, Nov 18, 2001 at 05:29:31PM -0500, [EMAIL PROTECTED] wrote: In http://www.openssl.org/docs/ssl/SSL_get_session.html#, If the data is to be kept, SSL_get1_session() will increment the reference count and the session will stay in memory until explicitly freed with SSL_SESSION_free(3), regardless of its state. But as stated in http://www.openssl.org/docs/ssl/SSL_SESSION_free.html#, a single call of SSL_SESSION_free() does NOT free the session obtained with SSL_get1_session. In order to free it, SSL_SESSION_free() must be called until the the reference count has reached 0. Thanks, I have rephrased the corresponding paragraph. Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RAND_add() and the entropy...
On Wed, Nov 14, 2001 at 07:01:28PM +0100, Juan Segarra wrote: My question relates to the entropy parameter in RAND_add() function and the use of it along the command line applications. I've observed that nearly all calls to RAND_add() have their entropy set to 0. I'm writing some examples about crypto functions and most of them need the PRNG being seeded before use and i'm very interested in doing this well. By now i've been calculating the entropy parameter with Shannon's expression (256 possible states) divide by 8. But the way it's handled in command line applications confuses me. So... what's the meaning of entropy? Or... how can i estimate it? The entropy parameter should tell, how much uncertainty is in the data provided. With 256 variations per byte you will find a certain number of possible states for 100bytes, but if the 100bytes are english text, not all of these possible states have the same probability. You will find a lot of e, , a and only few รถ symbols. Therefore the entropy is not the full amount but it is (much) lower. A good guess about the informational contents is the amount that is left after you run a compression algorithm over the data. You will e.g. find, that a typical maillog file can be compressed down to 10% of its original size (depending on the typical events loggted, of course). One would therefore account only 10% of the original byte count as entropy. If you have a phyisical source, you may be able to calculate the entropy available from this source by phyisical knowledge. When taking input from a computer you have to guess the number and the compression factor is one indicator. If we choose a value of 0, we mean that there may be entropy in it, but maybe an attacker can predict the value, so we use it but do not count it as a really unpredictable input. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RAND_add() and the entropy...
On Wed, Nov 14, 2001 at 10:59:57AM -0800, Michael Sierchio wrote: Lutz Jaenicke wrote: The entropy parameter should tell, how much uncertainty is in the data provided. If we choose a value of 0, we mean that there may be entropy in it, but maybe an attacker can predict the value, so we use it but do not count it as a really unpredictable input. So, if we know the entropy per character (byte) what's the correct formula for deriving the correct value for the entropy parameter? If the entropy is 10% (compress ration 1:10), the parameter is number of bytes * 10%. Please note again, that the compression ration is just the condensed amount of information in the message. If we don't know the message, it is more or less equivalent to the entropy (unpredictability) in it. If the message is known, the entropy (from the cryptographic point of view) is zero! It is therefore a difficult decision to finally estimate the entropy coming from the source with the compressed size being kind of an upper bound. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [patch] 0.9.6b: Allow loading of uninstalled shared libraries
On Mon, Oct 29, 2001 at 11:22:18PM +0100, Richard Levitte - VMS Whacker wrote: This was a very useful patch. However, I believe that either on AIX or HP-UX, the environment variable isn't called LD_LIBRARY_PATH, and the whole thing works a little bit differently. Remind me please, anyone? HP-UX (32bit) uses SHLIB_PATH and it is only used when the executable was linked with +s: this is useful for dynamic loading. For building executables against shared libraries it is normally not necessary to provide this information, as the path to the shared library is hardcoded at link stage. This of course requires special provisions when e.g. installing OpenSSL itself: when performing make, the shared libraries just generated are normally not yet installed and therefore the executable built will not have the correct path to find the shared libraries at runtime. Libtool therefore re-links the executables after installing the shared libraries at their final destination when performing a make install. OpenSSL would have to do the same thing when it is intended to install the openssl command line tool against the shared libraries. There are reasons, why the shlib/hpux10-cc.sh is looking somewhat complicated (besides building with +O4=optimization at link time)... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: function declarations with no parameter specifications
On Fri, Oct 19, 2001 at 12:42:50PM -0400, Jeremy Hylton wrote: I have recently taken over maintenance of Python's minimal SSL interface, which provides a few basic operations via the standard socket module. When I compile Python, I get many warnings from gcc about OpenSSL headers files -- all function declaration isn't a prototype. There are a lot of struct and function declarations that define function pointers without parameter specifications. These are problematic on several grounds, no least of which is the anal goal we have of making Python compile without any warnings :-). If the declarations were prototypes, it would also improve argument checking and coercion on subsequent calls. It would also make the code a bit easier to read. I did a cursory review of a few calls and found it hard to tell what the arguments to these functions should be. Is there any intent to make these function declarations into prototypes in a future version of OpenSSL? If I wanted to contribute patches, would that be a good idea? (or a bad idea either for technical or political reasons?) The time the OpenSSL team members can spend on the project is limited. If you can supply a patch, we will strongly consider applying it :-) Please only take care of the current development snapshot (0.9.7-dev). The development for 0.9.6c is more or less finished and for compatibility reasons we should leave this point as is. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: problem in s_client -- comments on fix?
On Tue, Oct 16, 2001 at 02:30:03PM +0100, Adam Back wrote: On Sun, Oct 14, 2001 at 06:19:30PM +0200, Lutz Jaenicke wrote: [...] * If you have any patch to submit that will improve the behaviour of s_client you are most welcome to post it to this list :-) OK, here you go, someone please apply this: diff -Naur apps/s_client.c apps/s_client.c --- apps/s_client.c Tue Oct 16 09:22:49 2001 +++ apps/s_client.c Tue Oct 16 09:22:01 2001 @@ -881,5 +881,7 @@ BIO_printf(bio,---\n); if (peer != NULL) X509_free(peer); +/* do this or debugging output gets mixed with http response */ + BIO_flush(bio); } Applied. Thanks, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: problem in s_client -- comments on fix?
On Sun, Oct 14, 2001 at 04:01:23PM +0100, Adam Back wrote: I tried parsing the output of s_client with some perl code I was writing, and I found that the connection information (cipher selection, certificate chain if you ask for it with -showcerts) gets mixed up with the HTTP response. What do you want to achieve? OpenSSL s_client is a test and demo program. If you want to seperate normal I/O and the connection information, the correct solution would be to use a seperate channel for the information. I didn't have a look into stunnel for quite some time. Maybe it is better suited to your needs, as it is intended for application and not for testing? Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: problem in s_client -- comments on fix?
On Sun, Oct 14, 2001 at 04:43:30PM +0100, Adam Back wrote: Either way though s_client's behavior is wrong, because even visually you can't _find_ the connection info mixed in with the HTTP response; my post was just to follow up having found the bug to fix the problem. The note about the application was just background of how I found it. For s_client's main purpose (command line manual testing), perhaps just the BIO_flush(bio) is all that's needed. Then please allow another statement: * I personally find s_client to be more or less unreadable :-( * OpenSSL 0.9.7 should be coming out in the very near future and I would not expect anything to change on this before 0.9.7 (and I am not aware of any statements to put work into an s_client cleanup anyway). * If you have any patch to submit that will improve the behaviour of s_client you are most welcome to post it to this list :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: verify(1) man page
On Fri, Oct 05, 2001 at 03:23:12PM -0400, Howard Lum -- Customer Engineering wrote: 1. Error codes 10 and 11 are reversed in the verify(1) man page. Will be fixed in a minute. 2. Lines in the verify(1) man page wrap to the *previous* line for error codes 2, 4, 5, 6, 7, 13, 14, 15, 16, 18, 19, 20, 21, 25, 30, 31, 32 and 50. I don't understand this statement. I just performed a man verify on my system (HP-UX 10.20) and could not see anything special. 3. In the file crypto/x509/x509_txt.c, the message Certificate has expired could be changed to all lower case for consistency with other messages. Will be fixed in a minute. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Compiling as shared library on HP-UX 11.XX
On Wed, Sep 12, 2001 at 11:06:27PM -0700, ratan wrote: I am including a patch to enable compiling openssl as a shared library on HP-UX 11.00 and 11.11. The patch has been tested two different HP compilers on both 11.00 and 11.11. If I understand your patch correctly, you have backported the shared library support from 0.9.7-dev to 0.9.6x? Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OPenSSL fails to accept certificate chains over 16K
On Sat, Aug 25, 2001 at 01:59:24PM +0200, Lutz Jaenicke wrote: I'll add it to the TODO list. If we change this to a dynamic limit, we could start with 16kB (platform independant) and then applications may decide at will. 16kB should be sufficient in most cases, because the construct was broken (see the original report) for quite some time, so that effectively 16kB was the limit, and the number of complaints was 0. Ok. I have just added SSL_CTX_set_max_cert_list() and friends to 0.9.7. It should show up in the next snapshot. It's default buffer sizes are as before: 100kB for all platforms except DOS/16bit (30kB). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] for 0.9.67b shared libraries on HPUX using GCC and native ld
On Sun, Sep 09, 2001 at 11:07:04PM +0800, Peter Farmer wrote: I have built openssl 0.9.6b on HPUX 10.10 10.20 with gcc and the native HP linker . [Detailed technical description deleted] Shared lib support for HP-UX has been integrated for 0.9.7. Please check out do_hpux-shared in Makefile.org and the corresponding entries in Configure. As the release of 0.9.7 is already looking over the horizon, we should go the 0.9.7 way. Best regards, Lutz 1. the HPUX linker doesnt have the capability to build shared libs (.sl) directly from archive libs (.a) There exists an undocumented -Fl option (at least on 10.20). -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: bug in OpenSSL ssl\s3_clnt.c: SSL handshake fails
On Mon, Aug 27, 2001 at 03:37:11PM -0700, Alex Bereznyi wrote: I stumbled on a bug in ssl\s3_clnt.c, line 855, in function ssl3_get_key_exchange(SSL *s) the limit on possible message size is hardcoded to 8K: n=ssl3_get_message(s, SSL3_ST_CR_KEY_EXCH_A, SSL3_ST_CR_KEY_EXCH_B, -1, 1024*8, /* ?? */ ok); while using the latest Apache and mod_ssl (Apache 1.3.17, Mod_SSL 2.8.0, OpenSSL 0.9.6) with SSLCipherSuite set to MEDIUM in Apache config, result in message size 9865 bytes, so SSL handshake fails with SSL_R_EXCESSIVE_MESSAGE_SIZE. The fix is trivial, just use 10K or more for the limit, I tested it - works fine. Latest 0.9.6b build still has this problem, I hope this fix will make it into next release. This problem has been fixed in the CVS tree on August 7, 2001 and the fix will therefore be part of the next release. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SunOS gcc build patch
On Fri, Aug 24, 2001 at 06:42:29PM -0400, Jeffrey Hutzelman wrote: The following simple patch to e_os.h works around a problem which prevents building OpenSSL with gcc on SunOS 4.1.x. This patch was generated against 0.9.6, but should also apply cleanly to OpenSSL 0.9.6b. Thanks, applied! Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OPenSSL fails to accept certificate chains over 16K
On Fri, Aug 24, 2001 at 06:31:56PM -0700, Doug Kaufman wrote: On Fri, 24 Aug 2001, Lutz Jaenicke wrote: On Thu, Aug 23, 2001 at 02:21:27PM -0500, Douglas E. Engert wrote: ! #if defined(MSDOS) !defined(WIN32) ! 1024*30, /* 30k max cert list :-) */ ! #else ! 1024*100, /* 100k max cert list :-) */ ! #endif Why are you setting this limit for MSDOS? You certainly don't need it for the DJGPP port. Is the limit specific to certain compilers? I don't know. This construction is in since the OpenSSL team took over from EAY... I'll add it to the TODO list. If we change this to a dynamic limit, we could start with 16kB (platform independant) and then applications may decide at will. 16kB should be sufficient in most cases, because the construct was broken (see the original report) for quite some time, so that effectively 16kB was the limit, and the number of complaints was 0. Let's see, whether more input comes to this topic. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OPenSSL fails to accept certificate chains over 16K
On Thu, Aug 23, 2001 at 02:21:27PM -0500, Douglas E. Engert wrote: A fix was introdued in OpenSSL-0.9.5 or so. This added the ssl3_check_client_hello routine to ssl/s3_srvr.c to check for a new client hello message when a certificate chain was expected. This introduced a bug, in that it limited the certificate chain to SSL3_RT_MAX_PLAIN_LENGTH rather then the original arbitrary 100K limit used in the ssl3_get_client_certificate routine. Here is a fix to OpenSSL-0.9.6 to have it use the 100K limit. *** ,s3_srvr.c Mon Sep 11 07:42:59 2000 --- s3_srvr.c Thu Aug 23 13:32:37 2001 *** *** 537,543 SSL3_ST_SR_CERT_A, SSL3_ST_SR_CERT_B, -1, ! SSL3_RT_MAX_PLAIN_LENGTH, ok); if (!ok) return((int)n); s-s3-tmp.reuse_message = 1; --- 537,547 SSL3_ST_SR_CERT_A, SSL3_ST_SR_CERT_B, -1, ! #if defined(MSDOS) !defined(WIN32) ! 1024*30, /* 30k max cert list :-) */ ! #else ! 1024*100, /* 100k max cert list :-) */ ! #endif ok); if (!ok) return((int)n); s-s3-tmp.reuse_message = 1; Hmm. Seems reasonable to me. ssl3_check_client_hello() was realized by Steve Henson. Steve: do you see any problem? As the 100K is an arbitrary limit, I would also like to see this changed so it is a parameter which could be set by the application. Although we don't currently have certificate chains over 100K with Globus, we could in the future. Sounds horrible. With certificates typically having a size of 1-2kB this would mean a chain length of ... And it also means that 100kB are on the wire even before any payload is handled... The SSLv3 specs don't set this limit, but rather allows 2^24 certificates. I understand the need to have some practical limit, but it should be setable by the application at run time. To be considered. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: 0819 snapshot problem
On Mon, Aug 20, 2001 at 03:18:44PM -0700, Rodney Thayer wrote: openssl 0819 snapshot doesn't compile -- ssl/ssl_stat.c had several places that case statements didn't have a : on the clauses. See references to character string 'TLS1'. Sigh. I did check in the version from the wrong directory. One better should not work on Sundays. (fixed) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/doc/ssl SSL_COMP_add_compression_method.pod ssl.pod
On Tue, Aug 21, 2001 at 08:55:44PM +0200, Richard Levitte - VMS Whacker wrote: jaenicke SSL_COMP_add_compression_method - handle SSL/TLS integrated compression methods jaenicke jaenicke =head1 SYNOPSIS jaenicke jaenicke#include openssl/ssl.h jaenicke jaenickeint SSL_COMP_add_compression_method(int id, COMP_METHOD *cm); Something to note is that the semantics, and possibly the syntax, will most probably change as soon as the actual compression identities have been standardised. That is the consequence of all the drawbacks the actual setup has... I will add an appropriate note tomorrow. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL_COMP_* API
Hi! While writing the manual page for SSL_COMP_add_compression_methods(): SSL_COMP_add_compression_methods() is defined in ssl.h (and is therefore a public part of the API). The counterpart SSL_COMP_get_compression_methods() is however only part of ssl_locl.h (and is therefore private). Does anybody have an idea on why this distinction is being made? It doesn't make sense to me. (If nobody has an idea on why it should not be public, I will make it public.) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Bug fixes for BIO_get_num_renegotiates() and BIO_get_write_buf_size()
On Thu, Aug 16, 2001 at 09:15:36AM -0500, Stephen Hinton wrote: This is the first patch I've submitted for OpenSSL. Feedback about what I did wrong (and what I did right) is appreciated. Well done. Patches have just been applied. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Return string typos in SSL_state_string_long()
On Mon, Aug 06, 2001 at 01:46:25PM -0400, [EMAIL PROTECTED] wrote: I found typos with return strings of SSL_state_string_long() (in ssl_stat.c). In the following cases, the last chracter of the return strings should be corrected to 'B'. - case SSL3_ST_CW_CERT_VRFY_B:str=SSLv3 write certificate verify A; break; case SSL3_ST_CW_FINISHED_B: case SSL3_ST_SW_FINISHED_B: str=SSLv3 write finished A; break; - These typos are left even in OpenSSL 0.9.6b. Thanks, has been fixed. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Want to use certs and keys in memory instead of file
On Tue, Jul 31, 2001 at 04:43:54PM -0400, Dilkie, Lee wrote: anyway, where is the documentation for the d2i functions? and I can't find anything on the SSL_CTX_use_certificate(), where should I be looking? there is no manual page for these functions, as far as I can tell, i must be missing something There is a manual page for SSL_CTX_use_certificate in my copy of OpenSSL. A manual page for d2i_X509 does not exist, but the handling of all d2i_* functions is similar, so you can use the description of d2i_SSL_SESSION. Good night, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem using SSL_set_verify with a callback
On Mon, Jul 30, 2001 at 11:58:34AM +0300, Ori Yosefi wrote: Thanks for the patch. It solved the problem alright. One problem that I found though: I am building openssl on Windows NT as a DLL. The SSLeay32 would complain that X509_STORE_CTX_set_verify_cb is an unresolved symbol. I added the following line to util/libeay.num: X509_STORE_CTX_set_verify_cb2467 EXIST::FUNCTION: and it solved the problem. I must admit that I'm not sure what the libeay.num does and if what I did is OK but at least empirically it works ;-) Please let me know if the addition to the libeay.num is OK. Good. I will inocorporate the patch to the release tree, when the libeay.num problem is solved. I don't have the slightest clue about the Windows building process, so I already contacted Richard Levitte this morning to find out how to handle the libeay.num thing the official way. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Want to use certs and keys in memory instead of file
This is a topic for openssl-users, but I am too lazy to redirect it now! On Fri, Jul 27, 2001 at 03:50:12PM -0400, Dilkie, Lee wrote: I want to include the ssl cert and private key (copied, pem, from the files) in my program as static variables (to avoid having files in my file-less application). I'm staring at SSL_CTX_use_certificate_file() and the other SSL_CTX_use* functions and I don't see an obvious one that would serve. I'm looking at the SSL_CTX_use_certificate_file function itself and I see that it uses a file BIO and calls PEM_read_bio_X509() to decode the PEM into an x.509 structure which is passed to SSL_CTX_use_certificate(). I suppose I could duplicate the whole function but use a memory bio instead but I was wondering if any of youse folks out there have a better (simplier) way? Please use line breaks to improve readibility. Please check out the manual page for SSL_CTX_use_certificate(). The context of the certificate file in nothing else than the ASN1 representation of the X509 object. You can take this data and put it as an array into your program (-C option of openssl X509), then you can use the d2i_X509() function to transfer the contents of this array into the X509 and load it using SSL_CTX_use_certificate(). (OpenSSL rsa does not have a -C option, so transferring it into an array is left as an exercise to the reader :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: how to add info to SSL SESSION PARAMETERS?
On Thu, Jul 26, 2001 at 07:35:05AM -0400, Jeffrey Altman wrote: In order to allow the RFC 2712 Kerberos support in 0.9.7-dev to work with cached sessions I need to save the contents of the KSSL_CTX structure with the SSL SESSION PARAMETERS. Should this be added to the ssl_session_st structure? Yes. For software everything that it needed for caching is inside the SSL_SESSION structure (=ssl_session_st). Therefore if the contents of KSSL_CTX (or part of it) is needed, it should be added into this one thing. As you can see from the manual pages (e.g. SSL_CTX_sess_set_get_cb), there exists an interface to the external session cache. I would like to keep this transparent. Everything that is needed to reuse a session should be part of SSL_SESSION, so that the external session cache routines don't have to bother about it. This also means that d2i/i2d_SSL_SESSION() have to be extended to save the additional information. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug Report dsa_lib.c OpenSSL 0.9.6x on Solaris 2.6 and 8
On Thu, Jul 26, 2001 at 02:02:06PM -0500, Scott Burch wrote: Please read through the entire contents of this message. I included the entire discussion because I thought it would help clarify things. ... For the information of the audience not reading openssh-unix-dev: A fix for this problem has already been checked in this morning. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem using SSL_set_verify with a callback
On Thu, Jul 26, 2001 at 07:00:01PM +0300, Ori Yosefi wrote: I've been trying to write a server application that for some resources requests a client certificate from the user. I call SSL_CTX_load_verify_locations and SSL_CTX_set_client_CA_list before starting listening on the socket and then analyze the requests and for some requests I call SSL_set_verify with a callback function (with mode SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE). I then call SSL_renegotiate to actually request the certificate. I see that the connection is indeed renegotiated and that a client certificate is requested by the server. I also see that the server receives the client certificate (both through step debugging and through the info callback) but my call back function is never called. Had I used the SSL_CTX_set_verify with a callback function before starting the connection the callback function would have been called. Does this sound familiar to anyone? Is there a way to renegotiate a connection for client certificates and get a callback on a per connection basis (as opposed to a per context basis)? I just had a look into the source. On the first glance it seems, that the X509_STORE of SSL_CTX, that holds all information about the verification environment, is directly used for the verification in ssl/ssl_cert.c:ssl_verify_cert_chain(). In this X509_STORE the verify_callback of the SSL_CTX is being used. The verify_callback you supplied to the SSL object is stored into the object, but it is actually never used. This seems to be a bug :-) I'll have to go through this again to make sure that I did not miss anything and then consider the best strategy to solve this problem. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: dsatest problem (error 0A071003) while testing openssl (both 0.9.6a and 0.9.6b)
On Tue, Jul 24, 2001 at 06:56:36PM -0700, Janke Dรกvid wrote: I'm trying to build openssl now for about three weeks, read all main faq-s and lists where I could find something about it, but I still have that problem. It is that there's no problem while compiling openssl, but every time I test it, it sais the following: (make pid):error:0A7071003:dsa routines:DSA_do_verify:BN lib:dsa_ossl.c:305 Does anyone have an idea? Yes. At least post your operating system and compiler information :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Possible bug in openssl 0.9.6b
On Sun, Jul 22, 2001 at 05:57:21AM +, a y wrote: HMTL-gibberish... This indicates that there is a b missing in an `fopen(...,w)' that should read `fopen(...,wb)', such that a LF is transformed to CR/LF. I suppose you are running OpenSSL on a Windows platform. Before I start tracing through it: are you already using the latest version and/or can this problem be reproduced with it? Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: session resumption and bad mac
On Sun, Jul 22, 2001 at 01:05:32PM -0700, Tom Vaughan wrote: We've researched this[1] problem further and have found that on occasion, in the Server Hello, in response to a request to resume a session, the MAC is bad. We've now seen this problem with both IE and Netscape. This appears to only happen when MD5 is used. When SHA-1 is used, this problem disappears. Would anyone happen to know if there is a problem in OpenSSL version 0.9.5a that would be causing this? [1] http://marc.theaimsgroup.com/?l=openssl-devm=99542027232224w=2 At least there is nothing in the CHANGES that would indicate that it is fixed in later versions... Reading this ethereal printout is a bit hard. Can you supply the dump in tcpdump binary format so that it can be further processed e.g. with ssldump? Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Possible bug in openssl 0.9.6b
On Mon, Jul 23, 2001 at 11:20:17AM +0200, Lutz Jaenicke wrote: On Sun, Jul 22, 2001 at 05:57:21AM +, a y wrote: HMTL-gibberish... This indicates that there is a b missing in an `fopen(...,w)' that should read `fopen(...,wb)', such that a LF is transformed to CR/LF. I suppose you are running OpenSSL on a Windows platform. Before I start tracing through it: are you already using the latest version and/or can this problem be reproduced with it? Hmm, I have just seen that the version number (0.9.6b) is in the subject. Following the code in openssl/crypto/bio/bss_file.c: ... case BIO_C_SET_FILENAME: ... #if defined(MSDOS) || defined(WINDOWS) if (!(num BIO_FP_TEXT)) strcat(p,b); else strcat(p,t); #endif ... The input/output files of base64 are opened without any flag and with the correct flags (b), when MSDOS or WINDOWS is defined. I therefore have to assume, that your problem is related to your platform and/or specific installation. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: No shared cipher sslv3 alert handshake failure
On Mon, Jul 23, 2001 at 09:29:26PM +0900, Kukmin, Han wrote: I am programming the simple Server-Client message exchange program using OpenSSL. but i encountered this error message. Error message : Server SSL_ERROR_SSL, error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher Please check out the SSL_CTX_set_cipher_list manual page (use the online version at http://www.openssl.org/docs/ssl/SSL_CTX_set_cipher_list.html, as I have just updated the information with respect to this error message). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: shared library versioning
On Mon, Jul 23, 2001 at 03:36:22PM +0200, Hans Werner Strube wrote:
OpenSSL version: 0.9.6b 9 Jul 2001
platform: solaris-sparcv8-cc
This concerns not an actual bug in compilation or function but an annoying
deviation from the standards of shared library versioning. All the bugfix
subversions of 0.9.6{,a,b} have the same extension lib...so.0.9.6 but are
not replaceable because of the builtin check for OPENSSL_VERSION_NUMBER.
Normally, equal extensions indicate compatibility (at least with respect to
library updates), i.e., the newer version contains all the globals and
functions of the older one with the same semantics and argument types. This
is probably the case between 0.9.6a and 0.9.6b; at least the names of the
globals and functions are identical. Then programs built with (e.g.) 0.9.6a
should not have to be recompiled when the shared library is replaced with
0.9.6b (but with the same extension); but actually, the new library refuses
to work with the programs due to the internal check. If, however, the
libraries are indeed not compatible in the above sense, they should have
different version extensions.
Your complaint is half-correct.
It is incorrect in the sense that shared library support before 0.9.7 (not
yet released) is called experimental. So we don't give any guarantee on
behaviour or compatibility.
It is correct in the sense that using the same name (0.9.6) for different
versions, that are not binary compatible, does not make sense.
We'll have to keep this in mind for the 0.9.7 and later versions.
Unfortunately most public-domain software does not treat shared library
versioning correctly. It should be a general philosophy to keep compatibility
(and thus, same extension numbers) as long as possible. Internal checks
(or alternatively, Solaris's internal versioning) should only reject
attempts of incompatible downgrading to an older library with the same
version extension but fewer globals and functions.
I agree with this general philosophy. The development of OpenSSL however
will require further changes of data structures so please don't expect
binary compatibility coming soon.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: reading in DSA private key problems....
On Wed, Jul 11, 2001 at 10:59:03AM -0400, Mark W. Webb wrote: when I run this command, why does the private key file say that it is a RSA private key? This is the command that I am using. openssl req -inform DER -outform DER -out marktest.cert -keyout marktest -newkey dsa:deleteme.param -keyform DER -new -x509 -nodes Because the -new overrides the -newkey option. -new has RSA hardcoded and as it is processed later in the list, its setting gets preference. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: reading in DSA private key problems....
On Wed, Jul 11, 2001 at 02:27:12PM -0400, Mark W. Webb wrote: Do you have any insight as to how and read in public and private DSA keys from files that are DER encoded? Hmm. SSL_CTX_use_PrivateKey_file() and SSL_CTX_use_certificate_file() should be sufficient. man SSL_CTX_use_certificate Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Error message: random number generator:SSLEAY_RAND_BYTES / possible solution
Count to twenty before answering... On Mon, May 07, 2001 at 09:58:54AM -0500, Hynds, R Michael wrote: Since the error message was specific I thought I'd take a look at the indicated module (../openssl-0.9.6a/crypto/rand/md_rand.c). It seems that the variable ok was set to zero. Working my way down the function I found ok = (entropy = ENTROPY_NEEDED); The following statement checked the value of ok. I noticed that the if statement didn't modify ok back to one. I added ok=1; after line 378 and things seemed to work okay. After this I built Apache with mod_ssl and everything seemed to work. My question is: is the above code change solve the problem or did I just solve a symptom?. The check you just set out of effect is there for a very good reason. It shall ensure that only when enough entropy was added (entropy = ENTROPY_NEEDED), random number can be generated. If the PRNG is not sufficiently seeded, your cryptographic keys are weak and can be (easily!?) broken, therefore the OpenSSL library insists on sufficient seeding. Please check out the mod_ssl documentation about the SSLRandomSeed directive. There or in the OpenSSL FAQ you will find, that on AIX you'll probably have to use EGD or PRNGD, as no /dev/urandom device is available. With respect to the key generation, I don't know whether the mod_ssl build process supports specification of an entropy source. In any case you can use the openssl rand command to generate a $HOME/.rnd file that will be used as a backup entropy source for openssl genrsa. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_CTX_use_PrivateKey_file(...) fails
On Mon, Apr 23, 2001 at 07:41:11PM -0400, Guy Sagy wrote: ... pass = password; SSL_CTX_set_default_passwd_cb( pSSLContext, password_cb ); if ( !( SSL_CTX_use_PrivateKey_file( pSSLContext, servkey.pem, SSL_FILETYPE_PEM ))) ... But the function call SSL_CTX_use_PrivateKey_file(...) above fails internally inside pem_lib.c , on line 451 , line PEMerr(PEM_F_PEM_DO_HEADER,PEM_R_BAD_DECRYPT) . Hmm. I just had a look into the source and would guess, that something is odd with the passphrase. Unfortunately you do not supply your password_cb. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Cannot make
On Thu, Apr 19, 2001 at 02:02:25PM +0700, Tom Zuurbier wrote: I am unable to make/compile openSSL on a HP9000 A400 system. See the Testlog file for more details. This isn't a bug in OpenSSL. OpenSSL requires an ANSI C compiler. Target: hpux-cc Compiler: (Bundled) cc: NLSPATH is /usr/lib/nls/msg/%L/%N.cat:/usr/lib/n ls/msg/C/%N.cat: (Bundled) cc: CCOPTS is not set. (Bundled) cc: INCLUDIR is INCLUDIR=/usr/include You only have the bundled KR compiler that is sufficient to compile the kernel but not to compile applications. You must buy HP's unbundled ANSI C compiler or install gcc. gcc for HP-UX 11 is available for free from HP's download site at http://devresource.hp.com/. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL IV and -K oddness
On Fri, Apr 13, 2001 at 11:04:46PM -0500, Andy Brown wrote: I believe I've found a bug with the UNIX command-line "openssl enc" utility. If you specify the hex key (with -K) on the command line, the IV is some randomish garbage, probably whatever happens to be in memory. I have run some tests on HP-UX and Linux. I think I could reproduce your tests. (On HP-UX the IV is 0, but that may just be a coincidence.) I had a glance over the source and it seems indeed, that on the stack the two arrays "salt" and "iv" are defined but if I didn't miss anything, then their initialization to 0 is nowhere enforced... I have never dealt with the "openssl enc" command so I'll have to look into it deeper before actually realizing a change. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Handshake Failure with some ciphers
On Thu, Apr 12, 2001 at 11:18:25AM -0600, Verdon Walker wrote:
This is very true, but in the case I am testing both sides are running the exact
same version of openssl.exe. (One side as the server and one as the client.)
Certainly, the same version of openssl.exe should be supporting the same cipher
suites, shouldn't it?
From the "compiled in" point of view, yes.
However: for a cipher to be usable, the cipher must be compiled in _and_
the necessary certificates must be present. So for cipher with RSA
authentication, a RSA certificate must be present on the server side,
for a cipher with DSA authentication, a DSA certificate must be present
on the server side. All DSA ciphers and some RSA ciphers (with EDH)
also do need DH parameters. Openssl s_server has built in DH-parameters,
so the last point cannot be your problem.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] OpenSSL 0.9.6a Beta 3 released
On Fri, Mar 30, 2001 at 10:45:06PM +0200, Richard Levitte wrote: openssl-0.9.6a-beta3.tar.gz openssl-engine-0.9.6a-beta3.tar.gz The next (hopefully real) release is scheduled for Tuesday 2001-04-03. To make sure that it will work correctly, please test this version (especially on less common platforms), and report any problems to [EMAIL PROTECTED]. Passed (normal and engine) on HP-UX 10.20 with both HP ANSI-C and gcc-2.95.2. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [BUGS] Various bugs with PG7.1 8th March snapshot on Solaris 8INTEL
On Wed, Mar 28, 2001 at 11:17:45AM +0200, Richard Levitte - VMS Whacker wrote: From: Justin Clift [EMAIL PROTECTED] jclift Just wondering if this problem has been solved? i.e. no conflicting jclift des_encrypt() definition on Solaris, Unixware, etc? It hasn't been solved yet. My current thinking is that the OpenSSL variant should be renamed to something like des_encrypt1(). This leads to the question if there's anyone out there using the OpenSSL variant of des_encrypt() directly. If so, I'd like to know, and I'm sure those who do use it directly would like to know about any changes :-). I did not check the details, but at least cyrus-sasl uses the DES part of OpenSSL, if found. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: your mail
On Tue, Mar 27, 2001 at 01:56:03PM +0200, [EMAIL PROTECTED] wrote:
while creating a new private key , i give a password, and later i create a
request and a certificate according to it.
is there a way for me to change the passowrd without recreating the ca or
the privatekey?
Provided you know the old passphrase, you can use the "openssl rsa" command
to modify passphrases.
If you have lost or forgotten the old passphrase, you of course cannot
recover the key (otherwise we could stop working on cryptography :-).
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: your mail
On Tue, Mar 27, 2001 at 02:16:51PM +0200, [EMAIL PROTECTED] wrote: ok since u have answered me so kindly (and so fast) I will ask u several more questions hoping u will clarify the fog: when I create a request and a private key (using req -keyout ...) I get a req and an encrypted private key (with password) after I use the rsa command with the old password (to remove pass phrase) do I have an un encrypted key and if so will another rsa command will encrypt it again ? Please read the manual page. You will find the "-des", "-des3", "-idea" switches that set the new encryption (or none when not specified). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: problem compiling openssl-0.9.6-beta2 on HP-UX 11.00
On Thu, Mar 22, 2001 at 07:57:27AM +0100, Heiko Nardmann wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I configured openssl-0.9.6-beta2 according to the following configure line: ./Configure threads --prefix=/opt/openssl-0.9.6a-beta2 - --openssldir==/opt/openssl-0.9.6a-beta2 hpux-parisc-cc During compilation of it I got the following error: cc -I.. -I../../include -DTHREADS -D_REENTRANT -DDSO_DL +O3 +Optrs_strongly_typed +Olibcalls -Ae +ESlit -DB_ENDIAN -DBN_DIV2W - -DMD32_XARRAY -c dso_dl.c cc: "dso_dl.c", line 98: warning 604: Pointers are not assignment-compatible. cc: "dso_dl.c", line 126: error 1589: "len" is not a function. cc: "dso_dl.c", line 126: error 1537: Illegal operand type for +. *** Error exit code 1 Verified. The bug was introduced between beta1 and beta2. On line 126, len = strlen(filename) + len(extension); the second "len()" is obviously wrong and should be strlen(). The warning on line 98 seems to be caused by a longint conflict in the return types. I'll investigate further and check in a fix. Many thanks, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: problem compiling openssl-0.9.6-beta2 on HP-UX 11.00
On Thu, Mar 22, 2001 at 10:07:36AM +0100, Lutz Jaenicke wrote: cc -I.. -I../../include -DTHREADS -D_REENTRANT -DDSO_DL +O3 +Optrs_strongly_typed +Olibcalls -Ae +ESlit -DB_ENDIAN -DBN_DIV2W - -DMD32_XARRAY -c dso_dl.c cc: "dso_dl.c", line 98: warning 604: Pointers are not assignment-compatible. cc: "dso_dl.c", line 126: error 1589: "len" is not a function. cc: "dso_dl.c", line 126: error 1537: Illegal operand type for +. *** Error exit code 1 Verified. The bug was introduced between beta1 and beta2. On line 126, len = strlen(filename) + len(extension); the second "len()" is obviously wrong and should be strlen(). The warning on line 98 seems to be caused by a longint conflict in the return types. I'll investigate further and check in a fix. Fix has been applied and commited to the repository. make test now passes again for HP-UX 10.20 with HP ANSI C as well as gcc-2.95.2 for both normal and engine version. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: another crash on SSL_connect
On Wed, Mar 21, 2001 at 11:01:52AM -0600, Brajesh Tiwari wrote: I am geeting a crash on SSL_connect. Can any one help me, please. Read the documentation on how to compile a program with debugging support. 0 0x3ff81549cec in UnknownProcedure0FromFile22(0x1201feba8, 0x140086a40, 0x4, 0x1401c2023, 0x3ffc0087f20, 0x20002) I'll unpack my glass ball, maybe it tells me more than UnknownProcedure0FromFile22 DebugInformationStrippedFromFile22 How do you expect to debug the program without debugging information? #1 0x3ff814856a8 in malloc(0x3ffc0087f20, 0x20002, 0x1201f4540, 0x18, 0x140072cd0, 0x14008c968) DebugInformationStrippedFromFile22 Based on this line I will give you a guess: failures when calling malloc() and friends typically occur when the administrative structures are damaged by writing over boundaries or writing to already free()ed locations. In these cases a malloc-debugger like efence might help. Best regards, Lutz #2 0x1201f453c in CRYPTO_malloc(0x1201ff564, 0x0, 0x1401ba090, 0x1200a01f0, 0xe9, 0x3ffc0087f20) DebugInformationStrippedFromFile3165 #3 0x1201ff560 in X509_NAME_ENTRY_new(0x3ff81487db8, 0x140086980, 0x40, 0x70, 0x1201feba8, 0x140086a40) DebugInformationStrippedFromFile3179 #4 0x1201febfc in d2i_X509_NAME_ENTRY(0x1201f3078, 0x140086a70, 0x12021cf08, 0x1401c20a2, 0x1401ba090, 0x1200a2c98) DebugInformationStrippedFromFile3179 #5 0x12021d06c in d2i_ASN1_SET(0x29, 0x1401c20cb, 0x1201ff1dc, 0x140086818, 0x1401ba1f0, 0x1401c2045) DebugInformationStrippedFromFile3226 #6 0x1201ff24c in d2i_X509_NAME(0x4a, 0x1401c220d, 0x1401c20a0, 0x1401ba1f0, 0x1401ba1f0, 0x1401c2036) DebugInformationStrippedFromFile3179 #7 0x120219578 in d2i_X509_CINF(0x1c8, 0x1401c225f, 0x1401c2045, 0x1401ba268, 0x1401ba2f0, 0x1401c2026) DebugInformationStrippedFromFile3220 #8 0x1201f0530 in d2i_X509(0x1, 0x235, 0x1401c225f, 0x1401c202a, 0x1401ba2f0, 0x19000) DebugInformationStrippedFromFile3157 #9 0x1201e414c in UnknownProcedure5FromFile3144(0x1401c2026, 0x1, 0x1400bd100, 0x, 0x140087490, 0x23f) DebugInformationStrippedFromFile3144 #10 0x1201e315c in ssl3_connect(0x1, 0x1401ca002, 0x16, 0x1220, 0x82, 0x3ab8dcbb) DebugInformationStrippedFromFile3144 #11 0x1201d582c in SSL_connect(0x16, 0x1220, 0x82, 0x3ab8dcbb, 0x1201dde60, 0x1400bd100) DebugInformationStrippedFromFile3133 #12 0x1201dde5c in UnknownProcedure4FromFile3138(0x1201dd5d0, 0x1400bd100, 0x0, 0x1210, 0x1220, 0x24a00010316) DebugInformationStrippedFromFile3138 #13 0x1201dd5cc in ssl23_connect(0x1400bd880, 0x1400bd100, 0xc1, 0x0, 0x0, 0x3ab8dcbb) DebugInformationStrippedFromFile3138 #14 0x1201d582c in SSL_connect(0xc1, 0x0, 0x0, 0x3ab8dcbb, 0x1200cfb18, 0xa) DebugInformationStrippedFromFile3133 #15 0x1200cfb14 in acceptor::_decifer(buffer=0x14008d000="20199.245.204.15:443:1011@Sky Tel029Wed, 21 Mar 2001 16:50:31 GMT00201015N:BriAndOneTest015ADR:;;;123;00;;017TEL;PAGE", fd=9, threadId=3) /usr2/users/bri/s_client/src/acceptor.cxx:2045 #16 0x1200c6f98 in acceptor::_process(src=0x1400e5a60) /usr2/users/bri/s_client/src/acceptor.cxx:149 #17 0x3ff805954f8 in __thdBase(0x0, 0x0, 0x1, 0x45586732, 0x4, 0x0) DebugInformationStrippedFromFile106 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problems with SSL_write ..
Moved to openssl-users... On Thu, Mar 15, 2001 at 08:51:07PM -0800, MANDALEEKA,LAKSHMI (HP-Cupertino,ex1) wrote: ... nBytesSent = SSL_write(m_pSSL, (pszBuf[nOffset]), nBytesToSend); if (nBytesSent 1) break; If (nBytesSent 0) n bytes were sent; If (nBytesSent == 0) connection was closed with SSL shutdown alert (clean close); else call SSL_get_error() and check the error stack to find out what is going on; man SSL_get_error, ERR_get_error. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] OpenSSL 0.9.6a Beta 1 released
On Tue, Mar 13, 2001 at 10:15:24PM +0100, Richard Levitte - VMS Whacker wrote: From: Lutz Jaenicke [EMAIL PROTECTED] Lutz.Jaenicke Hmm. The DSO code was considerably changed for the Lutz.Jaenicke 0.9.7 version and changes are not completed yet Lutz.Jaenicke (additional security aspects must be considered with Lutz.Jaenicke respect to the search path). Lutz.Jaenicke The 0.9.6a is only intended to fix bugs and especially Lutz.Jaenicke should not break existing functionality, therefore Lutz.Jaenicke you'll have to wait for 0.9.7 for the improved DSO Lutz.Jaenicke handling. On this particular point, it shouldn't be too hard to integrate change 1.11 of dso_dl.c, and that would hardly break existing functionality, and at least make OpenSSL operate in a consistent way over all Unixly platforms (since it doesn't prohibit the use of LD_LIBRARY_PATH on all other platforms). Thoughts? The change in question is 1.10: On HP-UX, shared libraries are normally called ".sl" and versions before 1.10 use ".so" as used on most other platforms. 1.11 addresses part of the search path problem, the other part is in the +s switch to honor SHLIB_PATH. (We don't want SHLIB_PATH since we cannot control what files the dynamic loader will take, at least or especially not for suid programs!) 1.10 breaks existing functionality, since once ".sl" is used, ".so" crypto engines will not be loaded any longer (and they were loaded with 0.9.6 as ".so"). So for a "bug fix release" I would rather say leave it the way it is and then have the change in 0.9.7. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] OpenSSL 0.9.6a Beta 1 released
On Tue, Mar 13, 2001 at 10:56:44PM +0100, Richard Levitte - VMS Whacker wrote: From: Lutz Jaenicke [EMAIL PROTECTED] Lutz.Jaenicke 1.10 breaks existing functionality, since once ".sl" is Lutz.Jaenicke used, ".so" crypto engines will not be loaded any Lutz.Jaenicke longer (and they were loaded with 0.9.6 as ".so"). But since shared libraries on HP-UX are normally named libfoo.sl (as it is for libswift and ncipher!), wouldn't requiring libfoo.so be considered a bug? It feels like users of OpenSSL have to go to unnecessary lengths to get it working... It is a bug. If you want to change it for 0.9.6a, it is probably not a big problem. The number of people experiencing failure should be small because most people will not move the .sl to .so for 0.9.6 (old) but rather create a link, so that that both extensions would work. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Session reuse on client side when the session runs SSLv2 fails
On Thu, Mar 01, 2001 at 07:23:04PM +0100, Richard Levitte - VMS Whacker wrote: The printout will be: 28:error:140750DD:SSL routines:SSL23_CONNECT:ssl23 doing session id reuse:s23_clnt.c:132: ... or something very similar. The reason for all this is actually that ssl23_get_method() (which is called downstreams from SSL_set_session()) in s23_meth.c will return the result of SSLv23_method() when presented with SSL2_VERSION as input argument, while it will give the results from SSLv3_method() and TLSv1_method() for SSL3_VERSION and TLS1_VERSION respectively. What happens next is that ssl23_connect() is called with an SSL in the state SSL_ST_CONNECT|SSL_ST_BEFORE. The first thing that is checked is if there's a session connected to the SSL, and if there is, the error given above is signaled. Unless someone tells me the behavior of ssl23_get_method() is correct visavi SSLv2, I'll change it ro return the result of SSLv2_method(). I have read through the locations you name and come to the same conclusion you already posted. SSLv23_method() is a generic method that is called if it is not clear yet, which protocol to use. (So it is consistent that if you already know which protocol to use, you don't call the generic one and the error flagged is correct.) The (needed) fix should have one side effect (from conclusion, I did not try it): Since the SSL_connect() is now performed with SSLv2 only, in case the session cannot be reused, the new session will also be of type SSLv2, even if both the server and the client could do better. +1 to change this in both current and stable. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Session reuse on client side when the session runs SSLv2 fails
On Fri, Mar 02, 2001 at 12:30:05PM +0100, Richard Levitte - VMS Whacker wrote: From: Lutz Jaenicke [EMAIL PROTECTED] Lutz.Jaenicke The (needed) fix should have one side effect (from Lutz.Jaenicke conclusion, I did not try it): Since the SSL_connect() Lutz.Jaenicke is now performed with SSLv2 only, in case the session Lutz.Jaenicke cannot be reused, the new session will also be of type Lutz.Jaenicke SSLv2, even if both the server and the client could do Lutz.Jaenicke better. Hmm, isn't this true for SSL3 and TLS1 as well? I'm not that good at finding my way in the SSL-specific code yet so I may very well be missing something. Yes, that should be true as well. The difference is in that the use of SSLv2 is deprecated and SSLv3 or TLSv1 should be used. If I already have SSLv3 or TLSv1 negotiated, I don't care to keep it. Of course, this debate is more or less academic, since a SSLv2 session that has once been negotiated was negotiated for a reason, so probably both peers would not negotiate something different in the next attempt (if not a configuration change to place in between). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/ssl s23_meth.c
On Fri, Mar 02, 2001, [EMAIL PROTECTED] wrote: levitte 02-Mar-2001 13:17:58 Modified:ssl s23_meth.c Log: For SSLv2, return the SSLv2 method, not the SSLv23 method. This way, it's possible to reuse an SSLv2 session. You did not apply this change to the stable tree, the bug should also affect it. Maybe the change should also be recorded to the changelog. Best, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: How to start SSL
On Thu, Feb 22, 2001 at 11:48:55AM +0100, Pamarthi Venkata Naga Vara Prasad wrote: We hv installed Apache 1.3.17 and Open SSL 0.9.5 A on HPUX 10.20 server. We are able to start Apache server and is running with out any problem. But we dont know how to strat SSL. Could you pls tell us how to start SSL on HPUX 10.20 server. Dear Sir, openssl-bugs is definetly the wrong mailing list to ask these questions. To enable SSL with Apache, two products are available: Apache+SSL and mod_ssl. Both are listed in the related projects section at www.openssl.org. Both come with instructions on installation and use. Sincere regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/rand rand_egd.c
On Thu, Feb 08, 2001 at 03:04:57AM +0100, Ulf Moeller wrote: So, which RAND_egd functions (if any) do we want to document in RAND_egd.pod? All of them? RAND_egd(path) will query 255bytes and seed the PRNG. RAND_egd_bytes(path,bytes) will query a chosen number of bytes and seed the PRNG. RAND_egd() is the interface proposed by now, but 255 bytes is more than is actually needed and might load EGD more than necessary. For a symmetric key depending on the strength we need around 20 bytes (which is the default for ENTROPY_NEEDED), so application developpers may choose to query ... 32 bytes like e.g. used in OpenSSH per connection. As it seems to me RAND_egd_bytes() is not well known but it was added quite some time ago (by Ben, if memory serves me right). RAND_query_egd_bytes() is used internally to access the EGD and return the bytes. I was considering to make it publicly accessable. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Session cache size question
Hi!
I am currently writing the documentation for the session caching and while
researching in the code I found the following:
ssl.h:
#define SSL_SESSION_CACHE_MAX_SIZE_DEFAULT (1024*20)
ssl_sess.c:
...
if (SSL_CTX_sess_get_cache_size(ctx) 0)
{
while (SSL_CTX_sess_number(ctx)
SSL_CTX_sess_get_cache_size(ctx))
{
if (!remove_session_lock(ctx,
ctx-session_cache_tail, 0))
break;
else
ctx-stats.sess_cache_full++;
}
}
...
With SSL_CTX_sess_number being
ssl_lib.c:
case SSL_CTRL_SESS_NUMBER:
return(ctx-sessions-num_items);
This means that the default session cache size is more than 2 sessions..
(With client certificates a session can easily be more than 1kb, so I am
talking about 20MB. Yes, I am aware that it might be pretty tough to establish
2 sessions in the first place :-)
Did I miss something?
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: UPDATE - Problem installing Openssl on HP-UX
On Fri, Jan 26, 2001 at 03:21:26PM +, [EMAIL PROTECTED] wrote: I have investigated further and got a clean compile by changing -O3 to -O1 for CFLAG in the Makefile, so it looks like an optimizer problem on my machine. I'd still appreciate confirmation of this, and advice on whether or not the above change will cause a problem. If others have the same problem, maybe this work gcc -I.. -I../../include -DTHREADS -DDSO_DL -D_REENTRANT -O3 -DB_ENDIAN -DBN_DIV2W -c bn_asm.c gcc: Internal compiler error: program cc1 got fatal signal 11 ... $ gcc -v Reading specs from /usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.8.1/specs gcc version 2.8.1 If I remember correctly, gcc 2.8.x is considered to be buggy and in a lot of packages you will find hints to avoid this version at all. I had been using gcc-2.7.x until recently without too much problems and have now updated to 2.95.2 and it also works. I strongly recommend you to get rid of gcc-2.8.1 and install 2.95.2 instead. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Peer certificate in SSL_SESSION structure.
On Wed, Jan 24, 2001 at 09:45:53AM -0800, Geoff Thorpe wrote:
A "standard" (eg. RC4-SHA, 1024-bit RSA, no client-authentication) SSL
session typically encodes to around 130-150 bytes. Introduce
client-certificate authentication into the picture (with no cert-chains,
just a single CA-signed client cert for 1024-bit RSA) and the sessions can
go up around the 1K mark (the certificate components/fields can determine
the actual encoding length which is why I had a slight but disastrous
variance between two different test certs). Introduce client cert chains,
and ... well ... you get the picture. This is one of the reasons that it
OpenSSL only stores the peer's certificate but not the rest of the chain.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Peer certificate in SSL_SESSION structure.
On Mon, Jan 22, 2001 at 04:41:41PM -0800, Nagaraj Bagepalli wrote: Thanks for your response. If I understand this correctly, certificate is stored in the session table so that application can retrieve it in the resumed connections (in case it needs it), but from the ssl protocol point of view client certificate is not used any where other than establishing the new session.. No, it is not used in the handshake again (that's why it must be kept inside the stored session). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Peer certificate in SSL_SESSION structure.
On Tue, Jan 23, 2001 at 10:51:27AM +, Ben Laurie wrote: Lutz Jaenicke wrote: On Mon, Jan 22, 2001 at 04:41:41PM -0800, Nagaraj Bagepalli wrote: Thanks for your response. If I understand this correctly, certificate is stored in the session table so that application can retrieve it in the resumed connections (in case it needs it), but from the ssl protocol point of view client certificate is not used any where other than establishing the new session.. No, it is not used in the handshake again (that's why it must be kept inside the stored session). IIRC the client certificate is _not_ stored in the session (at least, it used not to be - Apache-SSL has to work around this in its own caching). At least in actual versions it is stored. I don't know whether this feature is missing in older versions, but Postfix/TLS uses this feature (disk based session caching) since September 1999. Just checked the CVS archive, i2d_SSL_SESSION handles the peer since 1.1 (the initial OpenSSL check in dated Dec 21, 1998). There was/is a bug with respect to the verify_result: In older versions, the certificate was stored but is verified again, when reused. Due to the default setting, verify_result became X509_V_OK in any case for reused sessions... * For the server side this bug was fixed in 0.9.5. * For the client side this bug is still present in 0.9.6 but has been fixed in CVS and will hence be fixed in 0.9.7 (or 0.9.6a if/when released). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Peer certificate in SSL_SESSION structure.
On Mon, Jan 22, 2001 at 09:11:04AM -0800, Nagaraj Bagepalli wrote: Peer certificate is stored in the SSL_SESSION structure, is peer certificate required any where during short handshake negotiation phase (resumed connections)? I was under the impression that certificates are used only during the new session creation and for the resumed connections master secret along with the randoms are sufficient for generating the keys, can someone please explain why certificates are being stored in session table? The peer certificate is stored inside the session table so that you can call SSL_accept(ssl); SSL_get_peer_certificate(ssl); and get the certificate of the peer for the session actually being used. Depending on the peer's certificate (identity) different levels of permission might be granted. Best regards, Lutz PS. Don't forget to call SSL_get_verify_result(ssl) ... to check whether the certificate passed verification... -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: need documentation on sha hashfunction
On Sun, Jan 21, 2001 at 06:38:31PM +0100, Arnim Kreutzer wrote: hi there, I need some documentation on the implementation of the sha hashfunction in eay library. difference between HASH_BLOCK_HOST_ORDER and HASH_BLOCK_DATA_ORDER? e.g. background: I have to add verbose functionality to the sha1 for a project at the university, but it's very hard to understand the implementation ... I don't know whether this helps, but there are other SHA1 implementations out there. For another project (prngd) I have used the one included in the mhash library (which obviously is from another source). It does use much less machine dependent settings. Of course, if your appointment is explicitly to work with OpenSSL... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug report: OpenSSL 0.9.5a 1 Apr 2000
On Fri, Jan 19, 2001 at 11:13:20PM -0800, Sunil K. Vallamkonda wrote: Tested using versions: OpenSSL 0.9.5a 1 Apr 2000 with OpenSSH_2.3.1p1 running on NetBSD 1.4.2 Hmm, I just tried to reproduce your problem to no avail with OpenSSL 0.9.6. (I suppose that you are using a latest OpenSSH snapshot as there is no 2.3.1p1 version of OpenSSH.) I run 2.3.0p1 in production on both HP-UX and Linux (OpenSSL 0.9.6) and never met the problem you describe... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: libsafe violation for /etc/ssl/openssl-0.9.6/apps/openssl, pid=18373; overflow caused by memcpy()
On Sun, Nov 12, 2000 at 07:13:07PM -0500, David Arbogast wrote: This was a clean full install of Mandrake 7.2 i586 in "expert" paranoid security mode. My fault? Yes :-) ... ../apps/openssl verify -CApath ../certs ../certs/*.pem Detected an attempt to write across stack boundary. Terminating /etc/ssl/openssl-0.9.6/apps/openssl. "libsafe violation for /etc/ssl/openssl-0.9.6/apps/openssl, pid=18373; overflow caused by memcpy()" A similar report has already been posted some weeks ago by James Breton [EMAIL PROTECTED] (Thread: "make test" fails on Linux while using libsafe-1.3). I could not install libsafe on my SuSE Linux 6.4 (I only received segmentation faults for all programs), Steve Henson could use libsafe on his Redhat 6.1 but could not reproduce the reported problem. James Breton finally came back with the report that he can see this problem only on his Debian 2.2 system, not on a Redhat 6.2. So: use a better distribution :-) To be serious: we are not aware of a memcpy() or other problem in OpenSSL. I rather think that the problem is related to your distribution or the glibc included or whatever. I consider this a false alarm. If you can reproduce the problem and track it down to OpenSSL we will happily accept your detailed bug report. (I checked out the libsafe source code: you can change the _exit() to an abort() and so generate a core dump or run the software in question from a debugger and so track down this thing. As libsafe does not run on SuSE Linux 6.4, I cannot try myself. There was a short discussion on the SuSE-security mailing list about libsafe, the result was not very much in favor of libsafe; SuSE does not include it into the distribution.) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/rand rand.h rand_egd.c rand_unix.c
On Wed, Jan 10, 2001 at 11:18:13AM +0100, Bodo Moeller wrote:
On Tue, Jan 09, 2001 at 05:45:02PM +0100, [EMAIL PROTECTED] wrote:
+ *) Add automatic query of EGD sockets in RAND_poll() for the unix variant.
+ If an EGD or PRNGD is running and enough entropy is returned, automatic
+ seeding like with /dev/[u]random will be performed.
+ Positions tried are: /etc/entropy, /var/run/egd-pool.
+ [Lutz Jaenicke]
Is /etc/entropy a standard location for EGD? Otherwise, and maybe
even if it is, I'd prefer an explicit file name such as /etc/egd-pool
instead of /etc/entropy. The reason is that, judging from its name,
/etc/entropy could be about anything (a symlink to /dev/random or
whatever), but EGD has a very specific interface design; and for those
who find /etc/{entropy,egd-pool} and are curious what is used for,
"egd" is a better term for grepping through the documentation or
searching the web. (It will probably be obvious from the context that
"egd" does not refer to esophagogastroduodenoscopy, even though the
querying procedure is similar. And a web search for "egd pool" is
likely to show up pages that are about the Entropy Gathering Daemon.)
I wholeheartly agree. The /var/run/egd-pool coincides with your understanding
and is my personal location and proposal. /etc/entropy I took from the
README in egd-0.8, where it is explicitly named:
...
HOW TO USE EGD WITH OpenSSH: http://www.openssh.com
(thanks to Patrick Gardella)
First, you'll need to configure OpenSSH to use EGD for it's random number
needs. Add "--with-egd-pool=/etc/entropy" to the arguments you give to
./configure.
Second, you need to have the daemon running. EGD listens on unix-domain
socket for entropy requests. When you start egd.pl, you tell it where to
create the socket. It can be anywhere for which you have write
permissions. Common places include, /etc/entropy, /tmp/entropy, etc.
Simply start the daemon as follows:
egd.pl /etc/entropy
Of course, we are free to contact Brian Warner [EMAIL PROTECTED] and
ask him to propose a better location.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: What means the error message SSL_connect: error in SSLv3 write cl ient key exchange A ?
I remember already having seen this text before.
On Mon, Jan 08, 2001 at 08:22:42AM +0200, Lauri-Alo Adamson wrote:
Then I runned the program and some errors occured
SSL_connect: error in SSLv3 write client key exchange A
SSL_connect: error in SSLv3 write client key exchange A
I would be very pleased if some one could give me good advice that must I do
to solve this problem!
Check out additional information!
SSL_connect: before/connect initialization
SSL_connect: SSLv2/v3 write client hello A
SSL_connect: SSLv3 read server hello A
depth = 1 /C=EE/ST=Estonia/L=Tallinn/O=AS Andmevara/OU=Tech/CN=Administrator
verify return: 1
depth = 0 /C=EE/ST=Harjumaa/L=Tallinn/O=Andmevara/OU=Andmevara/CN=tivoli
verify return: 1
SSL_connect: SSLv3 read server certificate A
SSL_connect: SSLv3 read server done A
SSL_connect: error in SSLv3 write client key exchange A
SSL_connect: error in SSLv3 write client key exchange A
HTSSLWriter. SSL returned 1
Error... Add 73Severity: 1 Parameter: `Error 0'Where:
`SSLWRITE'
HTSSL... Closing SSL Object 40023a18
This information is non-consistent. If SSL returns "1", success is meant.
Whenever returning an error value, the exact reason of the error is
saved on the OpenSSL error stack. There is the function SSL_get_error()
to check out the class of the error (SSL_ERROR_WANT_READ etc meaning that
this is not a hard error and the function would need to be retried, or
other errors indicating a "hard error"). In case of a hard error, the
error message is located on the stack.
Maybe you have to extend libwww to provide this additional error information.
Maybe the server has just closed down the connection.
Regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Random seed and possible blocking of /dev/random
you move from /var/run/egd-pool to /var/spool/egd/socket because this looks more elegant and forget to recompile. Let's rather add a list of places and have this static; stop on success. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Random seed and possible blocking of /dev/random
On Fri, Jan 05, 2001 at 09:49:56PM +0100, Richard Levitte - VMS Whacker wrote: I got to wonder a little about our seeding mechanism and the possibility of /dev/random blocking when getting overwhelmed. The thought trailed on to reads with a timeout, and the question if and how a select() with a file descriptor pointing at a file or a random device does actually react. I don't know how select() would act on a regular file. /dev/random (and/or /dev/urandom) are no regular files, so we could first call stat() and only continue when S_ISCHR() is true (character device). If select() is useable before read() for a standard file, then it would perhaps be possible to use possibly blocking devices like /dev/random and still not get impatient developpers on our throats :-). Hmm, I would consider using non-blocking reads. Select() does not know how many bytes you intend to read, so it will return "available" if just one byte is there and the second byte will block. Of course we could read byte-per-byte... So we can stay with non-blocking reads, try to take the minimum defined (20bytes as of now) and just take what's there. An extension to this could also be to check for more than one random device... This brings me to related point. Would it make sense to define a "default" place to look for an egd-socket? I had several contacts with people using my prngd (egd replacement) that installed prngd and did expect openssl to magically find it. This location would need to be in a "safe" place, so that no normal user can fake one just handing back prepared information (ruling out /tmp as proposed in the egd-documentation). The only place would probably in /etc. I know that /var would be better (I have my sockets /under /var/run), but the directory structure is not portable enough. - /etc/egd-socket? (I would not use /dev as this is for device files only (and might lead to trouble on Linux-2.4 not even having a real /dev directory).) Comments? Booohs? Hoorays? Hooray, that may reduce the unnecessary traffic on openssl-* :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Random seed and possible blocking of /dev/random
On Sat, Jan 06, 2001 at 08:48:09PM +0100, Richard Levitte - VMS Whacker wrote: From: Lutz Jaenicke [EMAIL PROTECTED] Lutz.Jaenicke On Fri, Jan 05, 2001 at 09:49:56PM +0100, Richard Levitte - VMS Whacker wrote: Lutz.Jaenicke I don't know how select() would act on a regular Lutz.Jaenicke file. /dev/random (and/or /dev/urandom) are no regular Lutz.Jaenicke files, so we could first call stat() and only continue Lutz.Jaenicke when S_ISCHR() is true (character device). My question about regular files was with the thought that one could hack RAND_load_file() with something similar. While I had a look into the Linux manpage but did not find things discussed, I know had a look into the HP-UX manpage for select(): ... The select() function supports regular files, terminal and pseudo- terminal devices, STREAMS-based files, FIFOs and pipes. The behaviour of select() on file descriptors that refer to other types of file is unspecified. ... I don't know, whether handling regular files is so much "standard", that it is just not mentioned in other places. So let's rephrase the question: Does somebody know of an (UNIX-like) OS _not_ supporting select() on regular files? Lutz.Jaenicke Hmm, I would consider using non-blocking Lutz.Jaenicke reads. Select() does not know how many bytes you intend Lutz.Jaenicke to read, so it will return "available" if just one byte Lutz.Jaenicke is there and the second byte will block. Of course we Lutz.Jaenicke could read byte-per-byte... That is a solution, but if we want to do reads with a timeout (say 20ms), that would mean a loop with a polling read with a definitely higher frequency than we wold get with a select(). On the other hand, non-blocking doesn't stop us from select()ing, does it? Hmm, perhaps it's a thought after all... Select() and non-blocking read() are a perfect pair :-) Lutz.Jaenicke This brings me to related point. Would it make sense to Lutz.Jaenicke define a "default" place to look for an egd-socket? I Lutz.Jaenicke had several contacts with people using my prngd (egd Lutz.Jaenicke replacement) that installed prngd and did expect Lutz.Jaenicke openssl to magically find it. That would be a good idea, I think. Personally, I'd say /etc/.egd-socket rather than /etc/egd-socket. This removes some possibilities for "accidents" as well. Yes, this is security by obscurity... Hmm, I don't like "dot" files for a wanted functionality. Users may want to use it anyway (e.g. when creating a keypair for their personal keys). Providing entropy should be a system's task (provided by either the OS or a process installed by the admin), so why not have it visible. The possibility of a name clash may be given, but the only thing I would expect to see behind "egd-socket" would be an egd-socket :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: what is doing undocumented SSL_CTX_load_verify_locations()
http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problems compiling HP Openssl in 64 bit mode
On Wed, Dec 13, 2000 at 09:37:56AM +0100, Cliff Sarginson wrote: Configure hpux64-parisc-cc make However the make eventually fails with the complaint: cc -o openssl -DMONOLITH -I../include -DTHREADS -D_REENTRANT -Ae +DD64 +O3 +ESlit -z -DB_ENDIAN -DMD32_XARRAY openssl.o v erify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o dsa.o ds aparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o se ss_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o -L. -L.. -L../.. -L../../.. -L.. -lssl -L.. -lcrypto ld: Missing library symbol table in ../libssl.a Fatal error. make[1]: *** [openssl] Error 1 make[1]: Leaving directory `/tmp_mnt/homes/csargins/openssl-HP-64/openssl-0.9.5a/apps' make: *** [all] Error 1 I would be grateful for any light you could throw on this. I am pretty sure that libssl is having ranlib run on it, but I can send the whole output of make if that helps. Hmm, it might be helpful to get this information. Probably not all of it is needed. "ranlib" is normally not needed, as "ar" will produce the symbol table itself (there is an exception, please read /usr/ccs/bin/ranlib for more information about this exception). So probably the output of "ranlib" and especially the "ar" command might be interesting. (Un?)fortunately I only have HP-UX 10.20 around, so I cannot reproduce your setup. Having this said, and I don't think the configuration for HP-UX 64bit has changed significantly between versions, OpenSSL 0.9.6 is available for some time. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [cryptlib.o] Error 1
1. This belongs to openssl-users, not openssl-dev!!! 2. Fix your email sender address!!! Vipramukhya Swami [EMAIL PROTECTED] 3. The files you are missing are part of the Linux kernel. You either need the kernel sources or just the kernel header files. I don't know how Redhat is organized. Actually, this is not yet covered in the FAQ... Lutz On Wed, Dec 06, 2000 at 07:49:11PM +, Vipramukhya Swami wrote: making all in crypto... make[1]: Entering directory `/home/vswami/kde-download/openssl-0.9.5a/crypto' gcc -I. -I../include -DTHREADS -D_REENTRANT -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c -o cryptlib.o cryptlib.c In file included from /usr/include/errno.h:36, from cryptlib.h:74, from cryptlib.c:61: /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory make[1]: Leaving directory `/home/vswami/kde-download/openssl-0.9.5a/crypto' make: *** [all] Error 1 -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: filtering the cipher list at negotiation time
On Mon, Nov 27, 2000 at 08:11:17PM -0800, David Schwartz wrote: Right. I want to ensure that the library does not choose KRB5 if the library was compiled with KRB5 support but the server was not configured for KRB5 use. (ie, no Kerberos 5 keytab file is provided) I have a similar issue. I'd like to be able to prefer 128-bit ciphers first, 168-bit ciphers second, and 56-bit ciphers lowest. Perhaps we can come up with one solution that meets both of our requirements. I'd suggest adding two hooks, one to control what ciphers are advertised to the client and one to select which common cipher is actually used. Please let me clear up some points. I am describing the TLS protocol (RFC2246) here with special regards to the OpenSSL implementation. I don't have a clue about Kerberos :-) - The client specifies the ciphers it is willing to use in the the CipherSuite contained in the Client Hello message. This is the first message the client sends. At this time it has not yet received any information from the server. RFC2246, Section 7.4.1.2 - The CipherSuite sent from the client should be sorted: The CipherSuite list, passed from the client to the server in the client hello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first). (7.4.1.2) - The server then selects one cipher from this CipherSuite. (7.4.1.2) Results: - The client is responsible for only advertising ciphers in the CipherSuite it is willing to handle. It is also responsible to provide a sufficient sorting with its preferences. - An OpenSSL server (and probably most other servers) will strictly follow the clients preference and choose the first cipher in the CipherSuite it matches. This is not actually enforced by the standard. The standard requires that the servers makes its choice, nowhere is written that the server must follow the clients preferences. OpenSSL however has no means to change this behaviour. * An OpenSSL server has its own list of ciphers with a preference. * It should be possible (with a new option) to change the choosing strategy from "client preference" to "server preference". * A completely free choice could be performed with a callback function. This callback function would however have to access internal (that means undocumented and maybe changing) structures inside the SSL library. Maybe this idea is not too good. - An OpenSSL server chooses the first cipher for which it has the necessary data available: a certificate (if not ADH) and DH parameters, if necessary. The SSL library does not check the verification state of the certificate supplied. There are many reasons for a certificate to fail, not only expiry as has been pointed out in this thread. For a complete check, the complete CA chain would be needed and a complete check as performed in ssl/ssl_cert.c:ssl_verify_cert_chain() would be needed. (Actually, a setup of an X509_CTX and a call to X509_verify_cert().) This could also be done by the application itself, but it is some effort to spend. Maybe one would even need a special verify_callback for the treatment of problems arising, as would be different from errors when checking the peer's certificate. [I develop Postfix/TLS and from my logfiles communicating with people running Postfix/TLS and from communications about problems I now, that such an "integrated check" would help a lot. The consistency of the private key and certificate is already there with SSL_CTX_check_private_key() but having a SSL_CTX_check_cert_chain() might make tracking down problems much easier. This is not a promise that I am going to write such a beast (at least not within a guaranteed schedule :-).] I hope this clarifies things a bit, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: filtering the cipher list at negotiation time
On Tue, Nov 28, 2000 at 09:39:17AM +, Ben Laurie wrote:
What OpenSSL does not offer is a server-side "cipher choice" callback.
The client sends a list of ciphers and an openssl server will always choose
the first of the ciphers it does support.
The point is that he wants to vary the list according to whether the
client presented a cert or not. Hadn't really thought about a cipher
choice callback, but actually that might be a cool way to address the
problem.
While such callback may be a good thing or not, I don't think it solves this
specific problem. The TLS protocol implies that the server selects
the cipher to be used, then sends its choice to the client together with
the CertificateRequest. Only after this point it will learn, whether the
client returned a certificate or not.
At this point only a ChangeCipherSpec could be used to change the cipher
_after_ learning that there is no client certificate!?
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: filtering the cipher list at negotiation time
On Tue, Nov 28, 2000 at 09:21:21AM -0500, Jeffrey Altman wrote:
Given the direction this thread has taken I think I need to explain
something about Kerberos 5 which I just assumed was a known fact.
Kerberos 5 is not a public key algorithm. It is a symetric key
algorithm. Therefore, both the client and the server must both have
their respective credentials before the protocol negotiations begin,
otherwise, failure is guarranteed.
It was good to explain things. I never touched kerberos, so maybe I
even did not understand everything now.
The only question that I have is where in the process of constructing
the ClientHello message should the client filter out KRB5 ciphers; and
where in the processing of the ClientHello message should the server
ignore KRB5 ciphers.
I understand this in the way, that you are working _inside_ the OpenSSL
library. The application does not see any modification!?
My guess at the moment is that the easist place is in the functions
that convert stacks of ciphers to/from byte streams of ciphers since
those functions must be called in all of the appropriate places.
That would be one place to go. For the client, there is no other step
involved than calling ssl_cipher_list_to_bytes().
If you are not working _inside_ the OpenSSL library,
you would check the condition, then call
SSL_set_cipher_list(ssl, "Normal_string:-KRB5");
to use the normal cipher string but no KRB ciphers, just before SSL_connect().
For the server, the same applies for the "outside OpenSSL" approach,
call SSL_set_cipher_list() as appropriate.
Inside OpenSSL, you should have a look into the ssl3_choose_cipher()
function.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
