Re: OpenSSL and compression using ZLIB
Gregory Stark wrote: Oops, I meant 2246. And reading it more carefully, I agree with your interpretation. The dictionary need not be reset. Compression state can and should be maintained across records. So, is anyone working on improving the zlib code according to these new guidelines? Cheers, - Peter -- Peter 'Luna' Runestig (fd. Altberg), Sweden [EMAIL PROTECTED] PGP Key ID: 0xD07BBE13 Fingerprint: 7B5C 1F48 2997 C061 DE4B 42EA CB99 A35C D07B BE13 AOL Instant Messenger Screen name: PRunestig __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
BIO broken
Hard to believe it might by true. Nevertheless everything indicates there is a major design flaw in BIO: BIO sends FILE* pointer across dll boundary, causing crash of statically linked version of libeay32.dll. (At least on WINNT). To reproduce, modify the corresponding compiler switch to /MT and try enclosed tests. The crash is located inside the EnterCriticalSection API, since the dll incorrectly considers sent FILE* as FILEX structure after being unable to locate it in its own list of FILEs. This is caused by the fact, both exe and dll maintain its own copy of the run time library, hence FILE* from the exe cannot work inside the DLL. Jan Kuznik __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: BIO broken
In message [EMAIL PROTECTED] on Sun, 24 Nov 2002 11:38:09 +0100, ssl mailing list [EMAIL PROTECTED] said: ssl Hard to believe it might by true. Nevertheless ssl everything indicates there is a major design flaw ssl in BIO: ssl ssl BIO sends FILE* pointer across dll boundary, causing ssl crash of statically linked version of libeay32.dll. ssl (At least on WINNT). To reproduce, modify the corresponding ssl compiler switch to /MT and try enclosed tests. The crash ssl is located inside the EnterCriticalSection API, since the dll ssl incorrectly considers sent FILE* as FILEX structure after ssl being unable to locate it in its own list of FILEs. ssl ssl This is caused by the fact, both exe and dll maintain its ssl own copy of the run time library, hence FILE* from ssl the exe cannot work inside the DLL. 1. You didn't attach any test file. 2. What do you suggest we do? -- 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: OpenSSL and compression using ZLIB
In message [EMAIL PROTECTED] on Sun, 24 Nov 2002 10:10:26 +0100, Peter 'Luna' Runestig [EMAIL PROTECTED] said: peter+openssl-dev Gregory Stark wrote: peter+openssl-dev Oops, I meant 2246. And reading it more peter+openssl-dev carefully, I agree with your interpretation. The peter+openssl-dev dictionary need not be reset. Compression state peter+openssl-dev can and should be maintained across records. peter+openssl-dev peter+openssl-dev So, is anyone working on improving the zlib code peter+openssl-dev according to these new guidelines? Well, I've got a couple of issues with such a change: 1. Is OpenSSL really the only implementation that has ZLIB at all? I believe there aren't any compression numbers defined for ZLIB yet (are have they actually been defined by now?), so I guess it might be tricky to implement in any case... If OpenSSL isn't alone with ZLIB compression, perhaps we should look at interoperability? 2. How does that affect communication with programs running older versions of OpenSSL? I assume that a change in dictionary reseting will also change the actual data that's resulting from compression. Will that be a problem? -- 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: BIO broken
This is not a design flaw in the BIO. It is a requirement on Windows that the DLLs be built with the same run-time library and threading models as the application. Hard to believe it might by true. Nevertheless everything indicates there is a major design flaw in BIO: BIO sends FILE* pointer across dll boundary, causing crash of statically linked version of libeay32.dll. (At least on WINNT). To reproduce, modify the corresponding compiler switch to /MT and try enclosed tests. The crash is located inside the EnterCriticalSection API, since the dll incorrectly considers sent FILE* as FILEX structure after being unable to locate it in its own list of FILEs. This is caused by the fact, both exe and dll maintain its own copy of the run time library, hence FILE* from the exe cannot work inside the DLL. Jan Kuznik __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and compression using ZLIB
http://www.ietf.org/internet-drafts/draft-ietf-tls-compression-03.txt
defines the compression numbers to be:
enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;
Therefore proposed numbers have been issued. I suggest that OpenSSL
define the CompressionMethod numbers to be:
enum { null(0), ZLIB(1), LZS(2), eayZLIB(224), eayRLE(225), (255) }
CompresssionMethod
as values in the range 193 to 255 are reserved for private use.
Where does the above draft state that the dictionary must be reset?
It states that the engine must be flushed but does not indicate that
the dictionary is to be reset. Resetting the dictionary would turn
ZLIB into a stateless compression algorithm and according to the draft
ZLIB is most certainly a stateful algorithm:
the compressor maintains it's state through all compressed records
I do not believe that compatibility will be an issue. It will simply
result in the possibility that the compressed data is distributed
differently among the TLS frames that make up the stream.
If compatibility is a issue we could implement a new variant of
COMP_zlib(); COMP_tls_zlib() that would be used with ZLIB(1).
Well, I've got a couple of issues with such a change:
1. Is OpenSSL really the only implementation that has ZLIB at all? I
believe there aren't any compression numbers defined for ZLIB yet
(are have they actually been defined by now?), so I guess it might
be tricky to implement in any case...
If OpenSSL isn't alone with ZLIB compression, perhaps we should
look at interoperability?
2. How does that affect communication with programs running older
versions of OpenSSL? I assume that a change in dictionary reseting
will also change the actual data that's resulting from compression.
Will that be a problem?
--
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]
Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!!
The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP
http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: BIO broken
Building shared libraries with static C Run Time Libraries is a disaster waiting to happen on many platforms. It is simply something you should not do. Not just because of the problem you are describing but because the C Run Time Libraries might be from completely incompatible implementations. Perhaps from different vendors. (This is a frequent problem on OS/2 when people try to mix EMX and IBM run time libraries.) If avoiding this problem is a goal of OpenSSL, then the only way to handle it is to never call a run time library function that works on a FILE * directly. Instead, all such calls must be made via callbacks to the application space in much the same way that we do for memory allocation and deallocation. Or applications must never create FILEs themselves and instead must use versions of fopen(), fclose(), ... which are provided by OpenSSL. This is not a design flaw in the BIO. It is a requirement on Windows that the DLLs be built with the same run-time library and threading models as the application. Hard to believe it might by true. Nevertheless everything indicates there is a major design flaw in BIO: BIO sends FILE* pointer across dll boundary, causing crash of statically linked version of libeay32.dll. (At least on WINNT). To reproduce, modify the corresponding compiler switch to /MT and try enclosed tests. The crash is located inside the EnterCriticalSection API, since the dll incorrectly considers sent FILE* as FILEX structure after being unable to locate it in its own list of FILEs. This is caused by the fact, both exe and dll maintain its own copy of the run time library, hence FILE* from the exe cannot work inside the DLL. Jan Kuznik __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error
Hi!
I have a small problem with SSL_get_error. This function starts like this:
int SSL_get_error(SSL *s,int i)
{
int reason;
unsigned long l;
BIO *bio;
if (i 0) return(SSL_ERROR_NONE);
/* Make things return SSL_ERROR_SYSCALL when doing SSL_do_handshake
* etc, where we do encode the error */
if ((l=ERR_peek_error()) != 0)
{
if (ERR_GET_LIB(l) == ERR_LIB_SYS)
return(SSL_ERROR_SYSCALL);
else
return(SSL_ERROR_SSL);
}
Now, if I have something in the error stack from previous operations and I
call SSL_read or SSL_write on non-blocking socket and read or write
returns -1 and sets errno to EAGAIN, then SSL_get_error will return
SSL_ERROR_SSL which makes this error look like an error in SSL
statemachine but it is really not.
Since BIO_f_ssl does not set retry flag for SSL_ERROR_SSL connection
aborts.
One solution to this problem is to make sure that ERR_clear_errors gets
called every time before you do SSL_read or SSL_write (or
BIO_read/BIO_write). But I think that this is not a very good approach,
because it relies on the good habbits of the application programmer.
Calling ERR_clear_errors automatically at the start of SSL_read and
SSL_write might hurt the performance and is therefore probably not a very
good solution.
I think that the good long term solution is do not rely on ERR_peek_error
inside library, because application can call OpenSSL functions with an
error stack that is in an arbitrary state.
I grepped the (almost) current source tree for ERR_peek_error and
ERR_get_error and found that it's fortunately used in just a very few
places:
apps/req.c: if ((ERR_GET_REASON(ERR_peek_error()) ==
apps/rsa.c: while ((e = ERR_peek_error()) != 0
apps/rsa.c: ERR_get_error(); /* remove e from error stack
*/
apps/rsa.c: if (r == -1 || ERR_peek_error() != 0) /* should happen only if
r == -1 */
ssl/ssl_lib.c: if ((l=ERR_peek_error()) != 0)
ssl/ssl_rsa.c: if (ERR_peek_error() != 0)
ssl/ssl_rsa.c: err = ERR_peek_error();
ssl/ssl_rsa.c: (void) ERR_get_error();
test/bntest.c: while ((l=ERR_get_error()))
test/rsa_test.c:while ((l = ERR_get_error()) != 0)
crypto/asn1/a_d2i_fp.c: e=ERR_GET_REASON(ERR_peek_error());
crypto/asn1/a_d2i_fp.c: ERR_get_error(); /* clear error */
crypto/bn/bntest.c: while ((l=ERR_get_error()))
crypto/objects/obj_dat.c: ERR_get_error();
crypto/pem/pem_info.c: error=ERR_GET_REASON(ERR_peek_error());
crypto/pem/pem_lib.c: if(ERR_GET_REASON(ERR_peek_error()) ==
crypto/pkcs7/bio_ber.c: (ERR_GET_REASON(ERR_peek_error()) ==
ASN1_R_TOO_LONG))
crypto/pkcs7/bio_ber.c: ERR_get_error(); /* clear the error */
crypto/rand/md_rand.c: err = ERR_peek_error();
crypto/rand/md_rand.c: (void)ERR_get_error();
crypto/rsa/rsa_test.c:while ((l = ERR_get_error()) != 0)
crypto/x509/by_file.c: if ((ERR_GET_REASON(ERR_peek_error())
==
crypto/x509/by_file.c: if ((ERR_GET_REASON(ERR_peek_error())
==
I suggest that if the exact kind of the error is important we should add
an explicit parameter to the lower level functions to return this
information. Or additional status fields to strucutres like SSL.
Arne
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[STATUS] OpenSSL (Sun 24-Nov-2002)
OpenSSL STATUS Last modified at __ $Date: 2002/11/21 22:39:08 $ DEVELOPMENT STATE o OpenSSL 0.9.8: Under development... o OpenSSL 0.9.7-beta4: Released on November 19th, 2002 Debian GNU/Linux (kernel version 2.4.19, gcc 2.95.4) - PASSED o OpenSSL 0.9.7-beta3: Released on July 30th, 2002 o OpenSSL 0.9.7-beta2: Released on June 16th, 2002 o OpenSSL 0.9.7-beta1: Released on June 1st, 2002 o OpenSSL 0.9.6g: Released on August 9th, 2002 o OpenSSL 0.9.6f: Released on August 8th, 2002 o OpenSSL 0.9.6e: Released on July 30th, 2002 o OpenSSL 0.9.6d: Released on May9th, 2002 o OpenSSL 0.9.6c: Released on December 21st, 2001 o OpenSSL 0.9.6b: Released on July 9th, 2001 o OpenSSL 0.9.6a: Released on April 5th, 2001 o OpenSSL 0.9.6: Released on September 24th, 2000 o OpenSSL 0.9.5a: Released on April 1st, 2000 o OpenSSL 0.9.5: Released on February 28th, 2000 o OpenSSL 0.9.4: Released on August09th, 1999 o OpenSSL 0.9.3a: Released on May 29th, 1999 o OpenSSL 0.9.3: Released on May 25th, 1999 o OpenSSL 0.9.2b: Released on March 22th, 1999 o OpenSSL 0.9.1c: Released on December 23th, 1998 [See also http://www.openssl.org/support/rt2.html] RELEASE SHOWSTOPPERS o BN_mod_mul verification fails for mips3-sgi-irix unless configured with no-asm o [2002-11-21] PR 343 mentions that scrubbing memory with 'memset(ptr, 0, n)' may be optimized away in modern compilers. This is definitely not good and needs to be fixed immediately. The formula to use is presented in: http://online.securityfocus.com/archive/82/297918/2002-10-27/2002-11-02/0 The problem report that mentions this is: https://www.aet.TU-Cottbus.DE/rt2/Ticket/Display.html?id=343 AVAILABLE PATCHES o IN PROGRESS o Steve is currently working on (in no particular order): ASN1 code redesign, butchery, replacement. OCSP EVP cipher enhancement. Enhanced certificate chain verification. Private key, certificate and CRL API and implementation. Developing and bugfixing PKCS#7 (S/MIME code). Various X509 issues: character sets, certificate request extensions. o Geoff and Richard are currently working on: ENGINE (the new code that gives hardware support among others). o Richard is currently working on: UI (User Interface) UTIL (a new set of library functions to support some higher level functionality that is currently missing). Shared library support for VMS. Kerberos 5 authentication Constification OCSP NEEDS PATCH o 0.9.8-dev: COMPLEMENTOFALL and COMPLEMENTOFDEFAULT do not handle ECCdraft cipher suites correctly. o apps/ca.c: Sign the certificate? - n creates empty certificate file o OpenSSL STATUS is never up-to-date. OPEN ISSUES o The Makefile hierarchy and build mechanism is still not a round thing: 1. The config vs. Configure scripts It's the same nasty situation as for Apache with APACI vs. src/Configure. It confuses. Suggestion: Merge Configure and config into a single configure script with a Autoconf style interface ;-) and remove Configure and config. Or even let us use GNU Autoconf itself. Then we can avoid a lot of those platform checks which are currently in Configure. o Support for Shared Libraries has to be added at least for the major Unix platforms. The details we can rip from the stuff Ralf has done for the Apache src/Configure script. Ben wants the solution to be really simple. Status: Ralf will look how we can easily incorporate the compiler PIC and linker DSO flags from Apache into the OpenSSL Configure script. Ulf: +1 for using GNU autoconf and libtool (but not automake, which apparently is not flexible enough to generate libcrypto) WISHES o Add variants of DH_generate_parameters() and BN_generate_prime() [etc?] where the callback function can request that the function be aborted. [Gregory Stark [EMAIL PROTECTED], [EMAIL PROTECTED]] o SRP in TLS. [wished by: Dj [EMAIL PROTECTED], Tom Wu [EMAIL PROTECTED], Tom Holroyd [EMAIL PROTECTED]] See http://search.ietf.org/internet-drafts/draft-ietf-tls-srp-00.txt as well as http://www-cs-students.stanford.edu/~tjw/srp/. Tom Holroyd tells us there is a SRP patch for OpenSSH at http://members.tripod.com/professor_tom/archives/, that could be useful.
SSL_CTX_set_cipher_list(ALL) negotiates ADH-AES256-SHA
Hi all, I have a client and a server, that sets SSL_CTX_set_cipher_list(ALL) (and SSL_CTX_set_tmp_dh_callback()). With beta3 and beta4, that makes the negotiated cipher to be ADH-AES256-SHA. I would expect something like DHE-RSA-AES256-SHA instead (which I get if I do SSL_CTX_set_cipher_list(ALL:!ADH) instead), or am I missing something? Isn't the strongest common cipher expected to be used? Doing it all with 0.9.6g negotiates EXP1024-RC4-SHA instead, which is also a surprise to me; e.g. SSL_CTX_set_cipher_list(MEDIUM) gives IDEA-CBC-SHA. Cheers, - Peter -- Peter 'Luna' Runestig (fd. Altberg), Sweden [EMAIL PROTECTED] PGP Key ID: 0xD07BBE13 Fingerprint: 7B5C 1F48 2997 C061 DE4B 42EA CB99 A35C D07B BE13 AOL Instant Messenger Screen name: PRunestig __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and compression using ZLIB
In message 001601c2940a$deed1b60$06a8a8c0@dell8200 on Sun, 24 Nov 2002 16:43:12 -0600, pobox [EMAIL PROTECTED] said: ghstark What will the current implementation of thedecompressor in ghstark OpenSSL do in each of these cases? Unless this can be determined, it can be tested by having several OpenSSLs with different behavior and test them against each other. In any case, now that I know the numbers (yeah, I know, draft numbers, but that's better than nothing), I can always put them in 0.9.8-dev and try several algorithms (as was suggested, there's a private range, and I see no harm in using them for tests, at least temporarly). -- 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]
Mingw32 build fail
The ms\mingw32.bat build fails with these undefines: out/libcrypto.a(eng_all.o)(.text+0x9):eng_all.c: undefined reference to `ENGINE_load_cswift' out/libcrypto.a(eng_all.o)(.text+0xe):eng_all.c: undefined reference to `ENGINE_load_chil' out/libcrypto.a(eng_all.o)(.text+0x13):eng_all.c: undefined reference to `ENGINE_load_atalla' out/libcrypto.a(eng_all.o)(.text+0x18):eng_all.c: undefined reference to `ENGINE_load_nuron' out/libcrypto.a(eng_all.o)(.text+0x1d):eng_all.c: undefined reference to `ENGINE_load_ubsec' out/libcrypto.a(eng_all.o)(.text+0x22):eng_all.c: undefined reference to `ENGINE_load_aep' out/libcrypto.a(eng_all.o)(.text+0x27):eng_all.c: undefined reference to `ENGINE_load_sureware' out/libcrypto.a(eng_all.o)(.text+0x2f):eng_all.c: undefined reference to `ENGINE_load_4758cca' make: *** [out/evp_test] Error 1 I understand it's because engines\*.c isn't included, but have no idea how to fix this. Gisle V. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
PLEASE HELP - Porting to TRU 64.
Hi Everyone, On Tru64, while using the des_key_schedule structures for the private session key encryption using a public key (of type RSA pub key), is there anything different I have to code as opposed to the other machines. While I was debugging, the des_key_schedule structures size returned two times the size for the other machines. Would this affect the actual encryption data? Actually, I am having problems on only Tru64, where the encrypted session key is supposed to be set on the Windows side, but I keep getting an error on Windows saying 'Bad data', in taht the public key is corrupted. If ANYONE has encountered or come across a similar issue on Tru64, PLEASE reply to me. Also, if anyone can help further if I send the code, please let me know and I will get back to you promptly. Thanx in advance, Jay.. = - J | - [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus Powerful. Affordable. Sign up now. http://mailplus.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
