Re: Memory leak in session caching?
Hi there, I'm not cross-posting this to modssl-users as the problem and solution are mostly openssl-specific. Perhaps we can post a summary to modssl-users once this is over with. On Monday 21 Oct 2002 8:40 am, Nadav Har'El wrote: I ran the test again with the correct library, and OpenSSL 0.9.6g indeed does not cache new sessions in the internal cache (when NO_INTERNAL_LOOKUP), like I already noticed in the source code. But it does cache resumed sessions in the internal cache, again like I noticed in the source code (ssl_get_prev_session()) - so I think this is the bug. Thanks for the detailed report - Lutz has already created an RT ticket for this. I replied to the RT mail from him privately before noticing these followups (from you both) on modssl-users and openssl-dev, so I'll repeat here a suggestion I proposed in my mail to him, though I'll try to elaborate a bit. I think perhaps the correct solution would be to have things as follows; - SSL_SESS_CACHE_NO_INTERNAL_LOOKUP Lookups are not performed using the internal/local cache but solely through (any) external cache-lookup callback. Make sure that cache stores are nonetheless cached internally as well as through any external callback - as it was before and perhaps is still the case in some inconsistent buggy fashion, as you have suggested might be the case. :-) - SSL_SESS_CACHE_NO_INTERNAL_STORE (new flag) Cache stores are not performed against the internal/local cache but solely through (any) external cache-store callback. Lookups are nonetheless performed internally before using any external callback. - SSL_SESS_CACHE_NO_INTERNAL (new flag) This is (SSL_SESS_CACHE_NO_INTERNAL_LOOKUP|SSL_SESS_CACHE_NO_INTERNAL_STORE) Combination of the both the above, and the appropriate replacement for use in mod_ssl, Apache2, and other circumstances where fork() can introduce security problems with cache state. The reason I don't suggest changing the behaviour SSL_SESS_CACHE_NO_INTERNAL_LOOKUP to not store sessions is two-fold; (i) behavioural change of a flag that applications may be relying on and will introduce an unforeseen bug. (ii) it may actually be advantageous to have fine-grained control as I've suggested with the 3 flags (well, the third being an abbreviation for the OR of the first two). W.r.t. (ii) I can invisage NO_INTERNAL_LOOKUP being used on its own with the current behaviour - we may want a cache of sessions for manual inspection by the application without the application having to implement its own cache. With this flag, the application can be sure that the SSL/TLS code won't automatically resume them without going via its external callback - ie. the application itself will control those sessions it is prepared to accept or not. NO_INTERNAL_STORE may be similarly useful because the application can know the SSL/TLS implementation will automatically resume any resumable session in its cache, but the contents of that cache are only those sessions that the application has manually inserted into the cache of its own will - the SSL/TLS implementation won't automatically populate the cache. Obviously the combination will be useful too and in fact is what is desired in Apache2/mod_ssl. Any thoughts? I'm thinking out loud here - but will continue to think a little more carefully (and quietly) about it. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #306] EVP_xxx_{cfb,ofb} problems in openssl 0.9.7-beta3
Are you speaking of the CFB-8 tests failing? I've only implemented
CFB-128 so far, so I'd expect CFB-8 to fail. If I'm reading things
right, Levitte's fix is for the EVP padding, not the crypto routines.
S
Thus spake Chris Brook:
Is this now fixed for EVP_Encrypt() and EVP_Decrypt() or only the
xxInit,xxUpdate,xxFinal sequences? Or must I set padding off?
If this is resolved, I can go back and rerun the NIST AES certification
tests for CFB with 8 bit block sizes. Needless to say they failed before.
Chris Brook
-Original Message-
From: [EMAIL PROTECTED]
[mailto:owner-openssl-dev;openssl.org]On Behalf Of John Viega via RT
Sent: Thursday, October 17, 2002 7:18 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [openssl.org #306] EVP_xxx_{cfb,ofb} problems in openssl
0.9.7-beta3
Yes, it does indeed seem to be fixed. Seeing that OFB and CFB are
pretty fundamental, shouldn't a fix like that merit a b4 release,
particularly considering how long it's been since b3? :)
John
On Thursday, October 17, 2002, at 05:34 PM, Richard Levitte - VMS
Whacker wrote:
In message [EMAIL PROTECTED]
on Thu, 17 Oct 2002 16:34:55 -0400, John Viega
[EMAIL PROTECTED] said:
viega Perhaps it would help to show you how things work differently
in 0.9.6
viega and 0.9.7. Try this code out in each one:
viega
viega #include openssl/evp.h
viega
viega int main(int argc, char **argv) {
viegaEVP_CIPHER_CTX c;
viegachar key[128] = {0,};
viegachar iv[128] = {0,};
viegachar in[256]={0,};
viegachar out[256];
viegaint olen,i, o2;
viega
viega #define CIPHER() EVP_bf_cfb()
viega #define HOWMANY 148
viegaEVP_EncryptInit(c, CIPHER(), (char *)key, iv);
viegaEVP_EncryptUpdate(c, out, olen, in, HOWMANY);
viegaEVP_EncryptFinal(c, out+olen,o2);
viegaolen += o2;
viegaprintf(Olen = %d\n, olen);
viegafor(i=0;iolen;i++) {
viega printf(%02x , (unsigned char)out[i]);
viega}
viegaprintf(\n);
viega }
viega
viega This returns 148 in 0.9.6, and it returns 152 in 0.9.7 (b3 at
least).
viega The same thing happens in OFB mode. What's going on is that
PKCS
viega padding is getting added when it never was previously.
Ah, yeah, right, that's a bug in beta3. It has been fixed, however.
Please try the latest 0.9.7 snapshot, and you'll see the difference.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
--
Stephen Sprunk God does not play dice. --Albert Einstein
CCIE #3723 God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity. --Stephen Hawking
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL on WindowsCE
In message [EMAIL PROTECTED] on Mon, 21 Oct 2002 12:48:17 +0200, Amir Schwartz [EMAIL PROTECTED] said: AmirS I would like to know whether a WindowsCE version of OpenSSL AmirS exists. I'm sure there are ports out there, but I haven't seen any specifics. AmirS We couldn't find any WindowsCE related information on the AmirS website. We tried to compile the source files ourselves using AmirS Microsoft eMbedded Visual C++ 4.0, but received errors in the AmirS following files: AmirS AmirS $(OBJ_D)\read_pwd.obj AmirS $(OBJ_D)\bss_log.obj AmirS $(OBJ_D)\randfile.obj AmirS $(OBJ_D)\rand_win.obj AmirS $(OBJ_D)\by_dir.obj AmirS $(OBJ_D)\read2pwd.obj Well, I'm not entirely surprised. However, just saying that there are errors doesn't really help anyone even trying to help you with a port. Please be more specific... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: problem when porting openssl to netware
I just fixed this. thx -H - Original Message - From: Richard Koenning [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 21, 2002 10:18 AM Subject: Re: problem when porting openssl to netware At 14:37 18.10.2002 -0400, you wrote: [...] The test programs run well on NetWare server. But when I run openssl on NetWare server to connect to a ssl server running on win2k, ( to do this , openssl - s_client ... ) , I got the following message .. SSL_connect: error in SSLv3 write client key exchange A SSL_connect: error in SSLv3 write client key exchange A 335810663: error : 24064064: random number generator:SSLEAY_RAND_BYTES: PRNG not seeded: md_rand.c :501 You need to read the OpenSSL FAQ, Have you done that? http://www.openssl.org/support/faq.html Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL on WindowsCE
Title: OpenSSL on WindowsCE Hello, I would like to know whether a WindowsCE version of OpenSSL exists. We couldn't find any WindowsCE related information on the website. We tried to compile the source files ourselves using Microsoft eMbedded Visual C++ 4.0, but received errors in the following files: $(OBJ_D)\read_pwd.obj $(OBJ_D)\bss_log.obj $(OBJ_D)\randfile.obj $(OBJ_D)\rand_win.obj $(OBJ_D)\by_dir.obj $(OBJ_D)\read2pwd.obj Regards, Amir Schwartz. P.S I hope that I'm sending this message to the right list, if it should be addressed to a different one please let me know.
Re: CTR mode
In message [EMAIL PROTECTED] on Mon, 21 Oct 2002 11:54:24 -0500, Stephen Sprunk [EMAIL PROTECTED] said: stephen I've just realized that my CTR code increments the nonce and not stephen the whole counter. Do you want me to send diffs, or can you fix it stephen yourself? That part of the code is really messy :( Please send a patch. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CTR mode
My reading of Rogaway's CTR submission was a nonce in the top half of the counter with a simple increment (by one) of the whole counter. Is there a new spec we need to comply with? What is the correct behavior of CTR when it reaches 2^64 (or whatever lower limit IPsec et al may set)? I'd assumed that it was safe to wrap to zero and keep counting. Do you have a suggested implementation for how to set a lower limit? The modes should probably be written as macros, yes. Unfortunately, some cipher implementations don't call an ECB function but actually implement the cipher inside the mode; switching to mode macros will be very tricky. S Thus spake John Viega: It should be possible to replace the counter increment function. The new NIST modes doc doesn't specify a mandatory increment function, but it does recommend one that's different from add one every time. Additionally, a lot of stuff built on counter mode is using a few bits of the counter for other purposes, so the effective counter size is less than the actual counter size. It would be nice to be able to add some sort of parameter that specifies the actual counter size, to prevent counter mode from continuing to encrypt when it's run out of counters. Also, why isn't counter mode implemented in a generic fashion? It's so simple, it should be usable with any block cipher without having to write additional code. John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL PROBLEM on HP-UX 11.00 and 11.11 (11i)
Hello Everyone, Has anyone had trouble with using the OpenSSL library on HP-UX?? I am using version 0.9.6d and there seems to be an intermittent problem with the digest encryption, or just some of the encryption/decryption routines in the OpenSSL toolkit. It does not happen all the time on HP-UX 11i, but it occurs all the time in HP-UX 11.00, in that the encryption and decryptions do not work. This was just recently ported to the HP-UX source tree of the product that is using OpenSSL. On Solaris, I used the OpenSSL library as a linked library and everything worked fine, but the same does not go for the HP-UX platforms for some reason. I am not sure where to start debugging, so please if anyone has come across a similar situation, please let me know or help me to start finding out the real problem or why it could be happening. It will be incredibly appreciated. Thanking you, J.. = - J | - [EMAIL PROTECTED] __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
