Re: 0.9.7 make test needs work
On Wed, Feb 13, 2002 at 08:37:24PM -0800, Tim Rice wrote: The make test in 0.9.7 needs a little work. [...] ./evp_test evptests.txt Auto configuration failed Fixed. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/err err.c
On Thu, Feb 14, 2002 at 02:42:36PM +0100, [EMAIL PROTECTED] wrote: Log: For some reason, getting the topmost error was done the same way as getting the bottommost one. I hope I understood correctly how this should be done. It seems to work when running evp_test in an environment where it can't find openssl.cnf. --- err.c 2002/01/24 17:17:29 1.51 +++ err.c 2002/02/14 13:42:33 1.51.2.1 @@ -720,7 +720,7 @@ if (es-bottom == es-top) return 0; if (top) - i=(es-bottom+1)%ERR_NUM_ERRORS; /* last error */ + i=es-top; /* last error */ else i=(es-bottom+1)%ERR_NUM_ERRORS; /* first error */ This fix for err.c is correct. But evp_test.c should never have called OPENSSL_config() because OPENSSL_config() uses the configuration file found in an OpenSSL *installation*. If we want to use a configuration file during 'make test', we should use one located in the source tree. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL Makefiles - SUGGESTION
On Thu, Feb 07, 2002 at 07:17:50AM -0500, Saju Paul Panikulam wrote: It would be nice to have a paragraph in the Makefiles to remove the TAB (^I) characters from the OpenSSL source and header files. The debugger on the platform that we use does not handle the TABs very well. Had to write a little script to remove them. We used expand but any editor (ex, ed, sed) should be able to do the same job. I don't think we should further complicate the Makefiles by including workarounds for this kind of problems with broken software. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/err err.c
On Fri, Feb 15, 2002 at 10:55:13AM +, Ben Laurie wrote: This fix for err.c is correct. But evp_test.c should never have called OPENSSL_config() because OPENSSL_config() uses the configuration file found in an OpenSSL *installation*. If we want to use a configuration file during 'make test', we should use one located in the source tree. It may be a good idea to test that configuration works, somehow. And yeah, I shouldn't have put config in evp_test, it was a mistake. Now with Steve's change (add a file name parameter to OPENSSL_config()) the OPENSSL_config() call can be put back into evp_test -- it just should use a file in the source code tree. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl STATUS
On Wed, Feb 20, 2002 at 03:07:16PM +0100, [EMAIL PROTECTED] wrote: Log: Including openssl/e_os.h in the OpenSSL 0.9.6 branch is legal, since it's exported. Changing that is a BIG step, which has been done in 0.9.7-dev. Revision ChangesPath 1.214 +1 -5 openssl/STATUS Index: STATUS === RCS file: /e/openssl/cvs/openssl/STATUS,v retrieving revision 1.213 retrieving revision 1.214 diff -u -r1.213 -r1.214 --- STATUS 2002/02/20 13:19:59 1.213 +++ STATUS 2002/02/20 14:07:07 1.214 @@ -1,6 +1,6 @@ OpenSSL STATUS Last modified at - __ $Date: 2002/02/20 13:19:59 $ + __ $Date: 2002/02/20 14:07:07 $ DEVELOPMENT STATE @@ -67,10 +67,6 @@ o 'openssl speed' should include AES support (0.9.7-dev) o apps/ca.c: Sign the certificate? - n creates empty certificate file - -o OpenSSL_0_9_6-stable: - #include openssl/e_os.h in exported header files is illegal since - e_os.h is suitable only for library-internal use. While e_os.h is installed as a header file in the 0.9.6 branch and thus is available to applications that *want* to use it, it is meant only for internal use, so it should not be '#include'd if not *explicitly requested* by the application. If an application wants e_os.h, fair enough -- but otherwise the stuff in e_os.h may break applications. That's what that entry was about. The problem with 0.9.6-stable is that '#include openssl/e_os.h' was added to conf.h, openssl/conf.h being automatically included by x509v3.h. I consider this a bug: Writing '#include openssl/x509v3.h' in the application sourcecode does not mean that you want an EXIT(n) macro to be defined, to name one example. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] argument passing to app_verify_callback
On Sat, Feb 16, 2002 at 11:16:23AM +0100, Richard Levitte - VMS Whacker wrote: I see no problem adding this patch. Queued. The problem is that the application callback prototype is incompatibly changed. Otherwise I would have added the argument instead of simply adding comments pointing out the inconsistency. To maintain backwards compatibilty, it looks like we need a new function for registering callback functions expecting this additional argument. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl STATUS
On Wed, Feb 20, 2002 at 06:45:41PM +0100, Richard Levitte - VMS Whacker wrote: [...] If you look in conf.h, you'll also see why it includes e_os.h: an #ifndef NO_FP_API. BTW, in 0.9.7-dev, we have the same (or almost, it depends on OPENSSL_NO_FP_API) #ifndef, but that one is meaningless, since OPENSSL_NO_FP_API is defined in e_os.h. Suggestion on how to solve this? One that I can think of is to remove the conditional and just let CONF_load_fp() (and NCONF_load_fp()) be declared even if they aren't in the library. That's ugly, but workable. It certainly is a lot less ugly than forcing e_os.h upon applications that don't request it, so I think we should simply make the prototype unconditional. Hm, other header files have similarly #ifndef-ed prototypes too -- they just don't include e_os.h, so this should be OK for conf.h as well. In 0.9.6-stable, conf.h also requires e_os.h to get MS_FAR defined. You simply removed this in 0.9.7-dev, so I figure we can do the same in 0.9.6-stable: revision 1.19 date: 2001/02/22 17:41:15; author: levitte; state: Exp; lines: +9 -9 CONF_METHOD is one of the few places where you find MS_FAR. I can't really see why we need to define these function pointers with MS_FAR if it's not done cosistently everywhere. If we decide to support MS_FAR modifiers, it's better to have the named something more unique for OpenSSL and to define them in e_os2.h. The occurrences of MS_FAR in conf.h were new with 0.9.6, so certainly no legacy applications will be affected by removing them. On all platforms actually used in real life, MS_FAR has an empty definition anyway. Summary: We should remove '#include openssl/e_os.h' and 'MS_FAR' from conf.h, then everything should be fine (or at least consistent with the rest of OpenSSL). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] argument passing to app_verify_callback
On Wed, Feb 20, 2002 at 10:18:55AM -0800, D. K. Smetters wrote: One comment made when I proposed the patch was that this functionality is currently almost entirely unused. Therefore changing the expected prototype is not likely to affect that many people, Well, maybe you and me are actually the only ones who have used SSL_CTX_set_cert_verify_callback() so far. If so, I agree to the change -- but only under the condition that your patch updates demos/easy_tls accordingly :-) Also the SSL_CTX_set_cert_verify_callback() prototype should be updated to include the argument list of the actual callback. It should also be included in the 'app_verify_arg' declaration for struct ssl_ctx_st in ssl.h. If this is changed, the POD manpages in doc/ssl/ must be updated. many of whom may actually prefer having the argument used. It also cleans up a notable inconsistency in the code (having placeholders for the unused argument), which might be useful to do on a revision boundary. It is true you can get to the SSL structure from the ex_data in the X509_STORE_CTX (thanks very much for pointing that out, I had missed it entirely). However, a) it's not easy to find (though I may just be blinder than most :-), and b) while it's available through the ex_data field, I don't think it's presence there is documented, and I as a user of the code wouldn't be sure that it's presence there was meant to be used by callbacks or something I could really rely on from version to version of OpenSSL. In contrast, the argument to app_verify_callback is easier to find, documented (though with the caveat that it doesn't work), and cleaner. The app_verify_callback argument certainly would be much nicer than having to use ex_data. (Everything is nicer than ex_data.) The only impediment to changing this is backwards compatibility. It seems that there are 4 approaches to this patch: 1) punt, and leave things in their current inconsistent state 2) skip the patch to protect backwards compatibility in the function prototype; but also: a) remove the argument entirely from the code and documentation so as to skip having this discussion again b) document/comment the placement of the SSL pointer in the ex_data so that it's clear that it's a stable feature of the code and can be relied on by app_verify functions, and not there just for the current convenience of some unrelated piece of the library 3) add the patch, on the theory that at most a small number of people will be bitten by the change in callback prototype, and that it's worth it for both usability and modularity 4) keep the current prototype, and add yet a 3rd callback function that actually takes an argument. Personally, I'd go for either 3 or 2+a+b. 4 might be nice, but would take more time planning. There aren't that many occurrences of 'verify_callback' in ssl/*.c, so approach #4 should be managable. But if noone else uses SSL_CTX_set_cert_verify_call() anyway, then changing the interface is fine with me. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: #ifdef DEBUG printf() in crypto/rand/rand_win.c (and others)
On Thu, Feb 21, 2002 at 09:29:24AM +0100, Peter 'Luna' Runestig wrote: I just found a bunch of these things in crypto/rand/rand_win.c, that surprised me: #ifdef DEBUG printf(randomness from PROV_RSA_FULL\n); #endif I'm using a standard debug build on Windows, and was, as I said, surprised by the extra info on screen when running my app. I'll simply remove these (#if 0). Apparently they are a leftover from when this file was initially developped. We have a couple of specific ..._DEBUG preprocessor symbols otherwhere in the code, but these are designed such that they don't change behaviour (other than execution speed) during normal operation unless there is some bug. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] argument passing to app_verify_callback
On Thu, Feb 21, 2002 at 06:17:47PM +0100, Richard Levitte - VMS Whacker wrote: I'm not sure I see the problem. Let's see, if an application with a certificate verification callback registered through SSL_CTX_set_cert_verify_callback() is built for an older OpenSSL (i.e. doesn't take a user argument), what will happen is that the callback gets an extra random argument that it ignores (if it's been constructed correctly). A new application will have to use the new interface which demands a user argument to be passed to the callback, and that should present no problems. This is true for C the macro assembler, but not for C the programming language. There is no guarantee that function calls will remain compatible. If we add the paramter list declaration for app_verify_callback to ssl/ssl.h and ssl/ssl_lib.c (which I think we should do for type safety), applications written for old releases will not compile without modification if they use SSL_CTX_set_cert_verify_callback(). But the only application that I know of that actually uses this function is by myself, and I can accept this incompatibility. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] argument passing to app_verify_callback
On Thu, Feb 21, 2002 at 06:30:04PM +0100, Bodo Moeller wrote: [...] If we add the paramter list declaration for app_verify_callback to ssl/ssl.h and ssl/ssl_lib.c (which I think we should do for type safety), applications written for old releases will not compile without modification if they use SSL_CTX_set_cert_verify_callback(). But the only application that I know of that actually uses this function is by myself, and I can accept this incompatibility. When I wrote this, I had not yet read Claus Aßmann's message stating that Sendmail uses SSL_CTX_set_cert_verify_callback() too. We should add the functionality without changing the existing interface -- i.e., add a function for registering callbacks that expect the additional argument. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Using SSL_clear to reuse SSL object
Lutz Jaenicke [EMAIL PROTECTED]:
On Wed, Feb 20, 2002 at 12:29:03PM +0200, Yoram Zahavi wrote:
My server application is using SSL_clear to reuse the SSL object, instead of
allocating a new one on every new connection. On first connection the client
succeeds to connect the server, and later on to reuse the SSL sessions. As
far as I understand connections are closed properly, assigning both
SSL_RECEIVED_SHUTDOWN and SSL_SENT_SHUTDOWN masks, and closing the
underlying socket as well.
The Server starts facing problems when the Client tries to open a new
connection asking not to reuse the previous session. The SSL object still
holds a valid Session (since previous connection was closed in the right
way), which is not removed by SSL_clear. As far as I understand, the Server
suppose to overcome such case and support the new connection by performing
full handshake.
[...]
Hmm. This brings up the question, what SSL_clear() should actually do.
I would consider SSL_clear() to be not much different from doing
SSL_free()/SSL_new(), but obiously it is. Unfortunately EAY did not leave
documentation about his intentions...
Note that SSL_clear() is called by the {ssl23,ssl2,ssl3}_{connect,accept}
functions, so it should not reset too much. In particular, it should
not unconditionally remove the session.
Connections to a previously used SSL object with a valid session fail
not because the servers insists on that particular session, but
because the server is restricted to the protocol version of that
particular session (and thus cannot handle a backwards-compatible
client hello). This is intentional: SSL_clear() will reset the
protocol version (method) only if no session is set. This behaviour
makes a lot of sense for SSL client objects. It is not particularly
useful for SSL server objects, but it would be bad to give up
consistency. If you really want to reuse an SSL server object,
use SSL_set_session(s, NULL) before calling SSL_clear(s).
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Using SSL_clear to reuse SSL object
Yoram Zahavi [EMAIL PROTECTED] in epsilon.openssl.dev: Thanks for the explanation, I liked the SSL_set_session(s, NULL) usage. Any reasons for calling it *before* SSL_clear(s) ? I think you better call it after the call to SSL_clear(s). Otherwise, the current session is already freed by SSL_set_session(s, NULL), and cannot be referenced by SSL_clear(s) for caching considerations. Good point. My reason for calling SSL_set_session(s, NULL) first was that otherwise SSL_clear(s) would not reset the method pointer (i.e., the protocol version). But you are right, and SSL_clear(s); SSL_set_session(s, NULL); should be OK: In this case, SSL_set_session() will reset the method pointer. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] config mod for crays
On Tue, Feb 05, 2002 at 06:42:08PM -0600, Wendy Palm wrote:
--- config.orig Mon Feb 4 16:12:43 2002
+++ config Tue Feb 5 16:01:09 2002
@@ -302,6 +302,13 @@
echo ${MACHINE}-whatever-cygwin32; exit 0
;;
+*CRAY T3E)
+ echo cray-t3e; exit 0;
+ ;;
+
+*CRAY*)
+ echo cray-t90; exit 0;
+ ;;
esac
#
@@ -562,6 +569,8 @@
mips-sony-newsos4) OUT=newsos4-gcc ;;
*-*-cygwin32) OUT=CygWin32
options=$options no-threads no-asm ;;
+ cray-t90) OUT=cray-t90 ;;
+ cray-t3e) OUT=cray-t3e ;;
*) OUT=`echo $GUESSOS | awk -F- '{print $3}'`;;
esac
I wanted to commit this patch, but I noticed that it breaks the naming
scheme that links the two parts of 'config'. Note that names always
have three components separated by hyphens. While things are not
totally consistent, the general pattern usually is
machine-manufacturer-os
or
machine-architecture-os.
Please try to come up with a naming that matches the rest of 'config'
as close as possible.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Fixes for 0.9.6-stable branch
On Thu, Feb 21, 2002 at 10:34:47AM +0100, Oscar Jacobsson wrote: * The fix for crypto/tmdiff.c (ie. the diff between 1.9.2.1 1.9.2.2) needs to be merged into this branch as well. Missing #endif. Fixed. * crypto/bio/bss_bio.c now checks SSIZE_MAX, and in the visual c++ limits.h this won't get defined unless one defines _POSIX_. Should this definition go into e_os.h or is it ok to simply insert it here prior to the inclusion of limits.h? If SSIZE_MAX is not defined, we use INT_MAX instead. Why worry about it? -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: error compiling openssl 0.9.7, windows 2000, mingw32
On Thu, Feb 28, 2002 at 09:11:54AM +0100, Joerg Voelker wrote: if I try to compile openssl 0.9.7 under win2k with mingw32 I get the following error: ranlib out/libssl.a gcc -o tmp/md2test.o -Ioutinc -Itmp -DL_ENDIAN -DDSO_WIN32 -fomit-frame-pointer -O3 -m486 -Wall -DBN_ASM -DMD5_ASM -DSHA1_ASM -DOPENSSL_NO_KRB5 -c ./crypto/md2 /md2test.c gcc -o out/md2test tmp/md2test.o out/libssl.a out/libcrypto.a -lwsock32 -lgdi32 out/libcrypto.a(bn_mul.o)(.text+0x44b):./crypto/bn/bn_mul.c: undefined reference to `bn_sub_part_words' out/libcrypto.a(bn_mul.o)(.text+0x49d):./crypto/bn/bn_mul.c: undefined reference to `bn_sub_part_words' out/libcrypto.a(bn_mul.o)(.text+0x4c5):./crypto/bn/bn_mul.c: undefined reference to `bn_sub_part_words' out/libcrypto.a(bn_mul.o)(.text+0x4f5):./crypto/bn/bn_mul.c: undefined reference to `bn_sub_part_words' out/libcrypto.a(bn_mul.o)(.text+0x525):./crypto/bn/bn_mul.c: undefined reference to `bn_sub_part_words' out/libcrypto.a(bn_mul.o)(.text+0x55d):./crypto/bn/bn_mul.c: more undefined references to `bn_sub_part_words' follow make: *** [out/md2test] Error 1 bn_sub_part_words() is a new function that has been implemented in Assembler only for x86. The C implementation in bn_mul.c is enabled only if the following condition is satisfied: #if defined(OPENSSL_NO_ASM) || !(defined(__i386) || defined(__i386__))/* Assembler implementation exists only for x86 */ On your platform, the assembler implementation should be used. Isn't bn_sub_part_words() defined in crypto/bn/asm/bn-win32.s? If it is: Isn't bn-win32.s assembled and linked into the library? Possibly crypto/bn/bn_asm.c is compiled and linked instead; this is the C implementation of most of the stuff that exists in bn-win32.s, with the exception of bn_sub_part_words(). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug fix: crypto/bn/bntest.c calls to BN_free()
On Wed, Feb 27, 2002 at 11:39:26PM +, Tom Cosgrove wrote: There's a problem in bntest.c from openssl-0.9.6c. It appears that this revision of the file is still the latest (rev 1.55), at least via CVSweb. The problem is that there are calls to BN_free() to attempt to free BIGNUMs that are not created by BN_new(). These calls presumably came about when changing the code to use stack-based automatic variables instead of pointers. I don't see anything wrong with this. Documented behaviour of BN_free() is to free the BIGNUM structure only if it has been created by BN_new(). The calls to BN_free() should just be deleted. No. BN_free() releases the additional data usually allocated during use of the BIGNUM. Omitting the calls to BN_free() would lead to memory leaks. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Wrong OIDS for PKCS #9 gender and pseudonym?
On Wed, Feb 20, 2002 at 09:59:19AM -0800, Leonard Janke wrote: According to PKCS #9 v2 gender should have the OID 1 3 6 1 5 5 7 9 3 and psuedonym should have the OID 1 2 840 113549 1 9 3. According to OpenSSL's objects.h gender has the OID 1 3 6 1 5 5 7 9 4 and pseudonym has the OID 1 3 6 1 5 5 7 9 3, Surely you mean obj_mac.h or objects.txt, not objects.h (in which I can find neither 'gender' nor 'pseudonum')? objects.txt was incorrect in OpenSSL 0.9.6c, but obj_mac.h had already been fixed if I remember correctly. (The OID for 'gender' has been fixed, the incorrect OID for 'pseudonym' simply was deleted.) In later versions, objects.txt wil be corrected similarly. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Fixes for 0.9.6-stable branch
On Fri, Mar 01, 2002 at 06:36:59PM +0100, Oscar Jacobsson wrote: Sorry for not being clearer. The reason I (or my compiler rather) was worrying about it is that it's actually a case of _INT_MAX being used rather than INT_MAX. Oh, that. I think that was a typo; all the other branches use INT_MAX (and so does 0.9.6-stable now). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] config mod for crays
On Fri, Mar 01, 2002 at 12:22:45PM -0600, Wendy Palm wrote:
the various architectures available from cray are
c90, j90, t90, t90IEEE, sv1, ymp and t3e.
t3e runs unicosmk, the rest run unicos.
for openssl, the cray t3e requires different compile options
than the other machines. (these are correct in Configure for cray-t3e).
c90, j90, t90, T90IEEE, sv1 and ymp require the compile options
current set as cray-t90-cc in Configure.
cray-c90-unicos
cray-j90-unicos
cray-t90-unicos
cray-t90ieee-unicos
cray-sv1-unicos
cray-ymp-unicos
cray-t3e-unicosmk
are all the different possible machine-architecture-os combinations at this time.
Actually the words 'machine' and 'architecture' appear to have a
different (reversed) meaning in 'config': The first usually is what
'uname -m' prints, so for example there's 'sun4u-sun-solaris2'.
we at cray consider the j90 to be the base machine type for all the unicos
machines.
In 'Configure', we have entries 'cray-t90-cc' and 'cray-t3e'. (Your
'config' patch referrred to 'cray-t90', which does not exist in
'Configure'.)
Given that j90 is considered the base machine type, should the former
configuration be called 'cray-j90-cc' (or simply 'cray-j90') instead?
For the names currently used in 'Configure', the following patch to
'config' (as found in the 0.9.6-stable snaphot) should be OK:
Index: config
===
RCS file: /e/openssl/cvs/openssl/config,v
retrieving revision 1.64.2.18
diff -u -u -r1.64.2.18 config
--- config 2002/02/14 12:29:02 1.64.2.18
+++ config 2002/03/02 15:15:46
@@ -310,6 +310,13 @@
exit 0
;;
+*CRAY T3E)
+ echo t3e-cray-unicosmk; exit 0;
+ ;;
+
+*CRAY*)
+ echo t90-cray-unicos; exit 0;
+ ;;
esac
#
@@ -591,6 +598,8 @@
mips-sony-newsos4) OUT=newsos4-gcc ;;
*-*-cygwin_pre1.3) OUT=Cygwin-pre1.3 ;;
*-*-cygwin) OUT=Cygwin ;;
+ t3e-cray-unicosmk) OUT=cray-t3e ;;
+ t90-cray-unicos) OUT=cray-t90-cc ;;
*) OUT=`echo $GUESSOS | awk -F- '{print $3}'`;;
esac
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: IRIX 6.5 problem with BN_mod_mul in openssl-0.9.7-stable-SNAP-20020213
On Wed, Mar 06, 2002 at 01:18:30PM -0500, Dawn Whiteside wrote: The latest OpenSSL-0.9.7 snapshot I've downloaded fails the BN_mod_mul test on both 32-bit and 64-bit IRIX 6.5 systems using either gcc or the vendor compiler. Results of 'make report' are attached (four files). [...] The BN test leaves behind a file 'tmp.bntest', which can be fed to GNU bc. If everything runs correctly, this will output lots of zeros. I tried this on the March 5 snapshot with both the vendor bc (which is an older GNU bc by the look of things) and GNU bc 1.06. They show identical failures (with different numbers than the February 13 snapshot) in BN_mod_mul. Output from 'bc test/tmp.bntest' for both vendor bc and GNU bc 1.06 on an Irix 6.5 64-bit platform is attached. To get an idea *what* is going wrong, we need the actual file tmp.bntest. The bc output just shows *that* something is going wrong. But we already know that currently there are bugs for 64-bit platforms. The problems with the 32-bit system are more interesting; for that case, please also try a 'no-asm' build. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: IRIX 6.5 problem with BN_mod_mul in openssl-0.9.7-stable-SNAP-20020213
On Thu, Mar 07, 2002 at 09:32:44AM -0500, Dawn Whiteside wrote: Okay, got it. Attached are the tmp.bntest files (modified to print the options c. from 'make report' so it's clear which is which) for the 20020306 snapshot on a 32-bit Irix 6.5 system both with and without no-asm (they do appear to produce different results), using gcc. Thanks. The concrete values differ because test values are chosen at random; the important difference is that the no-asm test verifies OK (piping it to 'bc' prints only zeros, besides the text) while the 32-bit test with assembler code enabled (target 'irix-mips3-gcc') fails. In other words, crypto/bn/asm/mips3.s does not work as intended with the current BIGNUM library. Andy? -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_pending() and SSL_ERROR_WANT_READ
John Hughes [EMAIL PROTECTED]:
I can confirm: There is a discrepancy between the SSL_pending()
manpage and the source. SSL_pending() returns rrec.length in
ssl3_pending() (as of 0.9.6a, we also verify that the SSL record
being processed is application data, else zero is returned). This
variable is updated in ssl3_get_record() when an SSL record header
is processed. If the remainder of that SSL record has not yet been
received, SSL_pending() will return a non-zero value even though
there may not be that amount of data ready. This contradicts the
SSL_pending() manpage, which indicates that its return value
represents the amount of data immediately available. I haven't yet
examined whether SSLv2 connections experience the same problem.
This patch should fix the bug:
diff -u -r1.57 s3_lib.c
--- s3_lib.c2001/10/20 17:56:35 1.57
+++ s3_lib.c2002/03/14 19:20:58
@@ -943,6 +943,9 @@
int ssl3_pending(SSL *s)
{
+ if (s-rstate == SSL_ST_READ_BODY)
+ return 0;
+
return (s-s3-rrec.type == SSL3_RT_APPLICATION_DATA) ? s-s3-rrec.length : 0;
}
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Fixes for dh_gen.c
On Tue, Mar 19, 2002 at 08:40:18AM +, Jason Holt wrote: I've added the general form of generator checking to crypto/dh/dh_gen.c and fixed the uninitialized t1,t2 bug. It compiles, but I haven't really tested it. What I have so far is at: http://www.lunkwill.org/dh_gen.c I had not seen this message when I replied to the previous one. As this time I'm replying to the list and not via private mail, here's my previous response: Thanks. I now set t1 to 2 and t2 to 1 for 'non-standard' generators; i.e., any odd number is acceptable. I suppose this is the fix you had in mind? But the example call in dhtest.c indicates that you are not really supposed to call DH_generate_parameters with some integer as 'generator' argument -- instead, DH_GENERATOR_2 or DH_GENERATOR_5 can be used (these macros evaluate directly to 2 and 5, respectively, and no other DH_GENERATOR_... macros are defined). Actually the existing code is rather pointless. There is no reason to insist to use a generator of the multiplicative group. A generator of the order-q subgroup is, in some sense, better. So I suggest to keep the current behaviour for cases 2 and 5 (mostly for backwards compatibility), and not to worry whether the number is a generator otherwise. -- We should report an error for negative generators and for 0 and 1, though. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Fixes for dh_gen.c
On Tue, Mar 19, 2002 at 05:38:06PM +, Jason Holt wrote: I don't really understand the math very well. I assume that being a generator has something to do with ensuring that a^b%n has a long period as n increases. DH_generate_parameters() always uses a safe prime as modulus, i.e. p such that q = (p-1)/2 is prime as well. Thus, the factorization of p-1 is 2q, and this leads to a simple subgroup structure of the multiplicative group mod p: There's the subgroup consisting just of the element 1; there's the subgroup consisting just of the numbers 1 and p-1; there's a subgroup consisting of q elements; and there's the full group with 2q elements. Every g with 1 g p-1 generates either the q-element subgroup, or the 2q-element group. That is, g^b mod p always has a long period if we avoid pathological cases such as g = 1. g being a generator (also called a primitive root) means that it generates the the 2q-element group. This is what DH_generate_parameters() is designed to ensure for the cases g = 2 and g = 5. But this requirement is actually pointless: A g that generates the q-element subgroup is just as good as one that generates the 2q-element group. In fact prime-order subgroups are usually preferred for many cryptographic purposes; for DH, if properly used (e.g. in ephemeral DH TLS ciphers suites), the difference does not matter at all. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: DES...
On Thu, Mar 21, 2002 at 02:45:18PM -0500, Jeffrey Altman wrote: I prefer that des_old.h be compatible with libdes since that apps that are built using it assume that the api they were using was constant and unchanging. The way things work now, there is at least no clash with libdes on the symbol level. The whole situation is otherwise a lose-lose one. There will always be someone loseing from the changes we make. Either we lose libdes compatibility by default or we lose the openssl 0.9.6 one. Take your pick. It has been pointed out (and I think I agree) that OpenSSL should prefer to be as compatible with the previous version of itself before being compatible with anything external (like libdes). Yes, but let's remember the reason this whole situation came up in the first place. There are a large number of applications that link to both Kerberos 4 and OpenSSL in place of libdes.a. These applications are not likely to be updated nor supported and yet we don't want to see all of them break simply because they load des.h. Adding '-DOPENSSL_DES_LIBDES_COMPATIBILITY' to the compiler switches when compiling such applications should do the job. This is about as easy to do as linking with OpenSSL. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug in ssl3_read_bytes()
Alex Pankratov [EMAIL PROTECTED]:
the following problem is present in 0.9.6 and 0.9.6c.
It is possible to put server code into the internal infinite
loop in ssl3_read_bytes() by sending the following data from
the client right after establishing TCP connection:
01 03 01 00 01 00
[...]
The problem is in the code that was supposed to ignore unknown TLS
message types:
switch (rr-type)
{
default:
#ifndef NO_TLS
/* TLS just ignores unknown message types */
if (s-version == TLS1_VERSION)
{
goto start;
}
#endif
...
The code passes control back to start without resetting 'rr' length,
[...]
Thanks for the report. This bug has already been fixed some time ago,
see the snapshots at URL:ftp://ftp.openssl.org/snapshot;type=d.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: bug in ssl code
Arne Ansper [EMAIL PROTECTED]:
[...]
okey, the bug:
ssl3_read_internal function has special treatment for situations when
renegotiation is going on and the handshake and data packets are arriving
in random order.
now, if i have a non-blocking socket on server side and i use BIO SSL
interface to access it, without performing an explicit handshake using
BIO_do_handshake or SSL_accept before i start usign BIO_read, then
following may happen:
1) application calls BIO_read that will finally call ssl3_read_internal.
2) inside ssl3_read_internal the in_read_app_data flag is set.
3) ssl3_read_internal calls ssl3_read_bytes that will determine that
handshake is not performed and calls handshake function that in my case
was ssl3_accept.
4) ssl3_accept determines that the statemachine is never used before and
will call SSL_clear.
5) SSL_clear will reset in_read_app_data flag (actually it's ssl3_clear
that clears the flag).
6) ssl3_accept will advance the state machine and tries to read the Client
Hello message
7) when the Client Hello is not yet available (non-blokcing socket), it
will return with an error.
8) now the condition inside ssl3_read_internal function will be erronosly
satisfied: there is error present from ssl3_read_bytes function and the
in_read_app_data is reset.
[...]
Thanks for the detailed report. Please try this patch:
Index: s3_lib.c
===
RCS file: /usr/local/openssl/cvs/openssl/ssl/s3_lib.c,v
retrieving revision 1.39.2.7
diff -u -r1.39.2.7 s3_lib.c
--- s3_lib.c2002/03/15 10:53:34 1.39.2.7
+++ s3_lib.c2002/04/12 21:52:10
@@ -1315,13 +1315,12 @@
if (s-s3-renegotiate) ssl3_renegotiate_check(s);
s-s3-in_read_app_data=1;
ret=ssl3_read_bytes(s,SSL3_RT_APPLICATION_DATA,buf,len,peek);
- if ((ret == -1) (s-s3-in_read_app_data == 0))
+ if ((ret == -1) (s-s3-in_read_app_data == 2))
{
/* ssl3_read_bytes decided to call s-handshake_func, which
* called ssl3_read_bytes to read handshake data.
* However, ssl3_read_bytes actually found application data
-* and thinks that application data makes sense here (signalled
-* by resetting 'in_read_app_data', strangely); so disable
+* and thinks that application data makes sense here; so disable
* handshake processing and try to read application data again. */
s-in_handshake++;
ret=ssl3_read_bytes(s,SSL3_RT_APPLICATION_DATA,buf,len,peek);
Index: s3_pkt.c
===
RCS file: /usr/local/openssl/cvs/openssl/ssl/s3_pkt.c,v
retrieving revision 1.37.2.5
diff -u -r1.37.2.5 s3_pkt.c
--- s3_pkt.c2001/12/28 17:13:10 1.37.2.5
+++ s3_pkt.c2002/04/12 21:51:58
@@ -1114,7 +1114,7 @@
)
))
{
- s-s3-in_read_app_data=0;
+ s-s3-in_read_app_data=2;
return(-1);
}
else
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Small bugs in v3 client hello parsing
It seems that I've found two small bugs in OpenSSL (at least 0.9.6c
and the latest snapshot).
In ssl/s3_srvr.c function ssl3_get_client_hello, after the
last field (compression) has been parsed, there's a test:
/* TLS does not mind if there is extra stuff */
if (s-version == SSL3_VERSION)
{
if (p (d+n))
{
/* wrong number of bytes,
* there could be more to follow */
al=SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_LENGTH_MISMATCH);
goto f_err;
}
}
Here d points to the start of the message, p to the
current location, and n is the length of the frame.
There are actually two bugs: First, the test should of
course be p (d+n).
Thanks. This will be fixed.
Second, if p (d+n) then we have read past the end of the packet
anyway [...]
A test is missing earlier in the code. This should fix all the problems:
Index: s3_srvr.c
===
RCS file: /usr/local/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.49.2.13
diff -u -u -r1.49.2.13 s3_srvr.c
--- s3_srvr.c 2002/01/14 23:42:38 1.49.2.13
+++ s3_srvr.c 2002/04/13 22:17:58
@@ -711,7 +711,7 @@
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_NO_CIPHERS_SPECIFIED);
goto f_err;
}
- if ((i+p) (d+n))
+ if ((p+i) = (d+n))
{
/* not enough data */
al=SSL_AD_DECODE_ERROR;
@@ -768,6 +768,13 @@
/* compression */
i= *(p++);
+ if ((p+i) (d+n))
+ {
+ /* not enough data */
+ al=SSL_AD_DECODE_ERROR;
+ SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_LENGTH_MISMATCH);
+ goto f_err;
+ }
q=p;
for (j=0; ji; j++)
{
@@ -815,7 +822,7 @@
/* TLS does not mind if there is extra stuff */
if (s-version == SSL3_VERSION)
{
- if (p (d+n))
+ if (p (d+n))
{
/* wrong number of bytes,
* there could be more to follow */
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/ssl s3_pkt.c
On Mon, Apr 29, 2002 at 12:28:33PM +0200, [EMAIL PROTECTED] wrote:
Log:
Synchronise with 0.9.7-stable.
Revision ChangesPath
1.49 +2 -2 openssl/ssl/s3_pkt.c
Index: s3_pkt.c
===
RCS file: /e/openssl/cvs/openssl/ssl/s3_pkt.c,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- s3_pkt.c2002/04/20 10:23:19 1.48
+++ s3_pkt.c2002/04/29 10:28:29 1.49
@@ -245,7 +245,7 @@
extra=SSL3_RT_MAX_EXTRA;
else
extra=0;
- if ((size_t)extra != (s-s3-rbuf.len - SSL3_RT_MAX_PACKET_SIZE))
+ if (extra != (s-s3-rbuf.len - SSL3_RT_MAX_PACKET_SIZE))
{
/* actually likely an application error:
SLS_OP_MICROSOFT_BIG_SSLV3_BUFFER
* set after ssl3_setup_buffers() was done */
@@ -605,7 +605,7 @@
if (prefix_len = 0)
goto err;
- if (s-s3-wbuf.len (size_t)prefix_len +
SSL3_RT_MAX_PACKET_SIZE)
+ if (s-s3-wbuf.len prefix_len + SSL3_RT_MAX_PACKET_SIZE)
{
Here you reversing patches that you had committed for 0.9.8-dev but
not for 0.9.7-stable ...
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util pod2man.pl
On Thu, May 30, 2002 at 03:14:17PM +0200, Richard Levitte - VMS Whacker wrote: pod2man is a command line wrapper around Pod::Man these days, and depends on other Pod:: modules. Do you *really* want them to be included? If we can't update our copy of pod2man, we should at least keep the old one as a fallback if the system has no pod2man or it does not work properly. Otherwise expect tons of reports that 'make install' does not work. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util pod2man.pl
On Thu, May 30, 2002 at 03:39:21PM +0200, Richard Levitte - VMS Whacker wrote: Specifically, we'd have to test that multi-line NAME sections are handled correctly; it appears this bug was fixed only recently in the pod2man that comes with Perl. Hmm, I tested with doc/crypto/des.pod with the pod2man.pl we had before the small fix that supposedly fixed this (-r 1.1), and I can't see anything wrong with the output. If you could tell me what the difference is between a broken pod2man and a working one, I might be able to make an appropriate test... The bug reported that led to the change was Christoph Martin [EMAIL PROTECTED]: Wichert Akkerman writes: Package: openssl Version: 0.9.6-1 Severity: normal The HISTORY section of RAND_add(3ssl) isn't formated correctly, its end looks like this: RAND_event() in OpenSSL 0.9.5a. entropy to the PRNG The .pod file is incorrect. Apparently you are not allowed to have more than one line in the NAME section. The following patch fixes this. A later comment was The pod2man which comes with perl 5.6 has the same problem. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: make depend from Configure?
Richard Levitte - VMS Whacker [EMAIL PROTECTED]: In revision 1.81 of Configure, the automatic run of 'make depend' was commented out. IIRC, this was done because we had a dependency rebuild war happening a little now and then back then. Since then, we've unified the results of dependency generation with the domd script, so this kind of war doesn't really happen any more that I know of. Doug Kaufman very correctly points out that it's not documented that configuration with some algorithms removed requires a manual 'make depend', Does it? Disabling algorithms with './Configure no-... ...' should not require 'make depend' (when building from an OpenSSL release as opposed to a snapshot version where the links in include/openssl are missing). Only if you remove the corresponding parts of the source code tree you have to run 'make depend', and in this case you have done manual changes anyway. We could document this better, though. Or check that all the header files are there when Configure is run and do an automatic 'make depend' only if some are missing. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: getpid()
On Sat, Jun 01, 2002 at 01:18:35PM +0100, Ben Laurie wrote: Also, the thread id may be used elsewhere - is there any point if its actually the PID? Applications that are actually multi-threaded should (and indeed, on most platforms, must) use CRYPTO_set_id_callback() so that OpenSSL can use appropriate thread IDs. To use the PID is merely the default behaviour of CRYPTO_thread_id(). This is generally not good enough for most purposes that OpenSSL uses the thread ID for (it can be helpful for memory debugging in programs that use fork(), though). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #65] Ticket Resolved
On Thu, Jun 13, 2002 at 06:05:34PM +0200, Kambez Sadeq via RT wrote:
Any idea why web browsers such as MSIE and Opera work okay with the server?
I'm guessing that these browsers ignore invalid records.
No, the server (actually a broken proxy to a real server apparently)
does not send invalid records under certain conditions. I used
s_client to send the following lines and it worked:
GET / HTTP/1.1
Host: ebmx.extra.daimlerchrysler.com
But when faced with inappropriate Host lines, the server behaves
erratically. I can connect to it using Netscape, but if I tunnel
through localhost (so that the real target host is not named in
Host) I get plaintext error messages; see the following partial
connection transcript (the lines are an SSL encrypted HTTP
request [so you can't read anything], the lines are the server's
response, which is sent in cleartext).
000114 17 03 00 01 26 42 fc 09 da 38 85 b8 60 98 ea b1 B...8..`...
000124 be 49 13 66 71 42 ab 11 b9 25 df 47 f1 d9 69 7c .I.fqB...%.G..i|
000134 a6 f2 72 a0 2e e2 7c 0a 2b 91 a8 e5 6b 77 ef 95 ..r...|.+...kw..
000144 fe 64 e2 e3 db a6 12 4b 8c 96 ed c4 f9 16 2b 05 .d.K..+.
000154 9a 4d d6 59 2a f9 cf 68 7d a6 04 ba 87 bd 83 f4 .M.Y*..h}...
000164 24 16 e9 71 f0 b9 b6 b8 16 e9 16 24 5c c5 a6 8b $..q...$\...
000174 81 84 14 77 28 4e 4b eb a4 94 13 52 76 c1 5b 39 ...w(NKRv.[9
000184 8e bc 96 6f fa 1c ca 4e ee ec 69 a6 85 7c 7d 6e ...o...N..i..|}n
000194 73 a5 54 8a de 9c 82 2d 9e 25 82 4a 46 3e 06 79 s.T-.%.JF.y
0001a4 0c cc 8b 1f c0 9f 5c 95 40 e7 51 b6 d2 38 75 b7 ..\.@.Q..8u.
0001b4 68 91 60 f1 f8 1a c3 d1 97 13 c6 63 28 37 93 65 h.`c(7.e
0001c4 aa b4 f2 d1 49 6b 5f cf 66 e1 40 cc 66 01 b1 44 Ik_.f.@.f..D
0001d4 4e 24 2b 04 23 26 2e bf a1 ff 57 6c 2a 52 01 68 N$+.#Wl*R.h
0001e4 3e 99 b7 1b 5e 7b c3 6d 72 6a ce 3e 89 98 9f 38 ...^{.mrj8
0001f4 17 6d 5a dd 3a f7 52 cd 9b cc 5c a4 a4 83 02 a9 .mZ.:.R...\.
000204 50 36 32 b2 44 11 f9 45 b7 c7 d8 5f 9d 6c 24 e6 P62.D..E..._.l$.
000214 22 58 9a 01 58 ba 2b a8 f7 d0 ca 78 a8 2b cc d4 X..X.+x.+..
000224 29 75 fd 24 38 1d c6 30 df b5 f0 48 5d cd d2 01 )u.$8..0...H]...
000234 51 21 cf d8 99 ac 6b 3e 1b 66 90 Q!k.f.
000c63 48 54 54 50 2f 31 2e 30 20 35 30 30 20 45 72 72 HTTP/1.0 500 Err
000c73 6f 72 20 66 72 6f 6d 20 70 72 6f 78 79 0d 0a 4d or from proxy..M
000c83 69 6d 65 2d 76 65 72 73 69 6f 6e 3a 20 31 2e 30 ime-version: 1.0
000c93 0d 0a 50 72 6f 78 79 2d 61 67 65 6e 74 3a 20 4e ..Proxy-agent: N
000ca3 65 74 73 63 61 70 65 2d 50 72 6f 78 79 2f 33 2e etscape-Proxy/3.
000cb3 35 33 0d 0a 43 6f 6e 74 65 6e 74 2d 74 79 70 65 53..Content-type
000cc3 3a 20 74 65 78 74 2f 68 74 6d 6c 0d 0a 0d 0a 3c : text/html
000cd3 48 54 4d 4c 3e 0a 3c 48 45 41 44 3e 3c 54 49 54 HTML.HEADTIT
000ce3 4c 45 3e 45 72 72 6f 72 3c 2f 54 49 54 4c 45 3e LEError/TITLE
000cf3 3c 2f 48 45 41 44 3e 0a 3c 42 4f 44 59 3e 0a 3c /HEAD.BODY.
000d03 48 31 3e 45 72 72 6f 72 3c 2f 48 31 3e 0a 3c 42 H1Error/H1.B
000d13 4c 4f 43 4b 51 55 4f 54 45 3e 3c 42 3e 0a 3c 48 LOCKQUOTEB.H
000d23 52 20 53 49 5a 45 3d 34 3e 3c 50 3e 0a 54 68 65 R SIZE=4P.The
000d33 20 72 65 71 75 65 73 74 65 64 20 69 74 65 6d 20 requested item
000d43 63 6f 75 6c 64 20 6e 6f 74 20 62 65 20 6c 6f 61 could not be loa
000d53 64 65 64 20 62 79 20 74 68 65 20 70 72 6f 78 79 ded by the proxy
000d63 2e 3c 50 3e 0a 54 68 69 73 20 4c 6f 63 61 74 69 .P.This Locati
000d73 6f 6e 20 28 55 52 4c 29 20 69 73 20 6e 6f 74 20 on (URL) is not
000d83 72 65 63 6f 67 6e 69 7a 65 64 3a 0a 20 20 66 69 recognized:. fi
000d93 6c 65 3a 2f 0a 0a 43 68 65 63 6b 20 74 68 65 20 le:/..Check the
000da3 4c 6f 63 61 74 69 6f 6e 20 61 6e 64 20 74 72 79 Location and try
000db3 20 61 67 61 69 6e 2e 3c 50 3e 0a 0a 3c 48 52 20 again.P..HR
000dc3 53 49 5a 45 3d 34 3e 0a 3c 2f 42 3e 3c 2f 42 4c SIZE=4./B/BL
000dd3 4f 43 4b 51 55 4f 54 45 3e 0a 0a 3c 50 3e 0a 3c OCKQUOTE..P.
000de3 41 44 44 52 45 53 53 3e 50 72 6f 78 79 20 73 65 ADDRESSProxy se
000df3 72 76 65 72 20 61 74 20 6f 64 73 70 6e 70 72 34 rver at odspnpr4
000e03 2d 68 6d 65 30 2e 65 78 74 72 61 2e 64 61 69 6d -hme0.extra.daim
000e13 6c 65 72 63 68 72 79 73 6c 65 72 2e 63 6f 6d 20 lerchrysler.com
000e23 6f 6e 20 70 6f 72 74 20 34 34 33 3c 2f 41 44 44 on port 443/ADD
000e33 52 45 53 53 3e 0a 3c 2f 42 4f 44 59 3e 3c 2f 48 RESS./BODY/H
000e43 54 4d 4c 3e 0a TML.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL
Re: getpid()
On Thu, Jun 13, 2002 at 05:20:42PM +0100, Ben Laurie wrote: However, the number of calls is astonishing - and must be significantly expensive, too. Memory debugging *is* expensive. It is only enabled by default in debug configurations, where (starting with 0.9.7) it can be disabled by setting environment variable OPENSSL_DEBUG_MEMORY to off. (In non-debug configurations, it can be enabled by setting OPENSSL_DEBUG_MEMORY to a string other than off.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #85] 0.9.7 prototype constification problems
Avery Pennarun [EMAIL PROTECTED]: On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote: [[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]: It appears the openssl guys goofed in 0.97beta. The prototype for the d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this: d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length); ie., without a const on the second parameter. The const should have been done like this (I think): const unsigned char * const *pp ...which would be entirely backwards-compatible with old versions of openssl. Could you explain why you think this would improve compatibility (compared with 'const unsigned char **pp', which is how 'pp' should be declared in 0.9.7-beta1, although the exact definition is hidden behind macros)? Any variable that could be passed to a function taking unsigned char ** could also be passed to a function taking const unsigned char * const *. Thus, using the above declaration would make openssl's api 100% source-compatible with previous versions, while promising an increased level of constness. Using const unsigned char **, however, is not 100% api-compatible, because you can't safely pass an unsigned char ** to it, for complicated reasons explained in the URL I sent earlier. [http://www.geocrawler.com/archives/3/362/1997/9/0/2036587/] I see, so this is an C++ speciality. As far as C is concerned, the types should be incompatible between any of these three variants, but compilers tend not to look that close (and otherwise you'd use a cast). Writing code that tries to change a 'const char' object as shown at the above URL is possible -- the actual assignment is illegal, but in general the compiler cannot catch this. In fact the second 'const' would be wrong because the pointer that 'pp' points to is updated to reflect how much of the encoded data has been processed by the d2i_... function. I.e., it is not at all constant. Now, you caught me there. The change I proposed earlier (adding an additional const) would fix API compatibility, but promises a level of constness that you're not actually providing. Unfortunately, I don't know a way around it: the problem is that the beta1 level of constness looks right, but doesn't _actually_ promise the constness that it looks like it does, due to the crazy hackery described in the URL I sent earlier. Prototypes alone don't really guarantee constness anyway. If a function is passed a 'const int *' pointer and knows somehow that the object pointed to is not 'const' (i.e. the pointer was 'int *' originally), it may cast the pointer back to 'int *' and modify the object. It also makes the API incompatible with older versions. I can't pass the address of unsigned char *p to the new function. I guess you'll have to include a cast to the new type depending on the value of OPENSSL_VERSION_NUMBER. I know this is ugly, but I don't think we should un-constify the prototype to avoid such problems. (In fact we'll have to make various other prototype changes to clean up the API, for example 'int' quite often should be 'size_t' etc.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #85] 0.9.7 prototype constification problems
On Mon, Jun 17, 2002 at 07:02:45PM +0100, Ben Laurie wrote: Avery Pennarun via RT wrote: On Mon, Jun 17, 2002 at 11:19:31AM +0200, Bodo Moeller wrote: Good question, but this problem does not appear to apply to C, and anyway it only makes *existing* code uglier -- for new code, the modified API makes more sense (the encoded data can be in 'const unsigned char' arrays all the time). If you don't want #ifdefs and casts throughout your code, please consider hiding this in wrapper functions. Hmm, okay, I'm not really convinced, but now that I see it doesn't cause C programs to not compile, I think it's okay to accept the small number of openssl-using C++ programs that will need changes because of this. Hmm, well, I'm not, because all right-thinking projects have a zero-warnings policy. OpenSSL included. The old API is not perfect when the data is located in a 'const' array, the new API is not perfect when the data is located in a non-'const' array. C++ code can be written to match either the old or the new API; with the wrong API, you can have either zero warnings or zero casts, not both. As those functions are not really supposed to modify the data, the 'const' variant appears to be the right one. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl e_os.h
On Thu, Jun 27, 2002 at 03:48:34PM +0200, [EMAIL PROTECTED] wrote: Modified:.Tag: BRANCH_WIN64 e_os.h Log: With Win64, define ssize_t as size_t. This is a very odd thing to do, really, since size_t is supposed to be unsigned while ssize_t is supposed to be signed. However, this will have to do until I know more in this matter. --- e_os.h 2002/06/13 20:41:50 1.61 +++ e_os.h 2002/06/27 13:48:22 1.61.2.1 @@ -222,7 +222,11 @@ # include io.h # include fcntl.h -# define ssize_t long +# ifdef _WIN64 +#define ssize_t size_t +# else +#define ssize_t long +# endif # if defined (__BORLANDC__) #define _setmode setmode I'm pretty sure that this will break the logic of some of the code. 'long long' should work if it is available. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CBC vulnerability workaround
On Wed, Jul 03, 2002 at 09:54:15AM -0400, Jeffrey Altman wrote: Is there a summary somewhere of the changes that were made to the SSLv3 and TLSv1 message exchanges to avoid the vulnerability in the CBC cipher suites? I'm not aware of a proper summary of all the issues involved. In particular, I need to know: . the description of the vulnerability There's something at the following URLs: http://www.imc.org/ietf-tls/mail-archive/msg03273.html http://www.imc.org/ietf-tls/mail-archive/msg03387.html . a description of the workaround From CHANGES: *) Implement a countermeasure against a vulnerability recently found in CBC ciphersuites in SSL 3.0/TLS 1.0: Send an empty fragment before application data chunks to avoid the use of known IVs with data potentially chosen by the attacker. [Bodo Moeller] As the protocols don't explicitly reset CBC IVs, the IV for each block is known in advance (it's the last ciphertext block from the previous record). The attack works by choosing application data with knowledge of the IV that will be used for encrypting this data. Empty fragments (i.e. fragments with plaintext length zero) ensure that the known IV will not be used for application data, and that an unpredictable IV will be in use when the actual application data is processed in the following fragment. . a summary of why the workaround should be considered valid in the protocol I have found nothing in the SSL 3.0 and TLS 1.0 specifications that forbids fragments of length zero. The length is given as a 'uint16' value; the specification defines upper limits, but no lower limits. draft-freier-ssl-version3-02.txt (SSL 3.0): 5.2.1 Fragmentation The record layer fragments information blocks into SSLPlaintext records of 2^14 bytes or less. [...] RFC 2246 (TLS 1.0): 6.2.1. Fragmentation The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. [...] I have come across a large commercial user of SSL services for whom the workaround fails. The transmission of the data frame with no application data generates an SSL Alert causing the application to close the connection. The developers of the SSL library being used have replied that SSLv3 does not permit data frames containing no application data. Can they cite a particular provision in the specification that forbids records with a fragment length of zero? I haven't found one, and length-zero fragments are handled well by many implementations (including Microsoft IIS). But I am aware of compatibility problems. One way to avoid these is to use RC4 (which does not need the workaround). Also new OpenSSL versions (starting with 0.9.6e or 0.9.7) have an option for disabling the countermeasure, which is automatically enabled in many applications; from CHANGES: *) New option SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS for disabling the SSL 3.0/TLS 1.0 CBC vulnerability countermeasure that was added in OpenSSL 0.9.6d. As the countermeasure turned out to be incompatible with some broken SSL implementations, the new option is part of SSL_OP_ALL. SSL_OP_ALL is usually employed when compatibility with weird SSL implementations is desired (e.g. '-bugs' option to 's_client' and 's_server'), so the new option is automatically set in many applications. [Bodo Moeller] -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CBC vulnerability workaround
On Wed, Jul 03, 2002 at 12:07:01PM -0400, Jeffrey Altman wrote: Can they cite a particular provision in the specification that forbids records with a fragment length of zero? I haven't found one, and length-zero fragments are handled well by many implementations (including Microsoft IIS). [...] They are quoting: draft-netscape-ssl-v2 1.1 SSL Record Header Format In SSL, all data sent is encapsulated in a record, an object which is composed of a header and some non-zero amount of data Note that this is from the SSL 2.0 draft, it has nothing to do with SSL 3.0. (And anyway it does not say anything about the amount of *application* data -- it mentions the header, so the 'non-zero amount of data' is all the bytes that appear after the header, not just what is left after decryption). The SSL 3.0 draft is similar to RFC 2246. RFC2246 6.2. Record layer The TLS Record Layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary size. This wording only refers to the interface between the SSL/TLS record layer and higher layers. These 'blocks' are virtual items, they are not actual protocol data. When we look at how the record layer arranges the data, we are talking about 'fragments', not 'blocks'. RFC 2246 says that the 'blocks' are 'non-empty', but otherwise 'of arbitrary size'. Certainly the latter does not apply to fragments, so there is no reason to conclude that the former does -- not even by analogy. This is the next paragraph from RFC 2246: 6.2.1. Fragmentation The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Client message ^^ boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType may be coalesced into a single TLSPlaintext record, or a single message may be fragmented ^^ across several records). ^^ When OpenSSL inserts an empty fragment, it fragments a single message into multiple parts, the first of which happens to be empty. I concede that this might appear pointless as long as one doesn't know about the CBC security issues, but nothing in the specification speaks against it. (And, of course, security considerations speak for it.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: create_empty_fragment in do_ssl3_write seems to breaks renegotiation in IE 6.0
On Wed, Jul 03, 2002 at 01:57:26PM +0200, [EMAIL PROTECTED] wrote: I'm doing some testing of openssl. I'm realized that the 'create-empty-fragment' introduced in do_ssl3_write [OpenSSL 0.9.6d] to avoid IV weakness causes that IE 6.0 (other versions, too?) don't work if a client renegotiation is performed. Modifying the code to avoid these procedure, renegotiation will work OK. I don't think that renegotiation is a problem. The problem probably is the ciphersuite selected during renegotiation -- presumably you switch from RC4 to a DES-based cipher. Using RC4 avoids the problem with IE. OpenSSL 0.9.6e or 0.9.7 will allow disabling the empty-fragment method. This is useful when interoperability with MSIE is more important than security. You might want to try the latest beta for OpenSSL 0.9.7. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #141] Error while writing zero-length string
Martin Sjögren: When you write a zero-length string with SSL_write, OpenSSL signals a protocol-violating EOF even though no such thing has happened. My guess is that a zero returned is misinterpreted somewhere though I have not had time to dig through the source. SSL_write() with length 0 will return 0, and this return value is always interpreted as protocol-violating EOF according to the SSL_get_error() manpage (SSL_get_error() returns SSL_ERROR_ZERO_RETURN). This is an inconsistency, but even if we change SSL_write() to return a different value, the program will not work -- we cannot return a positive value, and negative values would be interpreted as errors too. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #127] AES draft cipher suites
Lutz Jaenicke: I have already worked in the cipher selection routines yesterday with respect to PR#130. I will add an appropriate NOTDEFAULT selection keyword that will cover cipher suites not selected by default. As this is a new feature I intend to only add it to 0.9.7 (and later). Technically spoken we have two things: * ALL: all ciphers _except_ eNULL (no encryption is left out) * DEFAULT: ALL ciphers, then ADH is removed, then some sorting We would therefore have two classes of non-selected ciphers: * NODEFAULT: meaning effectively ADH in the moment * NOALL: meaning effectively eNULL in the moment Of course, this distinction is not necessarily clear unless you look up the realization of DEFAULT and ALL. Should I realize both classes? Actually it would make sense from the logical point of view and in the documentation I would propose to use something like RSA:NODEFAULT:NOALL to unselect the unwanted ciphers. I propose NOALL instead of NONE in order to reflect its logic interaction with the ALL keyword. The NO prefix in NODEFAULT and NOALL could be misleading. (Of course, NONE isn't any better.) COMPLEMENT_OF_ALL and COMPLEMENT_OF_DEFAULT is clearer. It is also longer, but it may be worth it. I don't particularly like the RSA:NODEFAULT:NOALL example because the NO... or COMPLEMENT_OF_... group aliases are not really useful for *enabling* ciphersuites (it can be done, but this is quite pointless). Their real purpose is *disabling* ciphersuites: RSA:!COMPLEMENT_OF_ALL or RC4:!COMPLEMENT_OF_DEFAULT will enable all RSA ciphersuites with the exception of the eNULL ciphersuites, and RC4:!COMPLEMENT_OF_DEFAULT will enable all non-anonymous RC4 ciphersuites. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #141] Error while writing zero-length string
Martin Sjögren via RT [EMAIL PROTECTED]: Bodo Moeller: Martin Sjögren: When you write a zero-length string with SSL_write, OpenSSL signals a protocol-violating EOF even though no such thing has happened. My guess is that a zero returned is misinterpreted somewhere though I have not had time to dig through the source. SSL_write() with length 0 will return 0, and this return value is always interpreted as protocol-violating EOF according to the SSL_get_error() manpage (SSL_get_error() returns SSL_ERROR_ZERO_RETURN). This is an inconsistency, but even if we change SSL_write() to return a different value, the program will not work -- we cannot return a positive value, and negative values would be interpreted as errors too. Uh, the example code I whipped up doesn't give you SSL_ERROR_ZERO_RETURN, it gives you SSL_ERROR_SYSCALL. Correct, my mistake. I actually meant SSL_ERROR_SYSCALL (SSL_ERROR_ZERO_RETURN means that the connection has been shut down cleanly, and this return value would be totally incorrect in this case). I'd say that the problem isn't as much in SSL_write as in SSL_get_error. The error codes and success codes overlap :( SSL_read() and SSL_write() are not really meant to be called with zero length. The return value cannot be larger than zero when this is done, so SSL_get_error() will interpret the return value as an error indication. We could change SSL_read() and SSL_write() to return an actual error when they are called with length 0, but this might break programs that do such calls but don't rely on SSL_get_error() for them. I suppose it should be possible to change the implementations behind SSL_read() and SSL_write() (i.e. ssl3_read() etc.) to use an extra flag for the special case of zero length parameters so that SSL_get_error() will indicate success unless there really was some kind of error, but I'm not convinced this is worth the effort -- why call the functions with length 0 anyway? -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: bug in RSA_padding_check_SSLv23()
Rob Dugal [EMAIL PROTECTED]: I believe there is a bug in openssl function RSA_padding_check_SSLv23(). This function is supposed to verify that the data is padded with special PKCS #1 padding as described in SSL 3.0 draft/RFC 2246, App. E.2 Run the server without support for SSL3, and specify only a RSA ciphers. bash$ openssl s_server -accept 9990 -no_ssl3 -www -cipher RC4-MD5 Run the client without support for tls1 bash$ openssl s_client -connect localhost:9990 -no_tls1 Here is the server output: Using default temp DH parameters ACCEPT 10386:error:04072073:rsa routines:RSA_padding_check_SSLv23:sslv3 rollback attack:rsa_ssl.c:139: 10386:error:04065072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check failed:rsa_eay.c:341: 10386:error:140BB004:SSL routines:SSL_RSA_PRIVATE_DECRYPT:nested asn1 error:s2_srvr.c:966: 10386:error:140EC071:SSL routines:SSL2_READ_INTERNAL:bad mac decode:s2_pkt.c:265: Since the server cannot negotiate SSL2, but the client has requested SSL3, the special PKCS #1 padding is required. Exactly, and this is why the handshake *must* fail. The only common protocol in the above case is SSL 2.0, but the special PKCS #1 padding instructs the server to refuse rolling back to SSL 2.0. 'openssl s_server -no_ssl3' (which leaves SSL 2.0 and TLS 1.0 enabled and disables only the intermediate protocol version, SSL 3.0) is a bad choice: Automatical protocol version negotion in SSL/TLS assumes that implementation support consecutive protocol versions. (Had you run the test the other way around ['s_server -no_tls1' and 's_client -no_ssl3'], the handshake would obviously have to fail because it is the server that picks the protocol version for the connection -- SSL 3.0 in this modified scenario, i.e. a protocol not support by the client.) With the suggested fix the above test can successfully handshake. It is intentional that the handshake fails. Note that the error is detect within the SSL 2.0 implementation (s2_pkt.c, s2_srvr.c). Whenever an SSL/TLS server detects the special padding in a connection for which protocol version SSL 2.0 has been chosen, it must interpret this as a protocol rollback attack unless SSL 2.0 is the only protocol version enabled in the server. Your suggested change would reverse the test condition, which cannot be correct. In those cases where special padding should not abort the SSL 2.0 handshake (because the server supports no newer protocol), the test must be completely disabled. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL patches for other versions
On Tue, Jul 30, 2002 at 03:50:17PM +0300, Arne Ansper wrote: These patches are known to apply correctly but have not been thoroughly tested. As I understand it, OpenSSL will call abort() when it detects attack against any hole in SSL. Not quite. The attacks against known holes are shielded by proper error handling. The 'die()' lines that might call 'abort()' are essentially 'assert()' lines, and they are just for additional protection: There should be now way for an attacker to trigger an 'abort()', but if there is still some problem left, an 'abort()' is better than a buffer overflow. (The reason that we are using 'abort()' now instead of generating 'internal error' error message is that we wanted to release the fix as soon as possible.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #170] OpenSSLDie not exported in Win32
On Tue, Jul 30, 2002 at 06:08:46PM +0300, Arne Ansper wrote: attached is a patch for openssl-0.9.6e that removes the usage of die. please review it carefully. all changes are localized but the action i take in some places where error reporting is not possible might be little bit wrong (i.e. in ssl2_generate_key_material(). this is void function, so i cannot indicate error). Thanks for the patch. For static functions, you can safely change void into int so that you can indicate the errors properly. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util mkerr.pl
Ben Laurie [EMAIL PROTECTED]: As noted elsewhere, I really object to returning internal errors! It makes no sense to attempt to continue after the impossible has occurred. If we could be absolutely sure that these events are strictly impossible, then it wouldn't make a difference if we call abort(), return an internal error, or post a coredump to alt.binaries: nothing of this could ever happen. In fact we don't continue -- we return an error, meaning that the current handshake will be aborted. Of course the point is that one of the events might not be that impossible after all if there are still hidden bugs. So what would this mean? If the internal structures are totally screwed up, then an abort() might be the best we can do. But that's not the case for those internal error cases (or the one that was considered an internal error in the initial patch but turned out to be a protocol error): what really may have happened is that a buffer that has been allocated turns out to be of insufficient size. We test this *before* accessing the buffer and return an internal error *instead*, so what bad thing could happen? -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util mkerr.pl
On Tue, Aug 13, 2002 at 05:10:34PM +0100, Ben Laurie wrote: Bodo Moeller wrote: Ben Laurie [EMAIL PROTECTED]: As noted elsewhere, I really object to returning internal errors! It makes no sense to attempt to continue after the impossible has occurred. If we could be absolutely sure that these events are strictly impossible, then it wouldn't make a difference if we call abort(), return an internal error, or post a coredump to alt.binaries: nothing of this could ever happen. In fact we don't continue -- we return an error, meaning that the current handshake will be aborted. Yes, and the application will continue as if it were sensible to do so. In fact it *is* often sensible to do so because such supposedly impossible events are triggered by certain conditions (such as unusual parameters in a certain protocol version) that will not apply to all connections. In such cases we cannot continue the one connection where a potential buffer overflow was detected, but there's no reason to completely kill the application. The internal error terminates the single connection for which OpenSSL does not know how to continue. There is no reason why this should affect the rest of the program. We test this *before* accessing the buffer and return an internal error *instead*, so what bad thing could happen? The application could continue to run with corrupt memory, thus exposing it to an unknown exploit, in the case where the error really is internal and not a protocol error. The consistency checks don't detect that memory *has* been corrupted. They detect that memory *would* be corrupted if the library simply continued to do what it is doing. But if we return an internal error, this does not actually happen. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util mkerr.pl
On Tue, Aug 13, 2002 at 08:09:02PM +0200, Lutz Jaenicke wrote:
On Tue, Aug 13, 2002 at 07:45:30PM +0200, Bodo Moeller wrote:
On Tue, Aug 13, 2002 at 05:10:34PM +0100, Ben Laurie wrote:
Yes, and the application will continue as if it were sensible to do so.
In fact it *is* often sensible to do so because such supposedly
impossible events are triggered by certain conditions (such as
unusual parameters in a certain protocol version) that will not apply
to all connections. In such cases we cannot continue the one
connection where a potential buffer overflow was detected, but there's
no reason to completely kill the application. The internal error
terminates the single connection for which OpenSSL does not know how
to continue. There is no reason why this should affect the rest of
the program.
I think we should define our terms clearly.
For me an internal error is an error that must not occur at all and
that can only have appeared due to the library having failed somehow
such that an inconistent state occurs (in M$-notation: an unexpected
error occured :-). I consider an error like this to be fatal and think
that it is still sensible to abort().
By definition we have no explanation on how this could happen and so
we don't know how to continue.
Example: when working through the internal session cache we learn, that
the linked list is corrupted, we have dangling pointers and don't know
what is going on. This would touch all threads using the same SSL_CTX.
Thus: we don't know how to repair it - abort().
This is an example of an internal error where we do not know how to
continue.
But for various other potential errors, we do know what happened
(e.g. a buffer has insufficient size) and we do know how to continue
without doing significant harm (abort this one TLS/SSL connection, and
in a way such that we have a likelihood of seeing a useful error
message in some log file). These are still internal errors.
For example, here is a consistency check I added in April when I
implemented the empty fragment protocol weakness workaround
(ssl/s3_pkt.c):
if (s-s3-wbuf.len (size_t)prefix_len +
SSL3_RT_MAX_PACKET_SIZE)
{
/* insufficient space */
SSLerr(SSL_F_DO_SSL3_WRITE, ERR_R_INTERNAL_ERROR);
goto err;
}
The buffer is allocated by the SSL library, but this happens
elsewhere, so it's safer not to rely on buffer allocation being
sufficient for what I plan to do with the buffer. If the buffer is
not sufficient, this would be a bug in OpenSSL.
If we have protocol errors to catch or errors in using the API (a function,
even an internal one was called with incorrect parameters, maybe a string
is too long), we can oversee the error and its impact, prevent the impact
and return with a corresponding failure message. We do this for a large part
of the public API, so we can also build in additional safety nets that
generate error messages and consequently result in a normal handshake
failure.
Yes, but we can also continue with a normal handshake failure for
various errors that are clearly internal.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl CHANGES
On Wed, Aug 14, 2002 at 12:52:37PM +0200, Richard Levitte - VMS Whacker wrote: bodo bodo14-Aug-2002 12:49:35 bodo bodo Modified:.CHANGES bodo Log: bodo add 'TODO' items Don't these go into the STATUS file, usually? Only when noone is really working on them at the moment :-) Temporary 'TODO' items in CHANGES shouldn't hurt. The CHANGES entry for ECDH is useless if you don't also know that the interface is going to change, so it appeared appropriate to add this 'TODO' to CHANGES. The second 'TODO' doesn't really belong there, but these two will most likely be handled simultaneously, so I preferred not to split them. The earlier 'TODO' item (the one one COMPLEMENTOF...) should disappear from CHANGES, though. I added it because I thought the fix would come quite soon, but now it looks as if it may take a little longer than expected. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util mkerr.pl
On Wed, Aug 14, 2002 at 01:24:32PM +0300, Arne Ansper wrote: [...] what if some standalone application thinks that the best solution for _its own_ problems is to reboot the machine? (happens all the time under the windows btw, you install some crap and the installer happily reboots your system). for me it's not different if some library thinks that the best solution for _its own_ problems is to kill the application. the application must have a control. Exactly. if the internal error (it would be correct to call them bugs, btw) happens When in internal error happens, this is because of a bug, but the internal error is not the bug. A bug is a property, not an event. application must get this information and then it's up to the application to deal with it. if it's simple commandline tool it can call abort by itself. if its complex application it might unload the openssl and reload it later. or save its state and restart. only application knows what the right thing to do is. Also only if the application sees an error message, it has the opportunity to write this message to a logfile. With 'abort()', all you know is that the program is no longer running, but you usually have no idea why this happened. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util mkerr.pl
On Wed, Aug 14, 2002 at 01:53:29PM +0100, Ben Laurie wrote: The consistency checks don't detect that memory *has* been corrupted. They detect that memory *would* be corrupted if the library simply continued to do what it is doing. But if we return an internal error, this does not actually happen. Not so - they detect that an impossible condition has occurred, so we do not know whether corruption (or other nastiness) has already occurred or not. Yes, but if you look at the tests, it is quite obvious that the typical reason for something impossible happening is that a buffer is too small for its purpose, and that it is quite unlikely that memory has already been corrupted before the consistency check (and, thanks to the consistency check, memory won't be corrupted at all). Just look at your patch, these are the first checks that you added: + die(s-s2-conn_id_length = sizeof s-s2-conn_id); memcpy(s-s2-conn_id,p,s-s2-tmp.conn_id_length); + die(i = SSL_MAX_KEY_ARG_LENGTH); if (i 0) RAND_pseudo_bytes(sess-key_arg,i); + die(i = sizeof sess-master_key); if (RAND_bytes(sess-master_key,i) = 0) + die(karg = sizeof sess-key_arg); memcpy(d,sess-key_arg,(unsigned int)karg); -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util mkerr.pl
On Wed, Aug 14, 2002 at 01:57:32PM +0100, Ben Laurie wrote:
[...]
But for various other potential errors, we do know what happened
(e.g. a buffer has insufficient size) and we do know how to continue
without doing significant harm (abort this one TLS/SSL connection, and
in a way such that we have a likelihood of seeing a useful error
message in some log file). These are still internal errors.
For example, here is a consistency check I added in April when I
implemented the empty fragment protocol weakness workaround
(ssl/s3_pkt.c):
if (s-s3-wbuf.len (size_t)prefix_len +
SSL3_RT_MAX_PACKET_SIZE)
{
/* insufficient space */
SSLerr(SSL_F_DO_SSL3_WRITE, ERR_R_INTERNAL_ERROR);
goto err;
}
The buffer is allocated by the SSL library, but this happens
elsewhere, so it's safer not to rely on buffer allocation being
sufficient for what I plan to do with the buffer. If the buffer is
not sufficient, this would be a bug in OpenSSL.
The buffer is _supposed_ to be big enough. We know of no path through
the code that should cause it to be not big enough. So if this condition
occurs something we don't understand has happened.
Quite in contrary, this would be quite easy to understand: if the
condition fails, the overhead for the empty fragment taken into
account during buffer allocation apparently was an underestimate,
possibly because a new cipher suite uses a block cipher with an
unusually large block size, or because TLS padding to larger lengths
has been implemented. There is no known path through that current
OpenSSL code such that the condition can fail (as far as I know), but
inconsistencies might be introduced with future changes in the SSL
library. Inconsistencies of this type are no reason to completely
abort the application.
For most of the consistency checks that your patch added, a failure
would very likely indicate that there is an inconsistency in the
OpenSSL source code similar to the potential inconsistency discussed
above. Those checks do not appear to be targeted at testing whether
memory was somehow corrupted at run-time. (Tests of the latter kind
are possible [e.g. magic constants in structs], but no such approach
is visible in your patch.)
Continuing under
these circumstances as if nothing were wrong strikes me as foolhardy.
Certainly there may be conditions under which it is unwise to
continue, but I don't think the ones detected by your patch
are among them.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util mkerr.pl
On Wed, Aug 14, 2002 at 03:39:03PM +0100, Ben Laurie wrote: So how did the buffer get to be too small? Well, in one of the cases it was improper protocol data checking (fixed in 0.9.6f). The others should really be impossible, but if they ever become possible, this most likely is because of changes to OpenSSL that are done without thinking of all the ramifications (e.g. new ciphersuites that require larger buffers for certain purposes). I propose we have a compile time flag that determines whether impossible conditions are fatal or return errors, Go ahead, compile time flags are how we usually handle such things in OpenSSL -- e.g. you can define BN_DEBUG to enable certain assertions that detect situations where memory is really corrupted. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util mkerr.pl
On Wed, Aug 14, 2002 at 08:42:47PM +0100, Ben Laurie wrote: I propose we have a compile time flag that determines whether impossible conditions are fatal or return errors, Go ahead, compile time flags are how we usually handle such things in OpenSSL -- e.g. you can define BN_DEBUG to enable certain assertions that detect situations where memory is really corrupted. Good. Now we have to debate what the default setting of the flag is. I propose, naturally, that it should be set to cause death on internal errors. Whatever decision we make, the same scheme should also be applied to asserts found elsewhere in the library. The current pattern is to define NDEBUG unless the respective DEBUG option is set. As you noted that assert() (with output to stderr) may be more dangerous than a straight abort(), the new OpenSSL_assert() macro (as it might be called) should be used everywhere in place of assert() (except possibly when a DEBUG option is set). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #274] session ID length bug (in 0.9.6g and 0.9.7beta3)
On Thu, Sep 19, 2002 at 01:44:01PM +0200, Bodo Moeller via RT wrote: I don't know why that message is empty. What I wrote is that this should now be fixed in the current snapshots (0.9.6-stable and 0.9.8-dev -- seems I forgot about 0.9.7-stable, this will have the fix tomorry). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Thu, Sep 19, 2002 at 06:28:16PM -0700, Patrick McCormick wrote:
No locking should be needed because the assignments are idempotent.
However, the assignments are not atomic. The following unprotected
operation:
if (init)
{
memcpy((char *)SSLv3_server_data,(char *)sslv3_base_method(),
sizeof(SSL_METHOD));
SSLv3_server_data.ssl_accept=ssl3_accept;
SSLv3_server_data.get_ssl_method=ssl3_get_server_method;
init=0;
}
can result in a thread calling .ssl_accept or .get_ssl_method after the
memcpy but before the assignment.
Can you elaborate? In such cases the other thread should execute the
'if' body too. A potential problem is not about atomicity, but about
reordering of statements (if the assignment to 'init' happens before
on of the other assignements, we have a problem), so it might be
better to make those static variables 'volatile'.
(I'm aware that the code still is bad in theory, but it should work
for all implementations. There's more stuff like that in OpenSSL, but
I can't rewrite all of it ...)
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Tue, Sep 03, 2002 at 05:29:41PM -0700, Patrick McCormick wrote:
I needed to add the following calls in my single-thread openssl setup code
to end several race conditions:
SSLv23_client_method();
SSLv2_client_method();
SSLv3_client_method();
TLSv1_client_method();
SSLv23_method();
SSLv2_method();
SSLv3_method();
TLSv1_method();
SSLv23_server_method();
SSLv2_server_method();
SSLv3_server_method();
TLSv1_server_method();
ssl2_get_cipher_by_char(XXX);
ssl3_get_cipher_by_char(XXX);
These functions appear to follow the same pattern (the
..._get_cipher_by_char functions actually use locks because they do
more than just simple assignments and copying).
I also see race conditions in crypto/rand/md_rand.c that I don't see a
workaround for. There's an init race in ssleay_rand_bytes. Multiple
threads can call in and end up in the initialization code if init==0. I'm
not sure why there is a lock around if (init), since this lock doesn't
prevent multiple initialization.
These threads then both call RAND_seed (ssleay_rand_seed, for me) at once.
ssleay_rand_seed modifies globals without any locking, so it doesn't appear
thread safe.
Er, what version of OpenSSL are you looking at? In 0.9.6g, we have
static int ssleay_rand_bytes(unsigned char *buf, int num)
{
[...]
CRYPTO_w_lock(CRYPTO_LOCK_RAND);
/* prevent ssleay_rand_bytes() from trying to obtain the lock again */
CRYPTO_w_lock(CRYPTO_LOCK_RAND2);
locking_thread = CRYPTO_thread_id();
CRYPTO_w_unlock(CRYPTO_LOCK_RAND2);
crypto_lock_rand = 1;
if (!initialized)
{
RAND_poll();
initialized = 1;
}
so the call to RAND_poll() (and eventually to ssleay_rand_see())
happens inside the write lock, meaing that only a single thread can do
this at a time.
ssleay_rand_bytes modifies globals (md, md_count, etc.) without locking, so
the random byte buffer can be filled from md while another thread is
rewriting the contents of md. Also, md_count[0]++ has undefined
results.
md_count[0] += 1 and access to md happens while the thread has the
CRYPTO_LOCK_RAND lock. Some accesses to the state array are not
protected by locking, however, because it does not really matter which
thread wins.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Mon, Sep 23, 2002 at 04:26:00PM +0200, Bodo Moeller via RT wrote: Somehow the RT2 system doesn't like the comments I enter at the website when resolving a ticket ... I wrote that the next snapshots should solve the problem. Functions SSLv23_client_method(), SSLv23_server_method(), SSLv2_client_method(),SSLv2_server_method(), SSLv3_client_method(),SSLv3_server_method(), TLSv1_client_method(),TLSv1_server_method() now use a lock. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Tue, Sep 24, 2002 at 03:47:14PM -0700, Patrick McCormick wrote:
Many thanks for putting in a lock. However, the race condition has not been
eliminated.
[...]init must be checked after the lock is entered in order to
prevent the client_data setup from happening twice. So, add:
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL_METHOD);
if (init)
{
}
CRYPTO_w_unlock(CRYPTO_LOCK_SSL_METHOD);
}
You are absolutely right, of course. I got similar constructs right
in the past, but I guess this time I was too busy with various other
things to really think about what I was writing ...
The next snapshot should really fix the problem.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #291] race condition in *get_cipher_by_char
On Wed, Sep 25, 2002 at 05:31:08PM +0200, Bodo Moeller via RT wrote: As usual, I really wrote that the bug will be fixed in the next snapshot (but RT2 still does not believe me :-). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Adding Certicom licensing info
On Wed, Sep 25, 2002 at 08:49:47AM -0400, John O Goyo wrote: Certicom has intellectual property rights relating to safe primes in DH [...] + Certicom has intellectual property rights relating to the use of safe primes + in the DH key-exchange, including US patent 5,933,504 and pending US + and non-US applications, [...] Can you elaborate? US patent 5,933,504 was filed in 1997, and using safe primes for DH was not new back then. URL:http://groups.google.com/groups?selm=2odko3%24jsf%40qualcomm.comoutput=gplain From: [EMAIL PROTECTED] (Phil Karn) Newsgroups: sci.crypt Subject: Re: Searching for primes Date: 12 Apr 1994 08:05:23 GMT Organization: 843rd Bomb Wing, Burpelson AFB Lines: 18 Distribution: world Message-ID: 2odko3$[EMAIL PROTECTED] References: [EMAIL PROTECTED] 2numd7$[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] NNTP-Posting-Host: unix.ka9q.ampr.org I'm following this discussion with interest because I'm currently generating some prime moduli for use with Diffie-Hellman. (DH is now included in RSAREF, so I'm using it as the basis of an experimental IP security protocol). My understanding of the criteria for a DH modulus p is that both p and (p-1)/2 should be prime, i.e, p should be a strong prime. I know that strong primes are no longer thought to be required for RSA key generation, but I understand that they're still a good idea for DH, which depends on the discrete logarithm problem rather than factoring (see LaMacchia's and Odlyzko's 1991 paper on discrete logarithms, URL http://martigny.ai.mit.edu/~bal/field.ps). Is this still the current consensus? Phil -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: possible bug in BN_dec2bn()
On Mon, Oct 14, 2002 at 12:52:30PM +0200, Richard Levitte - VMS Whacker wrote: The problem seems to be manifested in BN_dec2bn() because of the BN_mul_words and BN_add_words (e.g. line b). Since the upper parts of d aren't cleared out, those routines end up adding to whatever junk happened to be left in d from the previous iteration. Thanks, I found the bug. It seems like BN_add_word() (and BN_mul_word()) advances top without zeroing the next word. The result is that the value of that next word gets added to whatever is given as the next word to add. The simplest (and fastest, I believe) way to handle that is to have those functions zero the next word if top advances. Another theory is that any words in the array between 'top' and 'max' are supposed to be zero -- there's much code with the sole purpose to achieve this. The problem is that this does not *always* happen (otherwise this would not haven been a bug, and I believe there are other cases); so maybe we can say that these words are zero for aesthetical reasons, but technically are 'don't care'. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL init races (WAS: Any updates on 0.9.6.(h))
Miles Sabin [EMAIL PROTECTED]: First, the init flag needs to be volatile to prevent an aggressive compiler from optimizing away the second check (nb. there may be issues with compilers respecting volatile as mentioned in the key zeroizing thread). I know it should really be volatile (is someone willing to prepare a patch to this effect?), but this won't really make a difference unless the linker is in fact a global optimiser. If optimisation is per object code file (and the linker is really just a linker), the compiler has no idea what CRYPTO_w_lock() does: the function call to CRYPTO_lock() in the CRYPOT_w_lock() macro could, in principle, involve a recursive call to the calling function and thus could affect the 'init' flag. Thus the compiler can't optimise away the second check. Second you need to deal with MP cache coherency (Alpha, Itanium, others?). Memory models can be so weak that reads and writes to the same address can be reordered, and a write from a thread on one CPU isn't guaranteed to be immediately visible to a subsequent read from a thread on another. What do the C standards guarantee if we use 'volatile static'? Putting those two together, I think we end up with something like, [...] (nb. adapted from [1], so don't shoot me if I haven't got it exactly right) Your proposed code can't work as intended (your 'tmp' flag is a local copy of 'init', so the second check is redundant). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL Bug
On Thu, Nov 14, 2002 at 11:14:49AM +0100, Lutz Jaenicke wrote: On Wed, Nov 13, 2002 at 04:14:54PM -0800, Jeremiah Gowdy wrote: I was doing application development (not the topic of this email) interacting with an IBM developed SSL library. I experienced unexpected disconnects immediately after the SSL handshake takes place. According to the IBM developer, this is an OpenSSL bug due to an extra 24 bytes supposedly sent by OpenSSL after the handshake is complete. You are probably experiencing an effect caused by the following change for 0.9.6d: *) Implement a countermeasure against a vulnerability recently found in CBC ciphersuites in SSL 3.0/TLS 1.0: Send an empty fragment before application data chunks to avoid the use of known IVs with data potentially chosen by the attacker. For background, see URL:http://www.openssl.org/~bodo/tls-cbc.txt. In order to work around this incompatibility, the following new option was introduced for 0.9.6e: *) New option SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS for disabling the SSL 3.0/TLS 1.0 CBC vulnerability countermeasure that was added in OpenSSL 0.9.6d. This option is automatically enabled, if SSL_OP_ALL is set, please see the SSL_CTX_set_options manual page. Please update your version of OpenSSL, as beyond this particular problem 0.9.6d is known to have security vulnerabilities!!! Best regards, Lutz PS. Whether this is considered to be a bug on OpenSSL's side, or whether OpenSSL is correct in sending an empty fragment and the peer's software is incorrect, is another topic. OpenSSL clearly behaves according to the SSL 3.0 and TLS 1.0 specifications. If the IBM SSL library does not tolerate the empty fragments, then this is a bug that should be fixed in that library. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: man page location
On Sun, Jan 26, 2003 at 01:31:48PM -0800, Tim Rice wrote: I looks like man pages are being installed in the wrong place on non default installs. Ie. --prefix=/usr --openssldir=/etc/ssl It is intentional that we use the --openssldir value rather than the --prefix value in such cases. Files installed to --prefix are only those for which we can be reasonably sure that we don't have conflicts with unrelated software. This is not the case for our man pages (our foo.1 manpage documents 'openssl foo', not some program called 'foo', except that if you call the 'openssl' binary using a link called 'foo', it will automatically behave accordingly). A possible solution to this problem that has been considered was using OpenSSL-specific manpage sections (e.g. use man1openssl rather than man1). Open questions are how to name the section (how long can the section suffix be -- if portability dictates that we can use just a single letter, which letter is safe to use?). Currently if you want to view OpenSSL manpages you should set MANPATH accordingly (or use an appropriate option to 'man') -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error
Arne Ansper [EMAIL PROTECTED]: Like I say, they should only do this if there was an error reported, surely? No. Take a look at the SSL_CTX_use_certificate_chain_file: ret=SSL_CTX_use_certificate(ctx,x); if (ERR_peek_error() != 0) ret = 0; /* Key/certificate mismatch doesn't imply ret==0 ... */ Actually I think this is a bug in SSL_CTX_use_certificate() -- if it intentionally ignores an error returned by X509_check_private_key(), it should call ERR_clear_error(). The reason why I did not fix this when I looked at this some time ago is some rather weird code in ssl_set_cert(), the function used by SSL_CTX_use_certificate() from which X509_check_private_key() is called. (If you look at ssl_set_cert(), you'll see that it switches from SSL_PKEY_DH_RSA to SSKL_PKEY_DH_DSA and the other way around, which does not appear to make much sense.) Investigating this has been on my to do list for a while. Once this has been resolved, the lines if (ERR_peek_error() != 0) ret = 0; /* Key/certificate mismatch doesn't imply ret==0 ... */ can be removed from SSL_CTX_use_certificate_chain_file(). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl req prompting behavior
On Wed, Jan 22, 2003 at 04:20:37PM -0600, Joel Daniels wrote: The openssl req command, when set up to prompt for the Distinguished Name, uses fgets() to read the Distinguished Name fields. This means that if someone uses the backspace key, a 0x08 character is inserted wherever they typed the backspace key. If the backspace key results in a 0x08 character and this is not what you want, then you should either call stty erase '^h' before starting openssl req ... or reconfigure the keyboard so that the backspace key sends 0x7f (DEL) instead. This has nothing to do with OpenSSL; you'll observer the same behaviour if you run, say, 'cat'. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Win32 update to the ssleay32.def file
On Tue, Feb 04, 2003 at 04:32:24PM -0500, Joseph Ferner wrote: In OpenSSL 0.9.7 SSL_add_dir_cert_subjects_to_stack (ssl_cert.c) was added for Win32 but was omitted in the ssleay32.def file. Could this be added? Thanks for the report, this is now fixed. It would also be nice to have ssl3_send_alert (s3_pkt.c) in the .def file as well. OpenLDAP with SSL support would then compile without complaining on Win32. ssl3_send_alert() is not part of the officially exported API (you don't find in anywhere in include/openssl/*.h), so it is correct that it does not appear in the .def file. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: S/MIME PKCS7 and the famous CRLF
On Tue, Feb 11, 2003 at 10:51:56AM +0100, Holger Sesterhenn wrote: I am playing around with PKCS7 mails and also have noticed the small gliches when dealing with multipart/mime. (yes, I have spent some time reading groups.google and the mailing list archives). If I understand RFC2046 correctly every line ends with an CRLF. The function PKCS7_sign() fransfers the data to be signed to the canonical form using SMIME_crlf_copy(). Thats pretty nice. SMIME_write_PKCS7() and B64_write_PKCS7() just use BIO_printf() with a single \n for the EOL, especially when writing the boundary strings. OK, thats not a real big mistake and most MTAs/MUAs do handle this releaxed but I think if we have a RFC we should stick to it. And the other reason is that I have to use a program (for which I don't have the source code) which crashes without CRLF. The current workaround is to copy the whole mail again with something like my_crlf_copy(). That is a little bit annoying if you deal with some hundred mails bigger than 10 MB within a few minutes... What is you opinion? There has been some discussion on that previously on this mailing list. Please review ticket 151 at https://www.aet.tu-cottbus.de/rt2/ or read that thread in a mailing list archive: http://groups.google.com/groups?selm=ah0d18%241qf9%241%40FreeBSD.csie.NCTU.edu.tw If you want to add something, please use the request tracker and add to ticket #151. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
IMPORTANT: please test snapshot openssl-0.9.7-stable-SNAP-20030214.tar.gz
Please test snapshot openssl-0.9.7-stable-SNAP-20030214.tar.gz (or later), which will be available today around 8 p.m. GMT at URL: ftp://ftp.openssl.org/snapshot;type=d . We plan to release version 0.9.7a soon (next week if all goes well). OpenSSL 0.9.7a will be a bugfix release based on 0.9.7; thus there will be no beta releases. The snapshot should solve most problems that have been reported to [EMAIL PROTECTED]; please test it to help us avoid unforeseen problems with the new release. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #511] BUG: crypto/ec/ec_key.c:EC_KEY_dup()
Bodo Moeller via RT [EMAIL PROTECTED]: [nothing] RT has cut off the message, which said that the fix will be in the next snapshot (which should be the latest snapshot by now). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/crypto/asn1/ d2i_pu.c i2d_pu.c openssl/crypto/e...
On Fri, Feb 21, 2003 at 02:58:24PM +0100, Bodo Moeller wrote: Log: ECPublicKey_set_octet_string and ECPublicKey_get_octet_string behaviour was not quite consistent with the conventions for d2i and i2d functions as far as handling of the 'out' or 'in' pointer is concerned. This patch changes this behaviour, and renames the functions to o2i_ECPublicKey and i2o_ECPublicKey (not 'd2i' and 'i2d' because the external encoding is just a raw object string without any DER icing). The 'd' in 'd2i' and 'i2d' refers to DER, doesn't it? (I suggested using these new 'o2i' and 'i2o' names.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #541] Problem with the blinding patch
Bobco, Pete [EMAIL PROTECTED]: After applying the March 17, 2003 RSA Blinding patch, I am seeing some intermittant problems when I browse to my test server to retrieve pages. Sometimes a GIF file does not appear, but using the Refresh key will get it. I am wondering if anyone else out there is seeing similar oddities. Are there any server-side OpenSSL error messages? Background: My scenario is using OpenSSL 0.9.6i as the baseline. [...] On a side note, it looks to me like the openssl-0.9.7-stable-SNAP-20030320 build mentioned below DOES NOT contain the RSA Blinding fix... It does, although not literally the same fix as found in the patch. Please try the latest openssl-0.9.6-stable snapshot with your test server and report if you still observe problems. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[OpenSSL Advisory] Klima-Pokorny-Rosa attack on PKCS #1 v1.5 padding
OpenSSL Security Advisory [19 March 2003]
Klima-Pokorny-Rosa attack on RSA in SSL/TLS
===
Czech cryptologists Vlastimil Klima, Ondrej Pokorny, and Tomas Rosa
have come up with an extension of the Bleichenbacher attack on RSA
with PKCS #1 v1.5 padding as used in SSL 3.0 and TLS 1.0. Their
attack requires the attacker to open millions of SSL/TLS connections
to the server under attack; the server's behaviour when faced with
specially made-up RSA ciphertexts can reveal information that in
effect allows the attacker to perform a single RSA private key
operation on a ciphertext of its choice using the server's RSA key.
Note that the server's RSA key is not compromised in this attack.
This problem affects all applications using the OpenSSL SSL/TLS library.
OpenSSL releases up to 0.9.6i and 0.9.7a are vulnerable. The enclosed
patch modifies SSL/TLS server behaviour to avoid the vulnerability.
Security Patch
--
The following patch can be applied to OpenSSL releases 0.9.6b up to 0.9.6i,
0.9.7, and 0.9.7a.
--- s3_srvr.c 29 Nov 2002 11:31:51 - 1.85.2.14
+++ s3_srvr.c 19 Mar 2003 18:00:00 -
@@ -1447,7 +1447,7 @@
if (i != SSL_MAX_MASTER_KEY_LENGTH)
{
al=SSL_AD_DECODE_ERROR;
-
SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_RSA_DECRYPT);
+ /*
SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_RSA_DECRYPT); */
}
if ((al == -1) !((p[0] == (s-client_version8)) (p[1] ==
(s-client_version 0xff
@@ -1463,30 +1463,29 @@
(p[0] == (s-version8)) (p[1] == (s-version
0xff
{
al=SSL_AD_DECODE_ERROR;
-
SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_PROTOCOL_VERSION_NUMBER);
- goto f_err;
+ /*
SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_PROTOCOL_VERSION_NUMBER); */
+
+ /* The Klima-Pokorny-Rosa extension of
Bleichenbacher's attack
+* (http://eprint.iacr.org/2003/052/) exploits the
version
+* number check as a bad version oracle -- an alert
would
+* reveal that the plaintext corresponding to some
ciphertext
+* made up by the adversary is properly formatted
except
+* that the version number is wrong. To avoid such
attacks,
+* we should treat this just like any other decryption
error. */
+ p[0] = (char)(int) CAN-2003-0131 patch 2003-03-19;
}
}
if (al != -1)
{
-#if 0
- goto f_err;
-#else
/* Some decryption failure -- use random value instead as
countermeasure
* against Bleichenbacher's attack on PKCS #1 v1.5 RSA padding
-* (see RFC 2246, section 7.4.7.1).
-* But note that due to length and protocol version checking,
the
-* attack is impractical anyway (see section 5 in D.
Bleichenbacher:
-* Chosen Ciphertext Attacks Against Protocols Based on the
RSA
-* Encryption Standard PKCS #1, CRYPTO '98, LNCS 1462, pp.
1-12).
-*/
+* (see RFC 2246, section 7.4.7.1). */
ERR_clear_error();
i = SSL_MAX_MASTER_KEY_LENGTH;
p[0] = s-client_version 8;
p[1] = s-client_version 0xff;
RAND_pseudo_bytes(p+2, i-2); /* should be RAND_bytes, but we
cannot work around a failure */
-#endif
}
s-session-master_key_length=
References
--
Report Attacking RSA-based Sessions in SSL/TLS by V. Klima, O. Pokorny,
and T. Rosa:
http://eprint.iacr.org/2003/052/
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2003-0131 to this issue.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0131
URL for this Security Advisory:
http://www.openssl.org/news/secadv_20030319.txt
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: RSA Blinding patch and a recent snapshot.
On Mon, Mar 31, 2003 at 03:01:27PM -0500, Greaney, Kevin wrote: I downloaded a snapshot recently, openssl-e-0.9.6-stable-SNAP-20030327.tar.gz, and was comparing the files [.crypto.rsa]rsa_eay.c AND [.crypto.rsa]rsa_lib.c. I noticed that in rsa_eay.c that the patch used the positive when comparing, RSA_FLAG_BLINDING, and the snapshot used the negative, RSA_FLAG_NO_BLINDING. Here is the macro BLINDING_HELPER, and it shows the differences: [...] As for RSA_LIB.C, it looks like only part of the patch has been applied to the snapshot. [...] The missing changes to rsa_lib.c have been obviated by the other changes. (The OPENSSL_NO_FORCE_RSA_BLINDING compilation flag found in the patch no longer exists, but blinding now works when the PRNG has insufficient seeding, and this avoids a severe problem with having blinding always enabled.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: reminder
Please don't forget the enc_read.c bug fix.
From: Michael Rayment [EMAIL PROTECTED]
Subject: [ssl-bugs] Possible bug in crypto/des/enc_read.c
Date: Mon, 15 Feb 1999 00:45:01 -0330
I am using enc_read.c and enc_write.c to easily read and write data into
and from an encrypted file. I am reading and writing in large buffer sizes
and came across what appears to be a bug in the enc_read.c routine.
I added a few lines of code so that it would work [...]
*** enc_read.cSat Sep 12 14:19:38 1998
--- enc_read.c.orgThu Apr 9 09:29:29 1998
[...]
/* We need to get more data. */
! /* if (len MAXWRITE) len=MAXWRITE; */
! excess = 0;
! while (len MAXWRITE) {
! i = des_enc_read(fd, buf, MAXWRITE, sched, iv);
! buf += i;
! len -= i;
! excess += i;
! }
[...]
! return((int)num + excess);
Was that really a bug? I would not think so, and certainly the
proposed fix is not correct (the recursive call to des_enc_read can
return 0 because of either EOF, some real error or EWOULDBLOCK).
The original version of des_enc_read (with
if (len MAXWRITE) len=MAXWRITE;
) makes complete sense if you insist that the caller check the return
value; and on that you have to insist for obvious reasons.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: cleaning up crypto/dsa
+ s=BN_new(); if (s == NULL) ... + ret=DSA_SIG_new(); if (ret == NULL) ... + s = DSA_SIG_new(); if (s == NULL) ... __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Strong Primes
"Chad C. Mulligan" [EMAIL PROTECTED]: Hmmm... I don't know how _efficient_ it is, but in the tests I did on it, the average time to create a 1024 bit strong prime (and one _guaranteed_ strong, by construction) was 1014 seconds, as opposed to 2301 seconds for BN_generate_prime() with "strong" set to 1. What exactly do you mean by "strong" primes? BN_generate_prime() uses the word "strong" for what is more commonly called a "safe" prime, namely one where (p - 1)/2 is also prime. The word "strong" is traditionally (and I would like to be able to say "historically") used for RSA factors satisfying certain properties; namely: A prime p is called "strong" if p - 1 has a large prime factor p', p' - 1 again has a large prime factor, and p + 1 has a large prime factor. These requirements, together with p - 1 and q - 1 having a small GCD, make an RSA modulus resistant against certain attacks, which however are now superseded by more efficient methods (such as elliptic curve factoring), rendering this property worthless. (See Bob Silverman's papers on this topic, e.g. an article in some issue of CryptoBytes -- URL:http://www.rsa.com -- and some paper referenced from there, which should also be available at the RSA Labs web-site.) This kind of "strong" primes is mainly nostalgia. "Safe" primes, where q := (p - 1)/2 is prime, imply that there is one very large (order q) subgroup of (Z/pZ)*. More generally, we want a large prime q to be some divisor of p - 1. The order of the generator selected must be q or a multiple of q (it is absolutely not necessary that it generate all of (Z/pZ)*, which is how the cryptographic schemes are described in the original Diffie-Hellman and ElGamal papers.) q selected like that and an appropriate generator offer optimal resistance against "generic" algorithms for discrete logarithms, whose runtime is the root of the size of this subgroup. (Subgroups whose order has only small prime factors don't add any security against this kind of attacks.) It's really (generally believed to be) enough to have q so large that other known attacks become more efficient than the generic ones. For example, for a 1024 bit prime p, a 165 bit q should be enough. (And even if q is larger, you can select secret DH/ElGamal exponents with smaller sizes.) PGP uses for ElGamal encryption primes p where q is only about 10 bits smaller than p. While such large q's are not really needed for security reasons, they make it easy to make sure that 2 or some other small number is a generator of a subgroup the order of which is divided by q. That's very convenient, because the exponentiation x^k is much easier to compute for x = 2 than for large x. (Note that while PGP chooses a quite large q, the secret exponents are chosen rather small.) Alternatively, one could construct p - 1 to be the product of primes none of which, except for the inevitable 2, is smaller than what we want for q -- then we can also guarantee that 2 is okay as a generator. In any case, either we need to know all factors of p - 1, or we can't use a small generator. [...] because of the way the algorithm works, the size is somewhat variable, though this can be made better with empirical adjustments to the seed-data. For example, after asking for 1024 bit primes, I tended to end up with 1032 bit ones. I don't know if this is a problem or not. Is it? It is: Export cipher suites need Diffie-Hellman parameters of no more than 512 bits. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Strong Primes
On Sat, Mar 27, 1999 at 04:03:00AM +0100, Bodo Moeller wrote: "Safe" primes, where q := (p - 1)/2 is prime, imply that there is one very large (order q) subgroup of (Z/pZ)*. More generally, we want a large prime q to be some divisor of p - 1. The order of the generator selected must be q or a multiple of q Sorry, I was temporarily confused. While the above is a _necessary_ property of good Diffie-Hellman parameters, it is not sufficient. A sufficient condition can be formulated as follows: Let p be a prime of N bits, and let M be a threshold for the base-2 logarithm of the order of groups in which generic algorithms for discrete logs are less efficient than special algorithms are for (Z/pZ)*. (All this means that if we choose N = 1024, M should be 165, as stated in my previous message.) Let g be a candidate generator of some subgroup of (Z/pZ)* (we don't exclude the case that g generates the whole group (Z/pZ)*). We write ord(g) for the order of element g, which is also the order (= number of elements) of the subgroup that g generates. It is safe to use g if the following conditions are met: - There is a number O (which must satisfy M O N) such that ord(g) has a prime factor of O bits; and - if P denotes the bit length of that factor of ord(g) which consists only of prime factors of _less_ than O bits (in other words: the bit length of the 2^(O-1)-smooth part of ord(g)), then O - P M. For example, PGP's Diffie-Hellman parameters have, e.g., N = 1024 and O = 1014 (p - 1 has a prime factor about 10 bits smaller than p). Since ord(g) divides p - 1, the smooth part of ord(g) can have at most 10 bits, i.e. P = 10. So, O - P is at least 1004, which is well greater than 165. But, on the other hand, Diffie-Hellman parameters are not good if ord(g) is the product of a 200-bit prime and ten 20-bit primes. While 200 bits would be enough, the small primes destroy everything. The reason is that an attacker can first compute logarithms in the small subgroups, which is really easy, and then knows about everything about the logarithms in the one large subgroup. In the above condition, P stands for the bit-lenght of the size of a subgroup in which discrete logarithms are assumed to be easy; O - P stands for that part of the group generated by g which remains to be attacked after using those easy logarithms. As another example, if ord(g) is the product of a 200-bit prime, a 160-bit prime, a 120-bit prime, a 80-bit prime and a 40-bit prime, logarithms are also quite easy (an attacker can succesively compute logarithms in larger groups, starting with the 40-bit prime). In the above conditions, this shows in the impossibility to find an O that fulfils them. (it is absolutely not necessary that it generate all of (Z/pZ)*, which is how the cryptographic schemes are described in the original Diffie-Hellman and ElGamal papers.) As discussed above, it is actually a disadvantage if g generates "too much" of (Z/pZ)*, unless special care is taken. "Safe primes" (p = 2*q + 1 with q prime) are an easy way to avoid this problem: With only two elements, the small subgroup is so small that it cannot hurt. In any case, either we need to know all factors of p - 1, or we can't use a small generator. I hope this statement became more clear by now. -- If we know only one large prime factor q of p - 1, but not the factorization of p - 1, it is safe to choose some g with ord(g) = q. Such a g is easily found, but it is highly impropable that it will be a small number, as we want it for efficiency reason. Because parameter generation doesn't have the timing constraints that occur in the actual _use_ of the Diffie-Hellman parameters, it makes sense to invest more effort in parameter creation so that g = 2 or something similarly small can be used. (Note, however, that for ElGamal _signatures_ [as opposed to ElGamal _encryption_] additional conditions must be met!) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: 0.9.2b Sparc problem
On Mon, Mar 29, 1999 at 05:20:36PM +0200, Bodo Moeller wrote: What I don't understand though is the redifinition of BN_ASM in openssl-0.9.2b/crypto/bn/Makefile: [...] The real definition is in openssl-0.9.2b/Makefile.ssl: [...] What's this redefinition about, and why does the make procedure still try to cope with asm/sparc.s? Oh, I see: It's because those parameters are passed on the command line, not via the environment. Command line definitions override those in the Makefile, while those passed in the environment are just defaults that can be overridden from within the Makefile (unless the "-e" switch is used, which is available at least in GNU make). So I guess the definition in crypto/bn/Makefile.ssl is just there to confuse people :-) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: re[2]: OpenSSL Error Handling
[...] I do not have a file called error.doc on my hard drive. Actually, it's now part of doc/ssleay.txt. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Strong Primes
On Mon, Mar 29, 1999 at 01:12:03PM +, Chad C. Mulligan wrote: Bodo Moeller: What exactly do you mean by "strong" primes? BN_generate_prime() uses the word "strong" for what is more commonly called a "safe" prime, I mean a "safe" prime, then. The WS method creatres primes that are guaranteed to be of the form p = 2q+1 where q is also prime. Fine. Can you point me to a paper or book where this algorithm is described (such as the publication that earned it its name)? seed-data. For example, after asking for 1024 bit primes, I tended to end up with 1032 bit ones. I don't know if this is a problem or not. Is it? It is: Export cipher suites need Diffie-Hellman parameters of no more than 512 bits. You mean "export from the US"? Yes, exactly. They must not have more than 512 bits, but one also wouldn't want do use less than this limit; and new TLS ciphersuites might introduce a 1024 bit limit on Diffie-Hellman primes. I'm sure the code can be massaged to produce primes of the exact size (I've not played around with this very much) and, in any case, there is no reaosn why we can't use arbirarily large primes for places where the export rules don't prohibit it, is there? In the general case, this should be O.K. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL2_{CLIENT,SERVER}_VERSION
On Wed, Mar 31, 1999 at 02:06:33PM +0200, [EMAIL PROTECTED] wrote:
Changes between 0.9.2b and 0.9.3
+ *) Got rid of old SSL2_CLIENT_VERSION (inconsistently used) and
+ SSL2_SERVER_VERSION (not used at all) macros, which are now the
+ same as SSL2_VERSION anyway.
+ [Bodo Moeller]
I hope no-one circumenvented the API and used those macros directly in
any applications? The comment in ssl.h was wrong, anyway:
--- ssl.h 1999/03/22 12:22:03 1.17
+++ ssl.h 1999/03/31 12:06:29 1.18
@@ -477,10 +477,9 @@
struct ssl_st
{
- /* procol version
-* 2 for SSLv2
-* 3 for SSLv3
-* -3 for SSLv3 but accept SSLv2 */
+ /* protocol version
+* (one of SSL2_VERSION, SSL3_VERSION, TLS1_VERSION)
+*/
int version;
int type; /* SSL_ST_CONNECT or SSL_ST_ACCEPT */
Index: ssl2.h
===
RCS file: /e/openssl/cvs/openssl/ssl/ssl2.h,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -u -r1.1.1.2 -r1.2
--- ssl2.h 1998/12/21 10:55:50 1.1.1.2
+++ ssl2.h 1999/03/31 12:06:30 1.2
@@ -67,8 +67,8 @@
#define SSL2_VERSION 0x0002
#define SSL2_VERSION_MAJOR 0x00
#define SSL2_VERSION_MINOR 0x02
-#define SSL2_CLIENT_VERSION0x0002
-#define SSL2_SERVER_VERSION0x0002
+/* #define SSL2_CLIENT_VERSION 0x0002 */
+/* #define SSL2_SERVER_VERSION 0x0002 */
/* Protocol Message Codes */
#define SSL2_MT_ERROR 0
Index: ssl_sess.c
===
RCS file: /e/openssl/cvs/openssl/ssl/ssl_sess.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ssl_sess.c 1999/03/22 12:22:04 1.5
+++ ssl_sess.c 1999/03/31 12:06:30 1.6
@@ -150,7 +150,7 @@
if (session)
{
- if (s-version == SSL2_CLIENT_VERSION)
+ if (s-version == SSL2_VERSION)
{
ss-ssl_version=SSL2_VERSION;
ss-session_id_length=SSL2_SSL_SESSION_ID_LENGTH;
--
Bodo Möller
Lavielle EDV Systemberatung GmbH Co. Tel.: ++49 40 / 658088
Lotharstrasse 2b, D-22041 HamburgFax.: ++49 40 / 65808-202
http://www.lavielle.de/ Email: [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: ocsp in openssl
Tom Titchener [EMAIL PROTECTED]:
Attached please find a compressed tar file containing patches and
sources implementing with the OpenSSL libraries:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-07.txt
Here's a summary of the files you get:
[...]
mk1mf.pl.patch clone rules to build library for ocsp
($ssl,$crypto)=("ssl","crypto","ocsp");
I bet you meant
($ssl,$crypto,$ocsp)=("ssl","crypto","ocsp");
-- your patch to util/pl/VC-32.pl (with $cosp = "ocsp32") fixes it
for that specific case (can VC-16.pl be ignored now?).
But does anyone ever use makefile.one for Unix platforms, or at least
test it? util/pl/ contains BC-16.pl, BC-32.pl, VC-16.pl, VC-32.pl,
linux.pl, ultrix.pl, unix.pl. The top Makefile{.org,ssl} calls
mk1mf.pl without any argument, and INSTALL.W32 plus do_ms.bat use only
VC-* (BC-* is not even finished according to INSTALL.W32). There's a
script util/FreeBSD.sh which calls mk1mf.pl FreeBSD (which in turn
uses util/pl/unix.pl) -- is this ever used? I'm not too happy with
having so much stuff buried in various perl scripts ... Also,
ms/do_ms.bat has a semi-doppleganger util/do_ms.sh with different
lines commented out (and the additional difference that do_ms.bat uses
no-asm for 32 bit cases while do_ms.sh doesn't).
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: MD5 conflicts?
Niels Poppe [EMAIL PROTECTED]: In packaging openssl, I change #include "foo.h" to #include ssl/foo.h and then install all ssl include files into /usr/include/ssl. This way nothing changes for openssl internally, but once installed in the system location, external programs can include ssl/foo.h and be sure no local system foo.h will get in the way. The recursive #include "..."s in OpenSSL's include directory really all should be #include ... anyway, which whould avoid any clashes with application programs. It would not avoid clashes with other libraries, however, which can be expected to occur quite often. So I propose introducing openssl/... as the official file name scheme; that is, the files would be installed in /usr/include/openssl/ (or a location with a different prefix in place of /usr/include, whatever the user chooses). For consistency, the contents of the include directory in the OpenSSL source code tree (which are just links to other places) would be moved into a new directory include/openssl. If a program assumes that the OpenSSL header files can be reached as ssl.h and the like, it can still simply compiled with -I/usr/local/include/openssl, so no severe compatibility problem would be introduced. Instead of using "openssl" as prefix, just "ssl" is also an option, but it is not necessarily unique (and it is misleading: Programs that use the OpenSSL library do not necessarily use SSL, so it makes more sense to use the product name instead of a protocol name). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
openssl/doc
I thinkt that it is not a good idea to have files openssl.pod and openssl.txt in the same directory: The names suggest that the latter is a formatted version of the former, which is not true. The X509v3 documentation in openssl.txt (which could get a different filename) should mention that a basicConstraints pathlen is to be interpreted different than OpenSSL's "verify_depth" stuff (the pathLenConstraint counts just the CA path -- 0 means that a CA may sign only end entities --, while verify_depth counts all certificates, IIRC). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
apps/sc.c
apps/sc.c is a slight variation of apps/s_client.c. It exists in OpenSSL 0.9.1c, but not yet in SSLeay. The only changes to s_client.c are Windows-specific (mostly #if(n)defs); according to the comments, it has only been tested under Win95. Maybe someone who uses NT can look into it and, if it makes sense, integrate the changes into s_client.c, so that we can delete the extra file (which is currently not included in the make process as far as I can tell). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl/doc
I wrote: pathLenConstraint counts just the CA path -- 0 means that a CA may sign only end entities --, while verify_depth counts all certificates, IIRC). I don't really mean all certificates (unless one starts counting at 0), but all steps on the path: Depth 1 means that CAs sign end-entity certificates directly, and depth 0 should mean that we accept just those certificates that we have in our own certificate store. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: piping to s_client
Mikko Hirvonen [EMAIL PROTECTED]: I have problems with pipes. I try to use s_client as fetchmail plugin, but something goes wrong. Transmission over ssl-tunnel will stop. I think s_client.c is buggy in that in does a select() loop where in fact it the first thing it should do in each iteration is check SSL_pending(con). The result is that under certain circumstances when no new data arrives over the network, s_client sleeps on select() while SSL_read has quite a bit of internally buffered data that would be ready for processing. Fixing s_client is left as an exercise :-) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: patch to s23_srvr.c fixes crash for telnet with zero bytes to SSL port
"Titchener, Tom" [EMAIL PROTECTED]:
Ever try connecting to an SSLeay server that uses
SSLv23_server_method() via a telnet session and then closing the
session without sending any data?
When you do that in our server, it crashes trying to use the
handshake_func function in ssl23_read(), 'cuz handshake_func never got
initialized.
One fix that works is to change this code in the s23_srvr.c
ssl23_get_client_hello() routine from this:
n=ssl23_read_bytes(s,7);
if (n != 7) return(n);
to this:
n=ssl23_read_bytes(s,7);
if (n != 7) return -1;
In SSLeay-0.9.0b, that's lines 210 and 211.
From a quick look at the current sources in OpenSSL, I'd say this
is still a problem.
I looked into the source and think that it is not a problem (any
more?), and I also couldn't make out any relevant modifications in the
diff between 0.9.0b and 0.9.2b. openssl s_client does not seem to
have problems with incoming connections that are closed without having
sent any data. Is the server that you were testing really running
0.9.0b, or is it an older version?
Definitely the code above is not particularly clear, though.
In a more verbose programming style, it would be
n=ssl23_read_bytes(s,7);
if (n != 7) {
assert(n == 0 || n == -1);
return(n);
}
because ssl23_read_bytes is constructed to be called as often as
necessary to collect the requested number of bytes and won't return
something less than the requested number of bytes if only partial
reads succed, with the exception of 0 if EOF occured in which case the
protocol cannot procees any more. The call to ssl23_get_client_hello
in ssl23_accept is:
case SSL23_ST_SR_CLNT_HELLO_A:
case SSL23_ST_SR_CLNT_HELLO_B:
s-shutdown=0;
ret=ssl23_get_client_hello(s);
if (ret = 0) cb=NULL;
goto end;
[...]
end:
if (cb != NULL)
cb(s,SSL_CB_ACCEPT_EXIT,ret);
s-in_handshake--;
return(ret);
}
These return values (-1 = error or retry, 0 = EOF, 1 = success) are
used consistently in the varios handshake functions, I think. But I
haven't yet read all of them.
If handshake_func is not initialised (i.e. is 0 because that's what
SSL_new sets it to), then I guess your application failed to call
SSL_set_accept_state before any of SSL_do_handshake, SSL_read or
SSL_write are used, which it really has to. SSL_set_accept_state is
defined as follows:
void SSL_set_accept_state(SSL *s)
{
s-server=1;
s-shutdown=0;
s-state=SSL_ST_ACCEPT|SSL_ST_BEFORE;
s-handshake_func=s-method-ssl_accept;
/* clear the current cipher */
ssl_clear_cipher_ctx(s);
}
Also, I'd say it's probably also lurking in s3_srvr.c, where
ssl3_get_client_hello return the number of bytes read by
ssl3_get_message when !ok and the caller is going to think the call to
ssl3_get_client_hello didn't fail.
Again I think that the premature returns in ssl3_get_client_hello are
to be read as, e.g.,
n=ssl3_get_message(s,
SSL3_ST_SR_CLNT_HELLO_B,
SSL3_ST_SR_CLNT_HELLO_C,
SSL3_MT_CLIENT_HELLO,
SSL3_RT_MAX_PLAIN_LENGTH,
ok);
if (!ok) {
assert(n == 0 || n == -1);
return((int)n);
}
and don't cause any problems to the program (but, unfortunately, to
humans trying to understand the implementation -- the "if (n != 7)
return(n);" indeed looked suspicious to me when I first encountered
it).
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: piping to s_client
[EMAIL PROTECTED] (Bodo Moeller):
Mikko Hirvonen [EMAIL PROTECTED]:
I have problems with pipes. I try to use s_client as fetchmail
plugin, but something goes wrong. Transmission over ssl-tunnel will
stop.
I think s_client.c is buggy in that in does a select() loop where in
fact it the first thing it should do in each iteration is check
SSL_pending(con). The result is that under certain circumstances when
no new data arrives over the network, s_client sleeps on select()
while SSL_read has quite a bit of internally buffered data that would
be ready for processing. Fixing s_client is left as an exercise :-)
It seems that no-one took the challenge, so here's my patch (relative
to the current code, but the patch should work for 0.9.2b as well):
Index: apps/s_client.c
===
RCS file: /e/openssl/cvs/openssl/apps/s_client.c,v
retrieving revision 1.5
diff -u -r1.5 s_client.c
--- apps/s_client.c 1999/03/31 12:06:04 1.5
+++ apps/s_client.c 1999/04/08 20:20:02
@@ -154,7 +154,7 @@
char *cert_file=NULL,*key_file=NULL;
char *CApath=NULL,*CAfile=NULL,*cipher=NULL;
int reconnect=0,badop=0,verify=SSL_VERIFY_NONE,bugs=0;
- int write_tty,read_tty,write_ssl,read_ssl,tty_on;
+ int write_tty,read_tty,write_ssl,read_ssl,tty_on,ssl_pending;
SSL_CTX *ctx=NULL;
int ret=1,in_init=1,i,nbio_test=0;
SSL_METHOD *meth=NULL;
@@ -439,31 +439,36 @@
}
}
+ ssl_pending = read_ssl SSL_pending(con);
+
+ if (!ssl_pending)
#ifndef WINDOWS
- if (tty_on)
{
- if (read_tty) FD_SET(fileno(stdin),readfds);
- if (write_tty) FD_SET(fileno(stdout),writefds);
- }
+ if (tty_on)
+ {
+ if (read_tty) FD_SET(fileno(stdin),readfds);
+ if (write_tty) FD_SET(fileno(stdout),writefds);
+ }
#endif
- if (read_ssl)
- FD_SET(SSL_get_fd(con),readfds);
- if (write_ssl)
- FD_SET(SSL_get_fd(con),writefds);
+ if (read_ssl)
+ FD_SET(SSL_get_fd(con),readfds);
+ if (write_ssl)
+ FD_SET(SSL_get_fd(con),writefds);
-/* printf("mode tty(%d %d%d) ssl(%d%d)\n",
- tty_on,read_tty,write_tty,read_ssl,write_ssl);*/
+/* printf("mode tty(%d %d%d) ssl(%d%d)\n",
+ tty_on,read_tty,write_tty,read_ssl,write_ssl);*/
- i=select(width,readfds,writefds,NULL,NULL);
- if ( i 0)
- {
- BIO_printf(bio_err,"bad select %d\n",
+ i=select(width,readfds,writefds,NULL,NULL);
+ if ( i 0)
+ {
+ BIO_printf(bio_err,"bad select %d\n",
get_last_socket_error());
- goto shut;
- /* goto end; */
+ goto shut;
+ /* goto end; */
+ }
}
- if (FD_ISSET(SSL_get_fd(con),writefds))
+ if (!ssl_pending FD_ISSET(SSL_get_fd(con),writefds))
{
k=SSL_write(con,(cbuf[cbuf_off]),
(unsigned int)cbuf_len);
@@ -531,7 +536,7 @@
}
}
#ifndef WINDOWS
- else if (FD_ISSET(fileno(stdout),writefds))
+ else if (!ssl_pending FD_ISSET(fileno(stdout),writefds))
{
i=write(fileno(stdout),(sbuf[sbuf_off]),sbuf_len);
@@ -551,7 +556,7 @@
}
}
#endif
- else if (FD_ISSET(SSL_get_fd(con),readfds))
+ else if (ssl_pending || FD_ISSET(SSL_get_fd(con),readfds))
{
#ifdef RENEG
{ static int ; if (++ == 52) { SSL_renegotiate(con); =0; } }
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
make test revisited
The shellscript test/testenc must be told somehow which ciphers have been configured. After a -DNO_IDEA build, it still tries to run "../apps/openssl idea-ecb" etc., which of course fails. I usually just ignored this error because I obviously knew that I explicitly did not include IDEA, so this is less of a surprise than the RSAREF-OAEP thing; but still it should be changed. What's the cleanest way to solve this? Exile the command list (des-cfb des-ede-cfb des-ede3-cfb \ des-ofb des-ede-ofb des-ede3-ofb \ des-ecb des-ede des-ede3 desx \ des-cbc des-ede-cbc des-ede3-cbc \ idea-ecb idea-cfb idea-ofb idea-cbc \ rc2-ecb rc2-cfb rc2-ofb rc2-cbc \ bf-ecb bf-cfb bf-ofb bf-cbc rc4 \ cast5-ecb cast5-cfb cast5-ofb cast5-cbc) into an external file and run this external file through the C pre-processor so that #ifndef NO_IDEA can be used? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: make test revisited
On Fri, Apr 09, 1999 at 11:45:47AM +0200, Richard Levitte - VMS Whacker wrote: What's the cleanest way to solve this? Exile the command list Run something like the following during compilation of the test directory: $(CC) $(CFLAGS) -E testenc_methods.c | sed -e 'd/^$/' |\ sed -e 's/_/-/g' testenc_methods [...] You may wonder why I use _ instead of - in testenc_methods.c. The reason is that some preprocessors put spaces between tokens if there are none already, so for example des-ede-cbc would suddenly become "des - ede - cbc". Using underscores instead makes sure they are treated as symbols and, so to say, stay together. The last sed does the conversion back... Thanks. I have to added a new file test/testenc_commands.c[1]: [1] Does the filename really have to end in ".c"? I'd prefer ".in" if it cannot cause any problems with other compilers. Is there a portable option that allows to use a different suffix? Sun's cc version 4.2 accepts anything, but gcc complains when I do "gcc -DNO_IDEA -E testenc_methods.strange_suffix". /* C preprocessor input for producing the list of openssl encryption commands that should be available. Note that we use "_" instead of "-" in the names so that each command looks like one symbol to the C preprocessor -- -- otherwise spaces might be inserted. */ #ifndef NO_RC4 rc4 #endif #ifndef NO_DES des_cfb des_ede_cfb des_ede3_cfb des_ofb des_ede_ofb des_ede3_ofb des_ecb des_ede des_ede3 desx des_cbc des_ede_cbc des_ede3_cbc #endif #ifndef NO_IDEA idea_ecb idea_cfb idea_ofb idea_cbc #endif #ifndef NO_RC2 rc2_ecb rc2_cfb rc2_ofb rc2_cbc #endif #ifndef NO_BLOWFISH bf_ecb bf_cfb bf_ofb bf_cbc #endif #ifndef NO_RC4 rc4 #endif #ifndef NO_CAST cast5_ecb cast5_cfb cast5_ofb cast5_cbc #endif and plan to apply the following patches, unless someone complains: === RCS file: /e/openssl/cvs/openssl/test/Makefile.ssl,v retrieving revision 1.12 diff -u -r1.12 Makefile.ssl --- Makefile.ssl1999/04/08 15:09:24 1.12 +++ Makefile.ssl1999/04/09 10:45:02 @@ -144,8 +144,12 @@ test_rand: ./$(RANDTEST) -test_enc: +test_enc: testenc_commands @sh ./testenc + +testenc_commands: testenc_commands.c + $(CC) $(CFLAGS) -E testenc_commands.c | \ + sed -e 's/_/-/g' -e 's/^#.*//' testenc_commands test_x509: echo test normal x509v1 certificate Index: testenc === RCS file: /e/openssl/cvs/openssl/test/testenc,v retrieving revision 1.2 diff -u -r1.2 testenc --- testenc 1999/01/02 19:01:40 1.2 +++ testenc 1999/04/09 10:45:02 @@ -27,15 +27,7 @@ /bin/rm $test.cipher $test.clear fi -for i in rc4 \ - des-cfb des-ede-cfb des-ede3-cfb \ - des-ofb des-ede-ofb des-ede3-ofb \ - des-ecb des-ede des-ede3 desx \ - des-cbc des-ede-cbc des-ede3-cbc \ - idea-ecb idea-cfb idea-ofb idea-cbc \ - rc2-ecb rc2-cfb rc2-ofb rc2-cbc \ - bf-ecb bf-cfb bf-ofb bf-cbc rc4 \ - cast5-ecb cast5-cfb cast5-ofb cast5-cbc +for i in `cat testenc_commands` do echo $i $cmd $i -bufsize 113 -e -k test $test $test.$i.cipher __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: make test revisited
On Fri, Apr 09, 1999 at 07:29:51PM +0100, Ben Laurie wrote: Isn't the simplest thing to just #ifdef the test code itself, so the test programs are always there, just don't do anything if there's nothing to test? There are two kinds of tests: First, there are ideatest.c and similar programs. These don't seem to have any problems when NO_IDEA etc. is defined. Probably you were thinking of something like these. The only test that failed for me is testenc, which is a shellscript that tests the openssl application program by running openssl algorithm -bufsize 113 -e -k test and then openssl algorithm -bufsize 157 -d -k test And in a shellscript, we obviously cannot just write #ifndef NO_IDEA. It would be possible, of course, to convert the shellscript into an equivalent C program, but I don't know why one would want to do that -- it's quite natural to use the openssl application in shells or shellscripts, and that's exactly what we want to test. Now when it comes to determining which algorithms we should actually test here, the C pre-processor inevitably becomes involved because the relevant configuration is done by defining NO_IDEA and similar symbols. But except for that, the "enctest" program does not have anything with C. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
apps/enc.c, apps/prog.h (was: make test revisited)
Dr Stephen Henson [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
That seems very complicated. How about doing this
in the Makefile
test: cipherlist
cipherlist: cipherlist.c
..usual CC rules.
And cipherlist is
main()
{
#ifndef NO_DES
printf("des_cfb\ndes_ede_cfb\ndes_ede3_cfb\n...")
and so on.
Then the test is
for I in `cipherlist` ; do
Hmmm thats not portable to single Makefile stuff like Win32 which would
need a special case of course.
How about a 'test' application that works similar to the openssl
application which has all the tests linked into it [...]
I don't think that this should be done -- enctest is just about using
openssl from shellscripts. But if we combine these ideas, we get the
following:
Create, as a part of enc.c, a new application "cipherlist" or
"list-ciphers" or whatever that prints the list of all availabe
encryption applications (this is basically an extract of the error
message that openssl produces when you give an incorrect application
name):
$ openssl list-ciphers
base64
bf
bf-cbc
bf-cfb
bf-ecb
[...]
The proper #ifdefs exist in progs.h (which really should be split up
into progs.h, which defines prototypes, and progs.c, which defines the
data object "functions"[1] and thus does not belong in a header file)
[1] FUNCTION functions[] = {
{FUNC_TYPE_GENERAL,"verify",verify_main},
{FUNC_TYPE_GENERAL,"asn1parse",asn1parse_main},
etc. etc. etc.
Then, "testenc" would do the following:
for i in `$cmd list-ciphers`
do
echo $i
$cmd $i -bufsize 113 -e -k test $test $test.$i.cipher
$cmd $i -bufsize 157 -d -k test $test.$i.cipher $test.$i.clear
Votes, please, on
- adding a "list-ciphers" application (or, to make things more
coherent, "standard-commands", "message-digest-commands",
"cipher-commands" applications that emit the respective lists from
apps/openssl.c's standard error message)
and
- splitting prog.h in prog.c and prog.h.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Getting rid of ctx_size.c
Down below, as discussed, a patch for getting rid of ctx_size.c and
pem.org follows. The Configure script obviously should be cleaned up
if we do this. The new pem.h will differ from the existing pem.org as
follows (remember that HEADER_ENVELOPE_H is always defined here
because of a previous #include, and that the dummy structure
definitions anyway could fail on some systems because they don't
necessary have the alignment needed for the actual structures):
--- pem.org Mon Mar 8 23:46:54 1999
+++ pem.h Sun Apr 11 05:18:19 1999
@@ -121,36 +121,6 @@
#define PEM_STRING_SSL_SESSION "SSL SESSION PARAMETERS"
#define PEM_STRING_DSAPARAMS "DSA PARAMETERS"
-#ifndef HEADER_ENVELOPE_H
-
-#define EVP_ENCODE_CTX_SIZE 92
-#define EVP_MD_SIZE 48
-#define EVP_MD_CTX_SIZE 152
-#define EVP_CIPHER_SIZE 28
-#define EVP_CIPHER_CTX_SIZE 4212
-#define EVP_MAX_MD_SIZE 20
-
-typedef struct evp_encode_ctx_st
- {
- char data[EVP_ENCODE_CTX_SIZE];
- } EVP_ENCODE_CTX;
-
-typedef struct env_md_ctx_st
- {
- char data[EVP_MD_CTX_SIZE];
- } EVP_MD_CTX;
-
-typedef struct evp_cipher_st
- {
- char data[EVP_CIPHER_SIZE];
- } EVP_CIPHER;
-
-typedef struct evp_cipher_ctx_st
- {
- char data[EVP_CIPHER_CTX_SIZE];
- } EVP_CIPHER_CTX;
-#endif
-
typedef struct PEM_Encode_Seal_st
{
Index: Configure
===
RCS file: /e/openssl/cvs//openssl/Configure,v
retrieving revision 1.35
diff -u -r1.35 Configure
--- Configure 1999/04/09 16:25:25 1.35
+++ Configure 1999/04/11 03:40:53
@@ -236,9 +236,9 @@
# Miscellaneous hacks: this is designed to allow environments where the "one
# makefile" option does not auto build all files.
-# The first six fields are the hard coded versions of the stuff generated by
-# ctx_size for pem.h: that is EVP_ENCODE_CTX_SIZE, EVP_MD_SIZE EVP_MD_CTX_SIZE,
-# EVP_CIPHER_SIZE, EVP_CIPHER_CTX_SIZE and EVP_MAX_MD_SIZE respectively.
+## # The first six fields are the hard coded versions of the stuff generated by
+## # ctx_size for pem.h: that is EVP_ENCODE_CTX_SIZE, EVP_MD_SIZE EVP_MD_CTX_SIZE,
+## # EVP_CIPHER_SIZE, EVP_CIPHER_CTX_SIZE and EVP_MAX_MD_SIZE respectively.
# If the seventh field is 1 then auto generate
# crypto/date.h
# Need to add Win16 and others here.
@@ -636,12 +636,12 @@
$max_md_size, $date_fix) =
split(/\s*:\s*/,$misc_table{$target} . ":", -1);
-#print "EVP_ENCODE_CTX_SIZE $enc_ctx\n";
-#print "EVP_MD_SIZE $md_size\n";
-#print "EVP_MD_CTX_SIZE $md_ctx_size\n";
-#print "EVP_CIPHER_SIZE $cipher_size\n";
-#print "EVP_CIPHER_CTX_SIZE $cipher_ctx_size\n";
-#print "EVP_MAX_MD_SIZE $max_md_size\n";
+## #print "EVP_ENCODE_CTX_SIZE $enc_ctx\n";
+## #print "EVP_MD_SIZE $md_size\n";
+## #print "EVP_MD_CTX_SIZE $md_ctx_size\n";
+## #print "EVP_CIPHER_SIZE $cipher_size\n";
+## #print "EVP_CIPHER_CTX_SIZE $cipher_ctx_size\n";
+## #print "EVP_MAX_MD_SIZE $max_md_size\n";
#printf "Date fix: %s\n", $date_fix ? "Yes" : "No";
# Fix the date
@@ -652,23 +652,23 @@
close(OUT);
}
-open (IN, "crypto/pem/pem.org") || die "Can't open crypto/pem/pem.org";
-open (OUT, "crypto/pem/pem.h") || die "Can't create crypto/pem/pem.h";
-
-# Now fix up pem.h
-while(IN) {
- chop;
- s/^(#define EVP_ENCODE_CTX_SIZE).*$/$1 $enc_ctx/;
- s/^(#define EVP_MD_SIZE).*$/$1 $md_size/;
- s/^(#define EVP_MD_CTX_SIZE).*$/$1 $md_ctx_size/;
- s/^(#define EVP_CIPHER_SIZE).*$/$1 $cipher_size/;
- s/^(#define EVP_CIPHER_CTX_SIZE).*$/$1 $cipher_ctx_size/;
- s/^(#define EVP_MAX_MD_SIZE).*$/$1 $max_md_size/;
- print OUT "$_\n";
-}
-
-close (IN);
-close (OUT);
+## open (IN, "crypto/pem/pem.org") || die "Can't open crypto/pem/pem.org";
+## open (OUT, "crypto/pem/pem.h") || die "Can't create crypto/pem/pem.h";
+##
+## # Now fix up pem.h
+## while(IN) {
+## chop;
+## s/^(#define EVP_ENCODE_CTX_SIZE).*$/$1 $enc_ctx/;
+## s/^(#define EVP_MD_SIZE).*$/$1 $md_size/;
+## s/^(#define EVP_MD_CTX_SIZE).*$/$1 $md_ctx_size/;
+## s/^(#define EVP_CIPHER_SIZE).*$/$1 $cipher_size/;
+## s/^(#define EVP_CIPHER_CTX_SIZE).*$/$1 $cipher_ctx_size/;
+## s/^(#define EVP_MAX_MD_SIZE).*$/$1 $max_md_size/;
+## print OUT "$_\n";
+## }
+##
+## close (IN);
+## close (OUT);
}
Index: crypto/pem/Makefile.ssl
===
RCS file: /e/openssl/cvs//openssl/crypto/pem/Makefile.ssl,v
retrieving revision 1.11
diff -u -r1.11 Makefile.ssl
--- crypto/pem/Makefile.ssl 1999/04/01 12:34:09 1.11
+++ crypto/pem/Makefile.ssl 1999/04/11 03:40:55
@@ -21,8 +21,6 @@
TEST=
APPS=
-CTX_SIZE= ctx_size
-
LIB=$(TOP)/libcrypto.a
LIBSRC= pem_sign.c pem_seal.c pem_info.c pem_lib.c pem_all.c $(ERRC).c
@@ -37,16 +35,8 @@
top:
(cd ../..; $(MAKE) DIRS=crypto SDIRS=$(DIR) sub_all)
-
-all: pem.h lib
-
-pem.h: $(CTX_SIZE) pem.org
-
Re: 0.9.3 Windows/NT bit rot
On Wed, Apr 14, 1999 at 11:43:56AM -0400, Tom Titchener wrote:
Here are a handful of minor fixes I had to make to feed 0.9.3 through
VC 6.0.
[...]
4) The apps directory needs a copy of bss_file.c, which lives in
crypto/bio. This is the kind of thing you handle with a symlink
on Unix but which you need a copy in a bat script for on NT:
E:\cp crypto/bio/bss_file.c apps
This is because of:
[29]1.7 Thu Mar 4 07:47:27 1999 UTC; 5 weeks, 6 days ago by rse
Changed since 1.6: +2 -2 lines
[30]Diffs to 1.6 [[31]human readable]
Don't install bss_file.c under PREFIX/include/. It was introduced by Eric
between SSLeay 0.8 and 0.9 and just looks useless and confusing.
Pointed out by: Lennart Bong [32][EMAIL PROTECTED]
Submitted by: Ralf S. Engelschall
Cf.
URL:http://www.openssl.org/source/cvs/crypto/bio/Makefile.ssl.diff?r1=1.6r2=1.7hideattic=1sortbydate=0.
I have now added bss_file.c to HEADER, because that is what I think
was originally intended ("EXHEADER" = "exported headers", i.e. files
that should be copied into the "include" directory to be visible for
other programs that use OpenSSL; "HEADER" = other files that are
included somewhere within the library, e.g. all the ..._locl.h ones).
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
