Re: [openssl.org #82] `NID_uniqueIdentifier' undeclared (first use in this function)
On Wed, Jun 12, 2002 at 09:22:22AM -0400, Jeffrey Altman wrote: Gang. It is a little uncool to be having a long lengthy discussion of someone's supported code without involving them in the discussion. As it turns out all of the issues that have been addressed in this thread related to C-Kermit had already been handled in the C-Kermit Daily builds. http://www.kermit-project.org/ckdaily.html Sorry for not including you into the discussion. I only cared about the problem itself, which also pops up in mod_ssl, so I didn't even realize that we were talking about your package. Anyway: NID_uniqueIdentifier _may_ be re-enabled at some point in the future with its original meaning # The following clashes with 2.5.4.45, so commented away #pilotAttributeType 44 : uid : uniqueIdentifier I would therefore propose to not code dependant on #ifdef NID_uniqueIdentifier but by OpenSSL version number. This discussion started 1 week ago with corresponding problems reported in the mod_ssl mailing lists. As nobody else spoke up in that regard, it is my intention to leave everything as is, make sure that the item is pointed out in CHANGES (maybe even NEWS) and declare the problem to be resolved this way. I have not yet decided about pilotAttributeType 44, but will probably leave it disabled until the 0.9.8 release of OpenSSL, so that applications not conforming to the new naming will not compile instead of silently using a wrong interpretation. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #95] SSL_CTX_set_client_cert_cb error ?
The manual page about SSL_CTX_set_client_cert_cb was simply wrong. What in hell did I smoke when writing it? Or was it simply too late at night?? Anyway, I have just checked in a new version: If a certificate was already set, the client_cert_cb will never be called. Once it is called and returns a certificate, the certificate will be set for this SSL object and the callback will not be called again. Sorry for any confusion caused. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #82] `NID_uniqueIdentifier' undeclared (first use in this function)
As already pointed out in additional emails in openssl-dev: * the change will stay in place, thus NID_x500UniqueIdentifier will be the macro to use starting with OpenSSL 0.9.7 * I have not activated the original meaning of uniqueIdentifier and it will not be done before 0.9.8 in order to prevent silent failure. * I have added appropriate documentation in CHANGES, NEWS, FAQ. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #92] Prototypes SSL_write() SSL_read() problem in openssl/ssl.h for 64-bit applications
[[EMAIL PROTECTED] - Tue Jun 11 09:11:38 2002]: I believe that this last parameter needs to be of type size_t. The problem is not solved by changing the calls to SSL_read() and SSL_write(). These functions call internal functions which again call other internal functions and so on. All of these interfaces are realized using int. Thus, a massive change would be required that would exceed the definition of bugfix. I will therefore put your proposal into the 0.9.8 queue. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #73] make failing under MAC OS X (darwin)
[[EMAIL PROTECTED] - Tue Jun 4 19:09:40 2002]: cc -o openssl -DMONOLITH -I../include -fPIC -DTHREADS -D_REENTRANT -O3 -D_DARWIN -DB_ENDIAN openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o -L.. -lssl -L.. -lcrypto /usr/bin/ld: Undefined symbols: _ENGINE_by_id _ENGINE_free _ENGINE_set_default _ENGINE_load_private_key _ENGINE_ctrl _RSA_set_default_openssl_method /usr/bin/ld: warning unused multiple definitions of symbol _crypt /usr/lib/libcrypto.dylib(fcrypt.o) definition of _crypt /usr/lib/libSystem.dylib(crypt.o) unused definition of _crypt make[1]: *** [openssl] Erreur 1 make: *** [sub_all] Erreur 1 To which version of OpenSSL do you refer? Did you see any error message while building in the crypto/engine/ subdirectory? Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #88] Encrypted alert 25.
Sorry, my explanation went into the wrong bucket :-( Here again: I have tried to access the host (and the specific URL) mentioned with the openssl s_client command line tool. I could not see anything strange. After the data (how useful is it?) is transferred, the client sends a close notify alert... This is consistent with the dump you sent. It is the client that sends the alert, not the server: 1 985 8.9687 (7.3512) CSV3.1(18) Alert Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[ftm@uk2.net: Updating OpenSSL on RedHat 7.3]
- Forwarded message from root [EMAIL PROTECTED] - Date: Sun, 09 Jun 2002 16:43:05 -0300 From: root [EMAIL PROTECTED] X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en To: [EMAIL PROTECTED] Subject: Updating OpenSSL on RedHat 7.3 X-Virus-Scanned: by AMaViS snapshot-20011031 Hello, I have RedHat 7.3 installed here and the version of the openSSL is 0.9.6a. I donwnloaded the newest version of openSSL (0.9.6d) but its a tar file, not a RPM file, do I have to uninstall my current version of openSSL in order to intall the newest version? Because if in the openSSL homesite had the RPM file, I would just usr the rpm -Uvh openSSL.rpm command, to upgrade but I don't know if the tar file will upgrade in the correct way Could you tell me if I need to unistall the openSSL already installed in order to intall the new one or I should just install the new one over the current one? Ome more thing... Will the openSSL.tar.gz file install its components in the same place that RedHat 7.3 installed by default? Thanks for your time... Best, FTM - End forwarded message - -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Various patches for 0.9.6d and 0.9.7-beta1
On Mon, Jun 10, 2002 at 01:52:12PM +0100, [EMAIL PROTECTED] wrote: I have two patches for hpux64-parisc-gcc support in Configure and one to correct an error in evp_test.c, which calls strsep instead of sstrsep (09.7-beta1 only). Thanks. The strsep issue is already fixed in the current tree. (See attached file: openssl-0.9.7-beta1.patch)(See attached file: openssl-0.9.6d.patch)(See attached file: openssl-0.9.7-beta1.evp_test.patch) I have tests the hpux64 with gcc-3.1.0 and make test runs through correctly. These are not the most optimal values (eg it sets the -g flag and no optimization) but gcc for hppa64-hp-hpux11.00 is still a little flaky. This currently doesn't create shared libraries. The GNU linker is very flaky but I wouldn't take too much to create shared libaries with the HP linker. I don't yet fully understand your patches (I only have gcc-3.0.x on HP-UX 10.20, so I am not familiar with the latest 64bit issues). It however seems, that nowhere any 64bit command line option is used. Doesn't this mean, that 32bit code is generated? For hpux64-parisc-cc the +DD64 flag is required. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Various patches for 0.9.6d and 0.9.7-beta1
On Mon, Jun 10, 2002 at 03:06:22PM +0100, [EMAIL PROTECTED] wrote: I think the problem is because 32bit HP uses the SOM object format and 64bit HP uses ELF. These are quite different and hence gcc cannot be configured for both targets. So when you build gcc it is a different target (hppa64-hp-hpux11.00) for 64bit than 32bit (hppa2.0n-hp-hpux11.00). NB On PA-linux this is different, its uses ELF32 and ELF64 respectively, so I think a single instance of gcc does have 32/64 bit flag. So the entries you supplied are for gcc (hppa64-hp-hpux11.00)? Is there a way for config to find out itself? Please have a look into config and search for GCC_ARCH to see what I mean. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Various patches for 0.9.6d and 0.9.7-beta1
On Mon, Jun 10, 2002 at 03:44:07PM +0100, [EMAIL PROTECTED] wrote: So the entries you supplied are for gcc (hppa64-hp-hpux11.00)? Is there a way for config to find out itself? Please have a look into config and search for GCC_ARCH to see what I mean. Sure. It will take me a couple of days. In GCC 3.1 gcc --version doesn't work the same way so I will looking at gcc -v | egrep ^gcc version to do the same job. Please load down a current snapshot. GCC-3.1 support for --version should be added. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #80] [Lutz.Jaenicke@aet.TU-Cottbus.DE: Re: Naina announce (was: [ANNOUNCE] OpenSSL 0.9.1 beta 1 released)]
On Wed, Jun 05, 2002 at 09:33:25AM +0200, Vadim Fedukovich via RT wrote: patch to add SET-specific objects is attached. It's rather large, still it would let to build Naina without modifying openssl code. I have made some further modifications: I did not like the direct use of 2 23 42 for SET (even though correct of course) but wanted to build the tree from the root. While doing this I noted, that the CCITT has long since been renamed to ITU-T. I therefore made some additional changes to use the new name and prepare aliases for CCITT. * It should be no problem to apply this to 0.9.8. * I am afraid to break things beyond NID_uniqueIdentifier in 0.9.7. (Due to the alias for CCITT nothing should happen, though). Opinions? Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Various patches for 0.9.6d and 0.9.7-beta1
On Mon, Jun 10, 2002 at 04:53:36PM +0100, [EMAIL PROTECTED] wrote:
I've picked up the snapshot. There is a problem with the new code.
GCCVER=`(gcc --version) 2/dev/null | head -1`
if [ $GCCVER != ]; then
CC=gcc
# then strip off whatever prefix Cygnus as well as GCC 3.1 prepends
# the number with... Hopefully, this will work for any future prefixes
# as well.
GCCVER=`echo $GCCVER | sed 's/^[a-zA-Z ()]*\-//'`
# peak single digit before and after first dot, e.g. 2.95.1 gives 29
GCCVER=`echo $GCCVER | sed 's/\([0-9]\)\.\([0-9]\).*/\1\2/'`
else
CC=cc
fi
GCCVER=${GCCVER:-0}
The problem is with
GCCVER=`echo $GCCVER | sed 's/^[a-zA-Z ()]*\-//'`
The \- doesn't work with gcc 3.1 which outputs
gcc (GCC) 3.1.
Hmm. From cvs log config:
revision 1.101
date: 2002/06/05 05:00:51; author: levitte; state: Exp; lines: +5 -3
Update the recognision of GCC version numbers to handle the prefix text
that GCC 3.1 adds to the --version output
Maybe the change for 1.101 (or similar fo the BRANCHes) was not sufficient.
I have CC'ed Richard Levitte.
I can fix the regex but I like know the reasoning behind it. I tried
^[a-zA-Z ()]*\-?
but this doesn't work with sed because it an extended regex and not
supported by
HP or GNU sed.
As for detecting 64bit GCC, that looks fairly easy. GCC passes a define
-D__LP64__
to cpp. Otherwise it would something like
int main()
{
if ((sizeof(long) == 8) (sizeof(void*) == 8)) return 1; /* LP64 */
or ((sizeof(long == 8) || (sizeof(void*) == 8)) return -1; /* error, this
should never happen on hpux */
or return 0;
}
would work.
__LP__64 should work for the scheme used for other platforms, so we
probably don't need to test-compile a file.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #90] Empty fragments sent to prevent CBC known IV attack breaks compatibility
The change introduced in OpenSSL 0.9.6d to prevent attacks on CBC ciphers with known IVs seems to break compatibility. Several discussions on the list and discussions I had in private email indicate, that compatibility problems arise from this change. It should be discussed, whether there is another way to circumvent the problem (probably not), whether the problem is that dangerous that the compatibility problems are acceptable with respect to the risk, or whether the change should be reverted until an official solution in the TLS specification is made. This problem also applies to the 0.9.7 and later versions. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl-0.9.7-beta1 Win32 build error
On Fri, Jun 07, 2002 at 11:02:19AM +0530, Bhavin Shah wrote: I was trying to build the OpenSSL 0.9.7 beta1 source. Finally, changed evp_test.c. On line 361 of crypto\evp\evp_test.c changed the function call from strsep() to sstrsep() which is an existing function. The code compiled this time. Also, ran ms\test.bat and it passed all the tests. Is this the right fix though ? Yes, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #83] Pseudonym
Thanks, the new OID has been added for 0.9.7 and later. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #82] `NID_uniqueIdentifier' undeclared (first use in this function)
[[EMAIL PROTECTED] - Thu Jun 6 08:55:05 2002]: On Wed, Jun 05, 2002 at 03:10:58PM +0200, Lutz Jaenicke via RT wrote: [[EMAIL PROTECTED] - Wed Jun 5 14:48:52 2002]: ck_ssl.c: In function k_tn_tls_negotiate': ck_ssl.c:3232: ID_uniqueIdentifier' undeclared (first use in this function) ck_ssl.c:3232: (Each undeclared identifier is reported only once ck_ssl.c:3232: for each function it appears in.) ck_ssl.c: In function k_ssl_incoming': ck_ssl.c:3529: ID_uniqueIdentifier' undeclared (first use in this function) *** Error code 1 Thank you for a reply. The problem is caused by inconsistent definitions for the OID values. According to RFC2256, the OID 2.5.4.45 is assigned to X500UniqueIdentifier. UniqueIdentifier was assigned to pilotAttributeType.44 in RFC1274. If you have a look into crypto/objects/objects.txt you will see, that this was (still is) commented out. The reason is that UniqueIdentifier was (incorrectly) used for 2.5.4.45... In OpenSSL 0.9.7 I renamed the entry for 2.5.4.45 to fully comply with RFC2256. Now UniqueIdentifier is missing, as I did not uncomment the entry for RFC1274 (otherwise maybe nobody would have noted and only later strange failures would have been reported). I see. Let's discuss how to fix it!? For instance, mod_ssl 2.8.8-1.3.24 use workaround: #ifndef NID_uniqueIdentifier #define NID_uniqueIdentifier 102 #endif I don't like this option. As it is now, the new (correct) NID_uniqueIdentifier is not yet enabled. Once it is, this mechanism will fail. ## ## ## Also, markus@ created this temp patch: +@@ -102,6 +104,13 @@ + !ERROR This module requires OpenSSL 0.9.5a or higher + #endif /* OPENSSL_VERSION_NUMBER */ + #endif /* SSLDLL */ ++ ++#if OPENSSL_VERSION_NUMBER 0x00907000L ++#else ++ #ifndef NID_UniqueIdentifier ++ #define NID_uniqueIdentifier NID_x500UniqueIdentifier ++ #endif ++#endif + + static int auth_ssl_valid = 0; + static char *auth_ssl_name = 0;/* this holds the oneline name */ That looks better, but not finally good enough. I think that the correct solution would be something like: * Replace all occurences of NID_UniqueIdentifier with ID_X500UniqueIdentifier. * Then: #if OPENSSL_VERSION_NUMBER 0x00907000L #define NID_X500UniqueIdentifier NID_UniqueIdentifier #endif Of course, this will still break compatibility with application not especially prepared. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #82] `NID_uniqueIdentifier' undeclared (first use in this function)
On Thu, Jun 06, 2002 at 11:27:11AM +0300, Mike Pechkin wrote: On Thu, Jun 06, 2002 at 09:46:28AM +0200, Lutz Jaenicke via RT wrote: For instance, mod_ssl 2.8.8-1.3.24 use workaround: #ifndef NID_uniqueIdentifier #define NID_uniqueIdentifier 102 #endif I don't like this option. As it is now, the new (correct) NID_uniqueIdentifier is not yet enabled. Once it is, this mechanism will fail. When it will be enable? I don't know. As long as it is not defined, applications using it in its old form will break already during compilation. That's a good thing to make sure it doesn't stay unnoted :-) #if OPENSSL_VERSION_NUMBER 0x00907000L #define NID_X500UniqueIdentifier NID_UniqueIdentifier #endif Should this be removed after #define above will be enable? No. This section says: On older versions, NID_X500UniqueIdentifier is not available, use its old form instead. I would like to see more discussions about this issue. I have looked around some more and still find referrals like http://www.alvestrand.no/objectid/2.5.4.45.html with the UniqueIdentifier term instead of X500UniqueIdentifier. I have set [EMAIL PROTECTED], who supplied this entry, and [EMAIL PROTECTED], the maintainer of this very practical database, on the CC list. Hopefully they don't feel bothered but help in discussing this item... ( http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=82 login is guest/guest ) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/test Makefile.ssl
On Wed, Jun 05, 2002 at 03:15:18PM +0200, Lutz Jaenicke wrote: On Wed, Jun 05, 2002 at 02:47:24PM +0200, Bodo Moeller wrote: On Wed, Jun 05, 2002 at 09:01:53AM +0200, [EMAIL PROTECTED] wrote: Log: The correct PERL interpreter is passed via commandline. RCS file: /e/openssl/cvs/openssl/apps/Makefile.ssl,v retrieving revision 1.100.2.2 retrieving revision 1.100.2.3 diff -u -r1.100.2.2 -r1.100.2.3 --- Makefile.ssl2002/04/06 19:14:48 1.100.2.2 +++ Makefile.ssl2002/06/05 07:01:13 1.100.2.3 @@ -14,7 +14,6 @@ MAKEDEPPROG= makedepend MAKEDEPEND=$(TOP)/util/domd $(TOP) -MD $(MAKEDEPPROG) MAKEFILE= Makefile.ssl -PERL= perl RM=rm -f # KRB5 stuff KRB5_INCLUDES= Is there a particular reason for deleting these definitions? The value passed on the command line will override the value found in the Makefile anyway, so there should be no harm in keeping the PERL=... line. Yes, that's what I also read in the manual page. The more problems I have to explain why it didn't work as expected... (HP-UX 10.20) The reason for providing a PERL definition in the Makefile, even though it will be ignored under usual circumstances, is that otherwise very strange things might happen if make is run without a PERL definition on the command line. We could use 'PERL=false' to ensure that make will fail in a predictable way in such cases. Sounds reasonable. Probably I should take another look to find out, why it didn't work out in the first place, because it would break things again otherwise... Explanation found: When calling make in the openssl/ directory, everything is fine (with or without the PERL entry in apps/Makefile.ssl). However: when calling make test, the main Makefile will enter the test/ subdirectory, there calling make will all settings (including PERL) passed on the command line. test/Makefile.ssl will call make for the ../apps directory without passing the settings. Therefore the PERL setting in apps/Makefile will take precedence. The correct solution would therefore be, to pass all options back from withing test/Makefile (which would call crypto/ and ssl/ builds in case libcrypto and libssl are not yet build). Comments? Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #82] `NID_uniqueIdentifier' undeclared (first use in this function)
On Thu, Jun 06, 2002 at 12:39:50PM +0300, Mike Pechkin wrote: On Thu, Jun 06, 2002 at 09:46:28AM +0200, Lutz Jaenicke via RT wrote: Also, markus@ created this temp patch: +@@ -102,6 +104,13 @@ + !ERROR This module requires OpenSSL 0.9.5a or higher + #endif /* OPENSSL_VERSION_NUMBER */ + #endif /* SSLDLL */ ++ ++#if OPENSSL_VERSION_NUMBER 0x00907000L ++#else ++ #ifndef NID_UniqueIdentifier ++ #define NID_uniqueIdentifier NID_x500UniqueIdentifier ++ #endif ++#endif + + static int auth_ssl_valid = 0; + static char *auth_ssl_name = 0;/* this holds the oneline name */ That looks better, but not finally good enough. I think that the correct solution would be something like: * Replace all occurences of NID_UniqueIdentifier with ID_X500UniqueIdentifier. ^^^ You hopefully didn't take this directly and used the correct setting with the leading 'N'... * Then: #if OPENSSL_VERSION_NUMBER 0x00907000L #define NID_X500UniqueIdentifier NID_UniqueIdentifier #endif I see. Lets' back to this patch. Patch doesn't work. Now we have ssl = 0x00907000L Mine is at #define OPENSSL_VERSION_NUMBER 0x00907001L Best regards, Lutz PS. I didn't test the patch. I simply typed it into RT's communication window, so maybe there is a typo inside... -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/test Makefile.ssl
On Thu, Jun 06, 2002 at 11:29:13AM +0200, Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 6 Jun 2002 11:17:18 +0200, Lutz Jaenicke [EMAIL PROTECTED] said: Lutz.Jaenicke The correct solution would therefore be, to pass all Lutz.Jaenicke options back from withing test/Makefile (which would Lutz.Jaenicke call crypto/ and ssl/ builds in case libcrypto and Lutz.Jaenicke libssl are not yet build). Do it. Done. -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cpp0 cannot allocate ...
On Wed, Jun 05, 2002 at 02:31:35AM +0700, Satria Bakti (13297096) wrote: I'm working on AES code in openssl. After some modifications on AES code, I tried to compile it using 'make' command, but it failed. Here's the message : cpp0 cannot allocate 56915764 bytes after allocating 481876 bytes It seems, that the C-preprocessor has problems with allocating memory. Probably it cannot parse the code. I'm using i585 166Mhz machine, gcc-2.96, running on Linux 2.4.2-2. Was gcc-2.96 an official release of gcc? Wasn't it an experimental version? Try to update to gcc-3.0 or downgrade to gcc-2.95.x. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[ANNOUNCE] OpenSSL 0.9.7 beta 1 released
On Sun, Jun 02, 2002, Lutz Jaenicke wrote: The first beta release of OpenSSL 0.9.7 is now available from the OpenSSL FTP site URL: ftp://ftp.openssl.org/source/. Quite a lot of code changed between the 0.9.6 release and the 0.9.7 release, so a series of 3 or 4 beta releases is planned before the final release. ... Of course, OpenSSL 0.9.7-beta1 has been released (not 0.9.1-beta1). Please excuse any confusion caused by the typo in the Subject: line. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #69] Incorrect use of strsep in crypto/evp/evp_test.c
On Mon, Jun 03, 2002 at 04:22:33PM +0200, Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Mon, 03 Jun 2002 14:38:35 +0100, Ben Laurie [EMAIL PROTECTED] said: ben Richard Levitte via RT wrote: ben Probably because of atoi(), a last-second change was made, changing ben ustrsep to strsep on that line. Try replacing strsep with ben ustrsep, that should work better (I know it worked for me). ben ben I made the change - I think I mistyped and meant sstrsep - reason being ben atoi takes a char * not an an unsigned char *. Is that portable? I thought another reason for your implementation of ustrsep was that it would always be available even if it wasn't generally on the target system... I don't have my KR 2 at hand right now. My HP-UX manual page for atoi() however claims that atoi() is part of ANSI-C and thus the argument being a char * should also be correct, thus sstrsep() should be used. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[ANNOUNCE] OpenSSL 0.9.1 beta 1 released
The first beta release of OpenSSL 0.9.7 is now available from the
OpenSSL FTP site URL: ftp://ftp.openssl.org/source/. Quite a lot
of code changed between the 0.9.6 release and the 0.9.7 release, so
a series of 3 or 4 beta releases is planned before the final release.
To make sure that it will work correctly, please test this version
(especially on less common platforms), and report any problems to
[EMAIL PROTECTED].
Application developers that use OpenSSL to provide cryptographic
routines or SSL/TLS support are kindly requested to test their
software against this new release to make sure that necessary adaptions
can be made.
Changes between 0.9.6x and 0.9.7 include:
o New library section OCSP.
o Complete rewrite of ASN1 code.
o CRL checking in verify code and openssl utility.
o Extension copying in 'ca' utility.
o Flexible display options in 'ca' utility.
o Provisional support for international characters with UTF8.
o Support for external crypto devices ('engine') is no longer
a separate distribution.
o New elliptic curve library section.
o New AES (Rijndael) library section.
o Change DES API to clean up the namespace (some applications link also
against libdes providing similar functions having the same name).
Provide macros for backward compatibility (will be removed in the
future).
o Unifiy handling of cryptographic algorithms (software and
engine) to be available via EVP routines for asymmetric and
symmetric ciphers.
o NCONF: new configuration handling routines.
o Change API to use more 'const' modifiers to improve error checking
and help optimizers.
o Finally remove references to RSAref.
o Reworked parts of the BIGNUM code.
o Support for new engines: Broadcom ubsec, Accelerated Encryption
Processing, IBM 4758.
o PRNG: query at more locations for a random device, automatic query for
EGD style random sources at several locations.
o SSL/TLS: allow optional cipher choice according to server's preference.
o SSL/TLS: allow server to explicitly set new session ids.
o SSL/TLS: support Kerberos cipher suites (RFC2712).
o SSL/TLS: allow more precise control of renegotiations and sessions.
o SSL/TLS: add callback to retrieve SSL/TLS messages.
o SSL/TLS: add draft AES ciphersuites (disabled unless explicitly requested).
--
Lutz Jaenicke [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~jaenicke/
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Prime number returns NULL ( BN_generate_prime)
On Fri, May 31, 2002 at 06:59:05PM -0700, Praveen Dulam wrote: Hi I am testng my application on Vxworks. I am calling rsa = RSA_generate_key(512, RSA_F4, NULL, NULL); this is barfing. When I debugged I could see the rsa-p=BN_generate_prime(NULL,bitsp,0,NULL,NULL,callback,cb_arg); is resturning NULL. Can some one let me know if I miss some thing ... OpenSSL records errors it finds in its error queue. Please use the ERR_get_error() family of functions to get an indication about what was wrong. Best regards, Lutz PS. If I should give a guess, without digging deeper into it, all key-generation routines require random numbers. Did you seed the PRNG? -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util pod2man.pl
On Thu, May 30, 2002 at 03:43:34PM +0200, Bodo Moeller wrote: 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. I remember having had problems with multi line NAME sections. The solution for me was simple: I made sure that all manual pages I wrote only had a single line, even a long one, in the NAME section. We therefore do have another option for this problem. Falling back to a delivered pod2man.pl in case the system does not have however seems to be reasonable for me. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl-0.9.6c - doc/apps/smime.pod typo
On Mon, May 27, 2002 at 09:41:49PM +, [EMAIL PROTECTED] wrote: The documentation file doc/apps/smime.pod contains the '-in file' option twice in the SYNOPSIS section. ... Thanks, fixed. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #54] Compilation error m68k-next-openstep4
Obviously in enginetest.c the strdup() - BUF_strdup() migration was forgotten. I'll assign this to Richard, who takes care of the 0.9.6-engine branch. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #53] RE: Certificate
You may want to look into the details of the certificate and make sure, that the required trust settings are activated. It is not enough to simply have the certificate, but you also have to trust it. If this doesn't help, please ask this question on the openssl-users list. Best regards, Lutz PS. Please do not send .doc files. If you have to send graphics, please send them in a directly viewable and portable format like jpeg. It is a pain in the a?? to investigate .doc files, if you don't have M$ Word around, like in my case. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: your mail
On Fri, May 24, 2002 at 03:28:44PM -0700, john traenky wrote: OpenSSL is the cornerstone for Open Source projects using encryption. Has anyone done an analysis of what legalities need doing to use it legally in the United States? I have several charities and the like who'd love to use it but can't risk a legal conflict. TIA. There are three things to take care of: * Legality of using encryption: you can build and use any kind of cryptographic software in the US. If you ship sources to the world outside the USA, you have to inform the government of this fact (it does not require a permit, you just have to inform then once by). If you export binaries, you still need a permit, that however shall now be easy to obtain. That's how I understood the situation. I am german. I am living in Germany. I write OpenSource. I thus don't have to care. * Patent issues: like in science (where you can never be sure whether a theory is true unless you show that it's wrong) you can never be sure that not somebody holds or at least believes and/or claims to hold a patent on something. You only know once he sues you and it is decided in court. In Europe patents on software are not issued yet (and hopefully the european parliament doesn't get lobbyed into it by interested parts from the software industrie), so we don't have to care that much. (In some newsticker some days ago I read, that a small company sues more or less all scanner, printer etc manufacturers for having used a patented technology with respect to color management. The patent is more than 15 years old. I don't know whether it will hold up in court when not being enforced for that long time. But as you can see, you can never be sure from a surprise coming in even after decades. Man, I really prefer the german system of justice.) * Finally, there is the OpenSSL license, which comes with the package. Read it yourself: it is not very difficult. And to be honest: I rather spend my time writing software -- or even more sitting on the beach -- than trying to sue people with respect to our license :-) Hope this helps, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Security evaluation
On Fri, May 24, 2002 at 11:52:24AM -0400, Suresh N Chari wrote: I was wondering if there has been any formal security evaluation of the OpenSSL libraries especially the crypto, either by itself or in conjunction with any other product using OpenSSL. Apologies if this is the wrong forum for this question. I don't know a better forum than that. I am not aware of a formal security evaluation that has been proformed in the past. At least I have not seen any results of one. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #45] make test failed
Thanks, ticket closed, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #40] util/cygwin.sh has wrong permissions
Thanks, I have fixed it in the repository. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Semi-Official Announcement: RT2 for OpenSSL
Hi! as the readers of the openssl-dev mailing list already may have discovered, I am currently in the process of setting up a Request Tracker (using RT2 from http://www.fsck.com/) for the OpenSSL project. The request tracker is already up and running (see http://www.openssl.org/support/rt2.html) The [EMAIL PROTECTED] address is already redirected to the request tracker. Error reports sent to this address (or to [EMAIL PROTECTED]) are recorded in the request tracker and forwarded to the openssl-dev mailing list. Correspondence sent to one of the addresses with the [openssl.org #4711] marker in the subject are added to the recorded correspondence and are also forwarded to openssl-dev. TODO: The setup is not yet completed. * Currently there is no control on requestors being allowed to add a new request. After openssl-bugs was redirected, several SPAM emails immediatly popped up. I have installed an additional anti-SPAM rule to my postfix configuration, that indeed helped to catch several of these f*cking asian SPAM mails, but not all of them (and it wouldn't catch ASCII SPAM anyway). This problem is well known to RT2 users and examples are available (e.g. using procmail) on how to set up systems, so that mail for new requests must be confirmed by the requestor (just like mailing list subscriptions). I still have to set up such a system and test it. For the time being, I am moderating the input to the request tracker, so please allow for some delay.. * Requests do stimulate discussion on openssl-dev and should be recorded in the ticket. Until now only correspondence sent to openssl-bugs (or rt) is recorded. There shall be an automatic gateway that will handle this problem. It is also not set up, yet. Sorry. * Currently RT2 is running at my old university site in Cottbus. As I also support encrypted login via https (of course it is supported :-) and virtual hosts don't work via https, the official name www.aet.tu-cottbus.de is being used. On the long run, this shall be cleaned up (e.g. rt2.openssl.org). The server being located in Cottbus also means, that reliability is a little bit reduced, as mails sent to openssl.org will first be processed there (at ETH Zurich), then be forwarded to Cottbus, the reaction will be sent back to the list manager in Zurich... Unfortunately the OpenSSL project is not equipped too comfortable with computer and internet resources. As the system is not yet fully operational, I consider it good enough to send a semi-offical announcement for now. The system will have its test during the upcoming 0.9.7 beta phase :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #38] doc bug in doc/apps/x509.pod
Thanks, I have fixed the problem. I have found the missing =over 4 directly before the =back. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #36] ...
Obviously the proposed expression to catch junk like this for postfix
is not good enough:
/[^[:print:]]{8}/ REJECT Your mailer is not RFC 2047 compliant
I'll have to work on more restrictive options :-(
For now I have disabled
OnCreate NotifyRequestorsAndCcs with template Correspondence
so that new entries are no longer forwarded to the list.
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #37] Server-Client (SSL nonSSL)
[[EMAIL PROTECTED] - Wed May 15 13:25:14 2002]: Hi! i use Your project in my Client-Server project. For example, my Server calls BIO functions to use opened socket for handshaking , after that init_ssl_connection and everything works fine. But what will happen if i'll try to use client without SSL stuff ? My task is create SSL Server which can work with SSL Client and NonSSL Client. Is there any possibilities to do this using Your SSL API ? P.S. I suppose i can't because in source i found: #define readsocket(s,b,n) recv((s),(b),(n),0) it seems You don't work with MSG_PEEK or something like that. Best regards, Anatoly. I am not sure that I understand your request. If you mean, that you would like to use the same code on the server side: you can also use the BIO layer without any encryption, it is just the initialization that is different. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #32] [ ]
On Tue, May 14, 2002 at 12:42:33PM +0200, [EMAIL PROTECTED] via RT wrote: [SPAM deleted] Additional Anit-SPAM measures have been applied. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Announce: Time Stamp Protocol (RFC 3161) patch
On Fri, May 10, 2002 at 11:23:53PM +0100, Zoltan Glozik wrote: Hi All, I am working on an extension to OpenSSL that implements the Time Stamp protocol as specified in RFC 3161 and it reached a quite stable state to make it available to the public. If you are interested you can find the patch for openssl-engine-0.9.6d, installation instructions and manual at this URL: http://glozik-zoltan.int.eu.org/tsa/ Added to the list of applications. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: For 0.9.6d a is missing from the shlib/svr5-shared-gcc.sh FLAGS line
On Sat, May 11, 2002 at 03:54:52PM -0600, Boyd Lynn Gerber wrote: I just noticed that a is missing and version change. *** svr5-shared-gcc.sh.org Thu Sep 6 06:30:17 2001 --- svr5-shared-gcc.sh Sat May 11 15:37:00 2002 ... *** *** 9,15 clib=libcrypto sh_clib=$clib.so.$major.$minor ! FLAGS=-O3 -DFILIO_H -fomit-frame-pointer -pthread SHFLAGS=-DPIC -fPIC touch $sh_clib --- 9,15 clib=libcrypto sh_clib=$clib.so.$major.$minor ! FLAGS=-O3 -DFILIO_H -fomit-frame-pointer -pthread SHFLAGS=-DPIC -fPIC Hmm. In a previous mail you just stated, that the -DFILIO_H should be removed from the sco5-gcc-shared entry in Configure. In this shared library build script, you however do leave it in. Shouldn't it also be removed here? Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #26] 64 bit Suse Linux on PowerPC
Thanks. I have added a corresponding entry into config. Please check out a new snapshot for correct behaviour. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown.3 makewhatis failure under IRIX
On Thu, May 09, 2002 at 04:55:16PM -0400, Rick Troxel wrote: In order for makewhatis -M under IRIX 6.5.14m not to fail on SSL_shutdown.3 as follows: nroff: Macro argument too long; line 170, file /usr/local/man/man3/SSL_shutdown.3 stack: N I found it necessary (well, at least it was sufficient) to recast the long .Ip ...\*(N...\*(T... 4 lines as .Ip ...\*(L...\*(R... The version is openssl-0.9.6c, in case that should matter. I did not have to change the corresponding .IX Item lines. A context diff is attached. Hmm. The manual pages that come with OpenSSL are in POD format. Only during installation, they are converted to manual pages using the util/pod2man.pl script. Did you install OpenSSL from source? (In which case we would have to check pod2man for problems...) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #29] -Wl,-Bsymbolic in 0.9.6d broke shared builds
[[EMAIL PROTECTED] - Sun May 12 22:48:56 2002]: JFYI, when updating our package from 0.9.6c to 0.9.6d I've noticed that the new shared libcrypto library doesn't work anymore. The openssl(1) binary wouldn't recognize any of the block ciphers. I tracked this down to the addition of -Wl,-Bsymbolic. Removing that option solved the problem for us. This option has only recently been added. The comment in the commitlog says: Make shared libraries resolve global symbols within themselves first. Currently only on GNUish linkers... Submitted by Steven Bade [EMAIL PROTECTED] The issue was raised with respect to integration of a soft token using OpenSSL into iPlanet. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #26] 64 bit Suse Linux on PowerPC
[[EMAIL PROTECTED] - Thu May 9 22:13:32 2002]: I am trying to compile on a 64 bit Suse sles7 powerpc system. the error message indicates -m486 is an invalid compiler parameter. Anyone know the parameters I need to give ./config to get it to work for 64 bit Suse on a powerpc below are the results from running ./config without parameters and the results from running the make command. Operating system: ppc64-whatever-linux2 Configuring for linux-elf Obviously config mistakenly selects the linux-elf target that is used for x86 platforms. (This is a bug that has to be fixed.) Configure also contains an entry for linux-ppc, I however don't know whether it is suitable for 64bit PowerPC. Please try Configure linux-ppc directly instead of calling config and keep us updated, whether it works out. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #18] missing semicolon in Makefile.org
I have added the missing ; for 0.9.7-dev and -dev. We had no reports for 0.9.6d-beta1, even though the problem seems to be in it, too. I however don't want to break that version just minutes before it is released. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl Makefile.org
On Tue, May 07, 2002 at 05:10:40PM +0100, Ben Laurie wrote: [EMAIL PROTECTED] wrote: jaenicke07-May-2002 17:35:18 Modified:.Tag: OpenSSL_0_9_7-stable Makefile.org Log: Add missing ; after fi Submitted by: [EMAIL PROTECTED] PR: [openssl.org #18] Revision ChangesPath No revision No revision 1.154.2.4 +3 -3 openssl/Makefile.org Index: Makefile.org === RCS file: /e/openssl/cvs/openssl/Makefile.org,v retrieving revision 1.154.2.3 retrieving revision 1.154.2.4 diff -u -r1.154.2.3 -r1.154.2.4 --- Makefile.org 2002/04/13 12:28:49 1.154.2.3 +++ Makefile.org 2002/05/07 15:35:09 1.154.2.4 @@ -697,8 +697,8 @@ cp $$i $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \ $(RANLIB) $(INSTALL_PREFIX)$(INSTALLTOP)/lib/$$i; \ chmod 644 $(INSTALL_PREFIX)$(INSTALLTOP)/lib/$$i ); \ - fi \ - done + fi; \ + done; I can't believe this final ; is required! The ; after the fi is required, because it is a continuation line due to the \ (... fi ; done) The ; after the done should not be required. We do not handle this consistently ourselves. At several locations there is a trailing ; that should not be needed, at several other locations it is not... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Cannot compile open openssl-0.9.6d-beta1
On Sat, May 04, 2002 at 12:37:33AM +0200, Axel H. Siebenwirth wrote: On Fri, 03 May 2002, Lutz Jaenicke wrote: This definitely is a problem with your build tools. You seem to be using gnu-ld (from binutils!?) and it is failing. GNU ld 2.11.90.0.29 Copyright 2001 Free Software Foundation, Inc. Do you have any advice on what I could try to do? It says core dumped but I cannot find any such file in apps/ directory. This you can find explained in some Linux FAQs. core dumps are by default disabled in most (all?) Linux distributions. It won't help you much anyway, as the core dump would help you in analyzing ld, which you are most probably not interested in. Beyond the gcc/binutils people, that may be interested to check out the failure to improve their compiler/utilities suite, I can only recommend you to use a stable compiler if all you want is to use OpenSSL. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenVPN and OpenSSL 0.9.7 was: Re: Integration of AES algorith to OpenSSL Crypto library
On Fri, May 03, 2002 at 09:09:01AM -0600, James Yonan wrote: So, I need to know the process of integration of new cipher to Crypto library. I've tried to place the directory with new cipher (aes) inside of the crypto directory, modified root Makefile.ssl and crypto/Makefile.ssl however it seems that it is not enough - new codec does not appear in the list of supported codecs of openvpn executable. Ask the author, James Yonan, he is around on this list. And with him around asking about EVP-problems I am would guess that he already nailed down the problem with 0.9.7. OpenVPN uses the cipher-independent EVP layer of OpenSSL as an interface to the symmetric cipher algorithms. In the current 0.9.7 snapshot, the EVP API has been modified so it is incompatible with 0.9.6 -- this is probably the cause of the crash. I had the same result when I tried to test OpenVPN with 0.9.7 and AES-256. I know there's some discussion going on about fixing this, so the EVP API stays compatible. If you need something right now, I have a simple patch for 0.9.7 which will restore the 0.9.6 EVP behavior. When I applied this patch, OpenVPN ran fine with 0.9.7 and the AES-256 cipher. The following statement is not an official announcement: * We intended to put 0.9.7 into beta this week. We failed to keep this schedule. * Nevertheless 0.9.7 beta is due in the next days and a treatment of the problem will be included, most likely the old behaviour will be restored. So I would simply recommed to stay patient for the next hours/days. I didn't want to speak up before we have agreed on an official position (and my statement here still has a (quite) small risk of being wrong), but as discussion here becomes that intensive, I felt obligued to give a statement. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Cannot compile open openssl-0.9.6d-beta1
On Fri, May 03, 2002 at 10:01:52PM +0200, Axel H. Siebenwirth wrote: unfortunately openssl-0.9.6d-beta1 won?t compile on my system. I have this strange feeling that it?s because of my gcc: Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs Configured with: /usr/local/src/gcc/gcc_3.1.x/configure --enable-languages=c,c++Thread model: single gcc version 3.1 20020429 (prerelease) When linking openssl, the linker stops with an error: gcc -o openssl -DMONOLITH -I../include -fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o -L.. -lssl -L.. -lcrypto -ldl collect2: ld terminated with signal 11 [Segmentation fault], core dumped make[2]: *** [openssl] Error 1 This definitely is a problem with your build tools. You seem to be using gnu-ld (from binutils!?) and it is failing. If it?s really gcc 3.1 that?s causing the problem, can someone tell me if it might work with 3.0.x? We did not have reports about failures using gcc-3.0.x. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #16] openssl-engine-0.9.6d-beta1 crypto/Makefile.ssl patch
[[EMAIL PROTECTED] - Wed May 1 12:20:35 2002]: ! echo #define DATE \`date`\; \ ! echo #define DATE \`LC_TIME=C date`\; \ Is anybody aware of a platform on which this would cause trouble? Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Integration of AES algorith to OpenSSL Crypto library
On Thu, May 02, 2002 at 04:33:54PM +0400, Ildar Gabdulline wrote: I have one question regarding internals of OpenSSL Crypto library. The situation is as follows: I am going to integrate AES cipher to OpenSSL Crypto library. Regarding of AES algorithm implemnetation - we have the following functions: //rijndael_setup() should be called at startup of the program void rijndael_setup(RIJNDAEL_context *ctx, size_t keysize, const UINT8 *key); //rijndael_encrypt() should be called for every 16 bytes of the stream to be encrypted void rijndael_encrypt(RIJNDAEL_context *context, const UINT8 *plaintext, UINT8 *ciphertext); //rijndael_decrypt() should be called for every 16 bytes of the stream to be decrypted void rijndael_decrypt(RIJNDAEL_context *context, const UINT8 *ciphertext, UINT8 *plaintext); The question: Is anybody here who can provide me some guidelines on the integration of AES cipher to OpenSSL Crypto library ? What files should be changed/customized ? Have a look into the upcoming 0.9.7 version of OpenSSL. AES is integrated into it. Just do it the same way we did it. Hmm, or even just stop wasting your time, because it is already in there :-) Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Integration of AES algorith to OpenSSL Crypto library
On Thu, May 02, 2002 at 11:51:49PM +0400, Ildar Gabdulline wrote: I've got recent 0.9.7 snapshot but openvpn crashes when I link it with the snapshot. I am going to minimize scope of the problem as follows: 1. get stable 0.9.6 release 2. get only AES code and integrate it to 0.9.6 OpenSSL 0.9.7 will go beta soon. We intended to start beta this week, but we probably won't manage it before the weekend, so it will become next week. The problem with openvpn thus has to be resolved in the next weeks anyway, so I would rather suppose to spend your time in this direction. So, I need to know the process of integration of new cipher to Crypto library. I've tried to place the directory with new cipher (aes) inside of the crypto directory, modified root Makefile.ssl and crypto/Makefile.ssl however it seems that it is not enough - new codec does not appear in the list of supported codecs of openvpn executable. Ask the author, James Yonan, he is around on this list. And with him around asking about EVP-problems I am would guess that he already nailed down the problem with 0.9.7. Best regards, Lutz PS. Look out for OpenSSL_add_all_ciphers() to get an idea on what might be missing when integrating a new cipher. -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Adding cipher code
On Fri, Apr 26, 2002 at 02:29:46PM +0700, Satria Bakti (13297096) wrote: I'm working on integrating new cipher suite in 0.9.7, and now I come to part where I have to put my block algorithm code in crypto/ directory. Is there any guidelines/hints on how to put my cipher code there ? Code modification, header files, API, and things like that ? I am not aware about a corresponding documentation. You should probably have a look into the other implementations, like des (openssl/des, openssl/evp/e_des.c), aes, idea... It seems that the interface is not that large. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: strangeness in `x509 -noout -text` output
On Fri, Apr 26, 2002 at 12:38:05PM +0200, Robert Joop wrote:
`x509 -noout -text` prints inconsistent output.
... openssl x509 -noout -text -in old.pem | grep Issuer:
Issuer: [EMAIL PROTECTED], CN=CA UCO, O=Universidad de Cordoba, C=ES
... openssl x509 -noout -text -in new.pem | grep Issuer:
Issuer: C=ES, O=Universidad de Cordoba, CN=AC [EMAIL PROTECTED]
see the / that magically appears, instead of a , ?
if found the place that does this magic and commented it out:
... openssl x509 -noout -text -in old.pem | grep Issuer:
Issuer: [EMAIL PROTECTED], CN=CA UCO, O=Universidad de Cordoba, C=ES
... openssl x509 -noout -text -in new.pem | grep Issuer:
Issuer: C=ES, O=Universidad de Cordoba, CN=AC UCO, [EMAIL PROTECTED]
it does it because the type emailAddress starts lower case!
Your analysis is technically correct. If the object name is starting with
an uppercase letter, the / is replaced with the , , otherwise it is
not.
However: the section you are essentially removing (by commenting out)
may be there for a reason. I have not used this functionality myself,
so I don't know why this distinction is made. Therefore I am reluctant
to touch it. Steve, could you kindly have a look into this?
--- orig/openssl-SNAP-20020423/crypto/asn1/t_x509.c Wed Feb 13 20:00:30 2002
+++ openssl-SNAP-20020423/crypto/asn1/t_x509.cFri Apr 26 11:50:13 2002
@@ -460,12 +461,12 @@
for (;;)
{
#ifndef CHARSET_EBCDIC
- if (((*s == '/')
+ if (((*s == '/') /*
((s[1] = 'A') (s[1] = 'Z') (
(s[2] == '=') ||
((s[2] = 'A') (s[2] = 'Z')
(s[3] == '='))
- ))) ||
+ ))*/) ||
(*s == '\0'))
#else
if (((*s == '/')
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: strangeness in `x509 -noout -text` output
On Sun, Apr 28, 2002 at 08:07:43PM +0100, Dr S N Henson wrote: By default the code ultimately uses the old X509_NAME_print function to display DNs. This results in the weirdness mentioned and all manner of odd output if the DN contains things like BMPStrings. X509_NAME_print is only retained for compatibility. Changing it might do odd things if anyone parses or hashes its output for some reason: that isn't advisable but something might. If appropriate flags are passed to the X509_print_ex function then much more sensible output is produced using the X509_NAME_print_ex function. The -nameopt option can be used for this (see manual page): -nameopt oneline is a good place to start. I'd say that X509_NAME_print shouldn't be touched because new code should call X509_NAME_print_ex() However a new FAQ entry might be in order or possibly changing the default display options so that the old behaviour is no longer the default and adding a -nameopt old option is explicitly needed instead. -nameopt compat shall retain compatibility. Hmm, make oneline the new default? Or rather leave it as is and just add it to the FAQ. Robert Joop and Michael Bell, active in discussing DN issues, are with the OpenCA project. It should be possible for them to catch the problem by using an appropriate command line flag when calling openssl x509. With 0.9.7 we have traded compatibility in some cases. Applications linking against OpenSSL can always check OPENSSL_VERSION. This is far more difficult for applications externally calling OpenSSL's command line tools... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: 64 bit support
On Thu, Apr 25, 2002 at 05:07:27PM -0700, Paul L. Allen wrote: I just grabbed a copy of openssl-0.9.6d-beta1 and did the following on an Alpha running RedHat 6.2 with gcc=egcs-2.91.66: ./config make make test All of the tests succeeded. Are there bugs in the bignum code that don't get caught by the test suite? I'd be happy to dig into the code if someone can tell me how to reproduce the problems. Thanks for the report. Quite a lot of the bignum stuff has been touched for 0.9.7 and we would be most pleased, if you especially test out the new stuff. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: 64 bit support
On Thu, Apr 25, 2002 at 10:08:27AM -0700, Paul L. Allen wrote: Sean O'Riordain wrote: oh... on my alpha i've been consistently getting failures in the big num test stuff for a while now... that is using ./config and using gcc on redhat linux 6.0? for alpha - though iirc the compiler is more recent possibly 2.95.3? Have you reported the failures? Back when I actually had an Alpha, I had make test running cleanly all the way through. It would be a shame if another bug crept back in and stayed because nobody reported it. As can be seen from our STATUS information, we are aware that there are problems with BIGNUM on 64bit. What do we need: detailed information on platform, compiler, etc. What do we need more: somebody having this platform being willing to spend time in tracking the problem down!!! Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: test fails on SGI Irix 6.5 with openssl-0.9.6d-beta1
On Tue, Apr 23, 2002 at 03:05:30PM +0200, Martin MOKREJŠ wrote: Hi, I compiled openssl-0.9.6d-beta1 on Sgi Iriux 6.5.11 with gcc 2.95.3 and got the following error when running the make test [...] OpenSSL 0.9.6d-beta1 17 Apr 2002 built on: Tue Apr 23 12:57:56 CEST 2002 platform: irix-mips3-gcc options: bn(64,64) md2(char) rc4(idx,char) des(ptr,risc2,16,long) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -O3 -DTERMIOS -DB_ENDIAN -DBN_DIV3W Once you have reached this message, the testsuite came to the conclusion that the test succeded :-) Also, can you please tell me how to compile with cc instead of gcc? It does not seem that the config found my environment settings for CC and CXX. :( ./config prefers gcc when available and uses the irix-mips3-gcc target. Have a look into Configure and use another target, e.g. irix-mips3-cc :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PKCS #12
On Mon, Apr 22, 2002 at 05:24:04PM -0300, Raphael Amorim wrote: I need to generate PKCS#12 private key files from CryptoApi Key Containers. I'd tried to use Xenroll, OpenSSL and the RSA's PKCS#12 specification, but the files I'm generating have not been recognized as valid pkcs#12 files by another application that runs on a Linux Server and only accepts files in this format. Could you help me with that by describing the whole process? Please check out the application on the Linux server first. With a certain probability it will use OpenSSL itself, so that I would expect it to be compatible with an OpenSSL generated PKCS#12 file. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PKCS #12
On Tue, Apr 23, 2002 at 02:05:15PM -0500, raphael amorim wrote: They're using OpenSSL. By the way, you know how to use the pkcs12 command passing the container name(key pair holder in CryptoAPI) as -name parameter to obtain a .p12 file? ??? I don't know CryptoAPI. The -name option is used for the Friendly Name. It is the name that is e.g. used in Netscape when it comes to list certificates. -name Lutz Jaenicke (My CA) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Missing define in err.h
On Mon, Apr 22, 2002 at 07:25:50AM -0500, Kenneth R. Robinette wrote: In OpenSSL 0.9.6, file err.h, there is a define: #define ERR_file_name __FILE__ which is missing is 0.9.7. Is this by design or accident? From the log of err.h 1.24 - 1.25 Get rid of '#define ERR_file_name __FILE__', which is unnecessary indirection. (It cannot possibly help to avoid duplicate 'name of file' strings in object files because the preprocessor does not work at object file level.) There however still is #define COMPerr(f,r) ERR_PUT_error(ERR_LIB_COMP,(f),(r),ERR_file_name,__LINE__) left unnoted, as the macro is not used anywhere in OpenSSL. As it is part of the public interface, I will fix the macro and not just simply remove it :-) Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_CTX_set_cipher_list
On Mon, Apr 22, 2002 at 09:21:01AM -0500, Kenneth R. Robinette wrote: What it comes down to is the application is using undefined methods to force the SSL cipher list to only contain RSA:NULL:MD5 in the client cipher list. However, by using these unsupported methods, the app is not calling SSL_CTX_set_cipher_list or any of the other common methods of setting the cipher list, which results in the ssl_digest- methods[] array not being initialized. Somehow this array must get initialized during OpenSSL dll setup, but so far I have not been able to track down where that is being done. When I use the correct method of setting the cipher list using SSL_CTX_set_cipher_list, everything works as it should, with both the dll's and the static link. However comments in the old code indicate problems in this area in older versions of OpenSSL, thus I guess the use of the unsupported methods. What would be the correct method to force the client cipher list to only contain RSA:NULL:MD5 that would work with all recent versions of OpenSSL? What about SSL_CTX_set_cipher_list() :-) Anyway: ssl_create_cipher_list() is responsible for initializing ssl_digest_methods() via load_ciphers(). ssl_create_cipher_list() is called from SSL_CTX_new() (in 0.9.7 and I would suspect in older versions, too), so that I don't see why it should make a difference with respect to dll setup... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PRNG support on Solaris for openssl-0.9.6d
On Sat, Apr 20, 2002 at 09:43:28PM -0500, Carlo Marcelo Arenas Belon wrote: i got this patch backporting (sorta - for sure not as elegant as Lutz code on 0.9.7 but i didn't wanted to make too many changes on the 0.9.6 code so the patch looks clear) the prngd support that comes with openssl 0.9.7 over the openssl-0.9.6c code (appended at the end and available from ftp://ftp.sajinet.com.pe/pub/misc/crypto/openssl/openssl-0.9.6c-egd.patch) Actually, one can simply replace the code for 0.9.6 with the code from the 0.9.7 tree and add the appropriate definitions to e_os.h. That's all. and that the openssl-0.9.6d is on beta, could support for a prng on Solaris be a good idea on the source? When the 0.9.7 PRNG extensions were complete, it was decided that the change was too large to call it it a bugfix, therefore it was not backported to the 0.9.6 tree. 0.9.6 is dead and gone (at least from the development point of view), we won't make any modification to 0.9.6d any longer, except for vital bugfixes as long as beta is open. All of our efforts will now go into getting 0.9.7 out of the door. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: New cipher suite
On Sat, Apr 20, 2002 at 06:38:01PM +0700, Satria Bakti (13297096) wrote: I'm working on openssl 0.9.6 (and SSL generally) and trying to implement new cipher suite. 0.9.6 is finished, jump onto the 0.9.7 wagon. The new cipher suite will be : SSL_RSA_WITH_ABLOCKCIPHER_CBC_SHA What files should I create (and where to put it) ? and which files needed to be modified. Have a look into ssl/s3_lib.c. There the cipher suites are selected. Then check out ssl/ssl_ciph.c, where part of the interfacing is initialized. Start there for the integration into the TLS/SSL layer. In parallel have a look into the EVP layer and how to add your new cipher to the lists (follow OpenSSL_add_all_algorithms()). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [RFA] New script util/cygwin.sh
On Fri, Apr 19, 2002 at 08:42:12PM +0200, Corinna Vinschen wrote: Hi, I've attached a file which I'd like to get into the ssl source tree. It's a script which automatically generates the binary runtime and development tar archives as they are provided by the Cygwin net distribution. It's definitely not a must have but I thought it would be helpful for others to reproduce a Cygwin release version... Thanks, added to 0.9.6d, 0.9.7, and -dev. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Revised DOS patch for openssl-0.9.7
On Sun, Apr 21, 2002 at 11:40:56AM -0700, Doug Kaufman wrote: On Sun, 21 Apr 2002, Corinna Vinschen wrote: Oh and, btw., current Cygwin is 1.3.10, 1.3.11 coming soon. Why are you testing with a version which is almost a year old? It was just what was installed on my machine. I hadn't updated in a while. Thanks for the reminder. I am now at 1.3.10. Does it work now without your patches? Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[bs@bsws.zid.tuwien.ac.at: openssl-0.9.6d-beta1 on AIX 3.2.5 und ULTRIX V4.5]
The following success report I received as part of a private discussion. I can report success for 0.9.6d (normal and engine) on HP-UX 10.20 with both HP's ANSI-C and gcc-3.0.3 - Forwarded message from Bernhard Simon [EMAIL PROTECTED] - Bravo! - Alles funktioniert out-of-the-box! Sogar auf den alten Systemen. TRU: Digital UNIX V4.0E, GNU bc 1.06, cc, gcc 2.95.3 AIX: AIX 3.2.5 (325102), GNU bc 1.06, cc 1.3.0.44, gcc 2.95.3 ULT: ULTRIX V4.5,GNU bc 1.06, cc, gcc 2.95.3 Falls Ihr eine success/fail Liste habt, hier sind 6 success Eintraege: time (in sec) make test install make testhardware - alpha-ccOK OK OK 376 63Digital PWSau 433 alpha-gcc OK OK OK 623 63Alpha EV5.6 (21164A) 433MHz aix-ccOK OK OK 1820220IBM RS/6000-390 aix-gcc OK OK OK 1740202POWER2 67MHz ultrix-ccOK OK OK 5532 2009DECstation 5000/120 ultrix-gcc OK OK OK 9321 2003MIPS R3000 20MHz - linux-elf OK OK OK 186 18P3/800 RHL-7.2, gcc 3.0.4 Die Ultrix Zeiten sind nicht vernachlaessigbar, ein Durchlauf dauert mehr als 2 (cc) bzw. 3 (gcc) Stunden. Am PC geht's deutlich besser. ;-) - End forwarded message - Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: problem with openssl-0.9.5 on AIX3.2
On Fri, Apr 19, 2002 at 04:23:19PM -0700, Nir Goldman wrote: I'm trying to install openssl-0.9.5 on an old AIX3.2 machine so I can eventually install openssh-3.1. Whenever I try to build with 'make', I get the following long list of errors (this is a partial list): Latest OpenSSH requires at least version 0.9.6 of openssl, please give the new versions a try. We have just released 0.9.6d beta1. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP incompatibility from 0.9.6 to 0.9.7
On Fri, Apr 19, 2002 at 05:01:02AM -0600, James Yonan wrote: The following program succeeds on 0.9.6 but fails on 0.9.7. It tests the feature of calling EVP_CipherInit once to build a key schedule, then cycling through calls to EVP_CipherInit, EVP_CipherUpdate, and EVP_CipherFinal to encrypt/decrypt multiple messages with the same key. Is this a bug or a design change to the EVP layer? The ability to recycle an EVP_CIPHER_CTX is important to avoid having to reconstruct a key schedule for every message, when the key stays the same and only the IV changes. Is there a better way to do this that works on both 0.9.6 and 0.9.7? The EVP interface has been changed between 0.9.6 and 0.9.7 in an incompatible way. We are aware of problems caused by this change and there is currently an internal discussion going on how to handle the situation, including the option to revert to the old behavior. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Small patch to 0.9.6c crypto/objects/obj_dat.c
On Wed, Apr 17, 2002 at 09:43:07PM -0700, Howard Chu wrote:
I just checked the CVS head and this patch should be valid there as well:
diff -u -r1.1 obj_dat.c
--- obj_dat.c 2002/04/18 04:34:17 1.1
+++ obj_dat.c 2002/04/18 04:35:10
@@ -437,8 +437,7 @@
return(0);
}
- nid=OBJ_obj2nid(a);
- if ((nid == NID_undef) || no_name) {
+ if (no_name || (nid=OBJ_obj2nid(a)) == NID_undef) {
len=a-length;
p=a-data;
(Just a slight speedup when I'm munging DNs by OID...) I hope you can commit
this for 0.9.6d/0.9.7 without too much trouble. :)
I have applied the change to all trees including 0.9.6d.
0.9.6d is already in beta, so I was a bit reluctant to apply the change,
but finally decided that the change is small enough.
Best regards,
Lutz
PS. Please do not embed patches in the text but better send it as
attachement. In your mail the TAB was transfored to SPACEs, so that
the patch utility could not apply it.
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: openssl 0.9.7 and debug
On Thu, Apr 18, 2002 at 01:36:39PM +0200, Jean-Marc Desperrier wrote: ./config -d on a standard linux box (RedHat 7.1) gives : Operating system: i686-whatever-linux2 This system (debug-linux-pentium) is not supported. See file INSTALL for details I think that out of the box debug support for this kind of platform is needed. Thanks, fixed. The debug-linux-pentium was missing (-pentiumpro and -k6 where there). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Stratus OpenSSL diffs and test results.
On Tue, Apr 16, 2002 at 02:32:11PM -0400, Sundaram, Mani wrote: Ben Laurie suggested that we send our OpenSSL diffs to the developers for review. We would like to call our port as VOS OpenSSL; we request your permission to use the OpenSSL name. Our changes include adding header files to compile on VOS - mostly sys/types.h and sys/select.h. This is because on the Linux OpenSSL code base, time.h includes types.h and select.h whereas in VOS it does not. There are two other changes that we did to the code: 1. VOS doesn't support getrusage( ) or ftime( ). However, we do support gettimeofday( ) and times( ). We had to write a new else condition in speed.c to handle this case. We haven't modified the functionality of the code. 2. gcc -Wall warns when sprintf (foo, %d, foobar) is called (foobar is a long datatype). We fixed this. We believe that these changes are platform specific only and no functionality of the product has been compromised. We didn't delete any source code. We are enclosing the diff and the self-test results. We would appreciate your prompt reply with the approval of our changes and the use of the OpenSSL name. Please do not hesitate to contact us if you need further information. You already received other statements about your submission. 0.9.6 is closed. Please contribute against 0.9.7. If you hurry up, it may still make it into 0.9.7, going to be released soon. I will add some more statements on the fly. diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/app_rand.c /p/openssl/porting_base/apps/app_rand.c 145,147d144 #ifdef VOS_DEBUG printf(\n file = %s, file); #endif /* VOS */ Please remove debugging statements, patches should be least intrusive. diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/dh.c /p/openssl/porting_base/apps/dh.c 63,65d62 #ifdef __VOS__ #include sys/types.h #endif Please check out e_os.h. Other operating systems have similar problems and these problems are handled in e_os.h. diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/openssl.cnf /p/openssl/porting_base/apps/openssl.cnf 8a9 RANDFILE= $ENV::HOME/.rnd 36c37 dir= ./demoCA# Where everything is kept --- dir = ./demoCA # Where everything is kept 39,40c40,41 database = $dir/index.txt # database index file. new_certs_dir = $dir/newcerts # default place for new certs. --- database= $dir/index.txt# database index file. new_certs_dir = $dir/newcerts # default place for new certs. It seems that there is no difference in the contents (except for RANDFILE) but probably only indentation diffs. Please edit these out before submitting. diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/speed.c /p/openssl/porting_base/apps/speed.c 72,80d71 #ifdef __VOS__ #ifndef _BSD #define _BSD /* for gettimeofday() */ #endif /* _BSD */ #ifndef _SYSV #define _SYSV #endif /* _SYSV */ #endif /*__VOS__ */ This change does make sense to me. In how far are _BSD and _SYSV symbols involved, when just the VOS case should be handled. 84c78 #define SIGACTION /* Define this if you have sigaction() */ --- /* #define SIGACTION */ /* Define this if you have sigaction() */ Are you sure that this will not break other platforms? /p/openssl/dev.0.9/src/openssl-0.9.6/crypto/opensslconf.h /p/openssl/porting_base/crypto/opensslconf.h 6,11c6 # ifndef NO_IDEA # define NO_IDEA # endif # ifndef NO_RC5 # define NO_RC5 # endif --- /* no ciphers excluded */ 16,18d10 # ifndef NO_ASM # define NO_ASM # endif 28c20 #define OPENSSLDIR /system/openssl --- #define OPENSSLDIR /usr/local/ssl 77c69 #define BN_LLONG --- #undef BN_LLONG Please do not change OpenSSL build defaults in a platform specific patch. 17c13 #include string.h --- #include strings.h This may break other platforms. diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/test/tcrl /p/openssl/porting_base/test/tcrl 80c80 /system/gnu_library/bin/rm -f f.* ff.* fff.* --- /bin/rm -f f.* ff.* fff.* This will most likely break other platforms. (More of these deleted.) Additional note: We collect platform specific settings in Configure. Please add a corresponding entry for your OS (and a detection routine for config, if applicable). You will see, that your patch will shrink significantly, when following my advice. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL
Announcement of OpenSSL 0.9.6d and 0.9.7 Release Plan and Schedule
Announcement of OpenSSL 0.9.6d and 0.9.7 Release Plan and Schedule == The OpenSSL developers team is pleased to announce the upcoming release of OpenSSL 0.9.7. OpenSSL 0.9.7 contains several changes and enhancements in many fields; please check out the NEWS and CHANGES files for details. Some of the changes made break compatibility, so that application developers and distribution providers may need a transition period. We have therefore decided for a 2-step strategy: * Release 0.9.6d: OpenSSL 0.9.6d will be the last release of the 0.9.6 series, containing all of the latest bugfixes while maintaining compatibility. * Release 0.9.7: OpenSSL 0.9.7 contains many enhancements and some incompatible changes. It also includes the bugfixes found in 0.9.6d (except for those obsoleted by other changes). We intend to provide releases according to the following schedule: 16 Apr 2002: 0.9.6d-beta1 30 Apr 2002: 0.9.6d The changes between 0.9.6c and 0.9.6d are quite small so that we do not expect too many problems. Therefore only one beta release is planned. 30 Apr 2002: 0.9.7-beta1 13 May 2002: 0.9.7-beta2 ... As the changes between 0.9.6x and 0.9.7 are numerous, we are prepared to handle more beta releases. The number of beta releases may change with error reports coming in. If no more errors are found after beta2, the final release will be made. If more errors are found in beta2, beta3 will be introduced and so on. Testing 0.9.7-beta... does not only mean to download and call make install and/or make test on different platforms. We explicitely ask application developers and users to test out the functionality of applications and/or integrate new functionality or adjust to the API changes. If these checks are not done in the beta phase and applications are only tested once 0.9.7 is released, bug fixes may be delayed until the release of 0.9.7a, if required. Be reminded that changes are also available via the daily snapshots. Incompatible Changes with 0.9.7: - List will be provided with the 0.9.7-beta releases. Known Problems with 0.9.7: == From the OpenSSL STATUS file: o BIGNUM library failures on 64-bit platforms (0.9.7-dev): - BN_mod_mul verificiation (bc) fails for solaris64-sparcv9-cc and other 64-bit platforms Checked on Result alpha-cc (Tru64 version 4.0)works linux-alpha+bwx-gcc doesn't work. Reported by Sean O'Riordain [EMAIL PROTECTED] OpenBSD-sparc64 doesn't work. BN_mod_mul breaks. Needs checked on [add platforms here] - BN_mod_mul verification fails for mips3-sgi-irix unless configured with no-asm Bug reports: - Bug reports should be sent to [EMAIL PROTECTED], reports are copied to openssl-dev. - Success reports may be sent to openssl-bugs too, to indicate successfull operation and help other people to narrow their problems down. Downloads: == - Files will be made available at the usual locations at OpenSSL.org. - Seperate announcements will be made for each beta and release. Yours, The OpenSSL Project Team... Mark J. Cox Richard LevitteAndy Polyakov Ralf S. Engelschall Bodo MöllerHolger Reif Dr. Stephen Henson Ulf Möller Geoff Thorpe Ben Laurie Lutz Jänicke __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Virus/Faked email addresses
On Tue, Apr 16, 2002 at 09:06:01AM +1000, Steven Reddie wrote: Perhaps blocking attachments on the current lists, and setting up an additional openssl-patches list that accepts attachments would work. Most people would not bother subscribing to the patches list anyway. Steven -Original Message- [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Kaufman On Mon, 15 Apr 2002, Geoff Thorpe wrote: I would personally +1 any proposal to have the listserver block any posts that; (a) contain attachments (b) aren't ASCII (ie. block HTML, RTF, etc) Anyone needing to distribute files can find some other legitimate way to do it. Attachments are often the only way to distribute patches to the list that don't get munged by the archiving software, so that they remain available in the list archives. An occasional inappropriate post shouldn't be enough to change the way the list operates. Doug There would be still another option: all current MTAs support interfacing to virus checkers (my setup is Postfix/Amavisd/Sophie). Even though not perfect (a virus would still pass until the virus signature is available) it would probably help quite a lot. Most virii spread on mailing lists are old enough :-) I am however not sure about Ralf's setup. Virus scanners are payware (and with respect to the fast update service required I do not expect anything like this to be available for free) and somebody has to shell out the money. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Wrong DNs
On Mon, Apr 15, 2002 at 08:57:00PM +0200, Michael Bell wrote: Hi, we found today a big problem with the DNs which OpenSSL displays because our application (OpenCA) produce DNs which are conform to the directorystandards but OpenSSL interprets them in the opposite order. What does this mean? Here an example: The root of our directory is the following: o=HU, c=de The organizational unit for the PKI is Test-CA. So the next DN in the directory must be: ou=Test-CA, o=HU, c=de A certificate would have the DN cn=bell, ou=Test-CA, o=HU, c=de. It is no problem to produce this DN with OpenSSL but then we were a little bit shocked when we see the DNs of Thawte, VeriSign, Entrust etc. with OpenSSL. They have all the format c=US, o=VeriSign, ... (openssl-*/cerst/). All these trustcenters use LDAP-servers but these DNs can never be stored in a directoryserver! So it looks like OpenSSL displays the different parts of a DN in the wrong order. Did I make a misinterpretation? If this is a bug then I have the next question, can you fix this in the 0.9.7-tree? It is possible to protect the old index.txt etc. by adding an option -x500 or something like this to get a DN which can be inserted in a directoryserver. The problem is that OpenSSL interprets a correct DN with openssl req -subj 'cn=...,c=de' in the wrong order (so we get a wrong certificate). I know no optimal solution except of adding such an option to every related command or add an option like -oldstyledn to openssl x509 and openssl ca but before starting discussing solutions I will wait for an answer (bug or misinterpretation). Hmm. As far as I could see with openssl x509 and openssl asn1parse, certificates are printed in the order of the data inside the certificate. Whatever this means :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL/Java JSSE Handshake problem...
On Mon, Apr 15, 2002 at 11:23:49PM +0200, David Maurus wrote: Andreas Sterbenz wrote: For the Sun JSSE provider, the default enabled protocols are SSLv3, TLSv1, and the pseudo protocol SSLv2Hello. The latter means that client hello messages are sent/ accepted in SSLv2 format. This is for better error diagnostic when talking to SSLv2 only implementations. After revisiting Eric Rescorla's SSL and TLS, I come to the conclusion that for the client, starting with a SSLv2 ClientHello msg would also be useful to talk to a server that might be a version 2 server. At least in SSLv3 it was specified for the server to continue with a v3 handshake, if it was able to support the version number sent be the client (see page 135 of SSL and TLS). The result is that with the default settings a V2 client hello message requesting TLS 1.0 is sent. ...which is the most compatible way to speak to any unknown SSL/TLS server. Shouldn't OpenSSL answer this v2 ClientHello with SSL-version no. 3.1 by continuing with a TLS handshake? Or was this compatibility option left out in OpenSSL by purpose? RFC2246 ( http://www.ietf.org/rfc/rfc2246 ) states (Page 65): TLS 1.0 clients that support SSL Version 2.0 servers must send SSL Version 2.0 client hello messages [SSL2]. TLS servers should accept either client hello format if they wish to support SSL 2.0 clients on the same connection port. The only deviations from the Version 2.0 specification are the ability to specify a version with a value of three and the support for more ciphering types in the CipherSpec. Warning: The ability to send Version 2.0 client hello messages will be phased out with all due haste. Implementors should make every effort to move forward as quickly as possible. Version 3.0 provides better mechanisms for moving to newer versions. The option to support the SSLv2 client hello is part of the SSLv23_method(). The TLSv1_method() is pure TLSv1, no SSLv2 client hello. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Virus/Faked email addresses
Hi! It seems that some hours ago some more or nice person (or software) sent out a virus using my email address: * The From: line is wrong: From: Lutz.Jaenicke [EMAIL PROTECTED] My full name (which is always inserted by mutt :-) does not contain a dot. * The User-Agent: Header is missing: User-Agent: Mutt/1.3.27i is not there. :-) :-) * The email was not received from my site but from: Received: by en5.engelschall.com (Sendmail 8.9.2) via SMTP for [EMAIL PROTECTED] from apedge.com id HAA00464; Mon, 15 Apr 2002 07:35:57 +0200 (MET DST) * My HP-UX boxes are not vulnerable to virii infecting M$-systems. * My mailserver is running Postfix with Amavis. It would not have let pass the virus when leaving my site :-) * The virus scanner did not even let in the infected mail when coming back from the mailing list, so I did not even detect myself the somebody used my email address... (I simply tend to press the D button when virus warnings come in with respect to mailing lists, because ill configured virus scanners tend to spam the mailing lists...) * Use HP-UX, Linux or another appropriate operating system to reduce your risk of getting affected by virii :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Virus/Faked email addresses
On Mon, Apr 15, 2002 at 01:36:56AM -0700, David Bronaugh wrote: Yeah, wasn't saying it was anything you did; just bugs me when people do that crap. My comment wasn't targeted at you. As I do post to this list quite often and as a member of the openssl developers team I felt that I should give a statement about the situation. I am not really easy to affect either, since I use a crappy graphical mail client under Linux; nonetheless, I understand quite a few people on this list may use OE or similar. I am afraid that this statement is quite correct :-( Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem with mail and RFC 1700
On Fri, Apr 12, 2002 at 10:53:38AM +0200, Michael Bell wrote:
I read RFC 1700 and I don't see why we should get problem if we rename
internet 7 in crypto/objects/objects.txt from mail to
internetMail. Nobody should ever use a direct reference to these
#defines. Only objects.txt would use this name and if the first user
need a subtree then we simply insert mimeMHS as next subtree below
internetMail.
On the risk on sounding bureaucratic...
I have checked out both RFC1274 and RFC2247 and I could not see mail
being listed anywhere.
However from RFC1495
5 OID Assignments
MIME-MHS DEFINITIONS ::= BEGIN
mail OBJECT IDENTIFIER ::= { internet 7 }
mime-mhs OBJECT IDENTIFIER ::= { mail 1 }
mime-mhs-headings OBJECT IDENTIFIER ::= { mime-mhs 1 }
id-hex-partial-message OBJECT IDENTIFIER ::=
{ mime-mhs-headings 1 }
id-hex-multipart-message OBJECT IDENTIFIER ::=
{ mime-mhs-headings 2 }
mime-mhs-bodies OBJECT IDENTIFIER ::= { mime-mhs 2 }
END
I come to the conclusion that I prefer to leave mail for use in the
internet 7 class.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Problem with mail and RFC 1700
On Mon, Apr 15, 2002 at 02:26:06PM +0200, Michael Bell wrote: Lutz Jaenicke schrieb: I come to the conclusion that I prefer to leave mail for use in the internet 7 class. I have no problem with this but what do you want to with the short name for an RFC822mailbox? Do you want to ignore the warning or do you want to ignore the shortname? Please ignore my ignorance, but I just had a second look into RFC1274 and I could not find any reference about mail being a short name for rfc822Mailbox. The problem is that OpenSSL mixes OID definitions and attributenames. Perhaps there are too much magic things. That seems to be quite true. Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem with mail and RFC 1700
On Mon, Apr 15, 2002 at 02:51:49PM +0200, Michael Bell wrote: Lutz Jaenicke schrieb: Please ignore my ignorance, but I just had a second look into RFC1274 and I could not find any reference about mail being a short name for rfc822Mailbox. See: RFC 2798 -- 9.1.3 -- 4th attribute Ok, I am convinced :-) I also see a document from Entrust (Entrust Directory Schema Definition) where email is used as short name for emailAddress so perhaps it is allowed but I found this nowhere else. This document I also found during my research, but that source is not authoritative, is it? Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Futher debug of possible race condition in 0.9.6b/c
On Fri, Apr 12, 2002 at 11:38:34PM -0600, Dax Kelson wrote: On Fri, 2002-04-12 at 22:30, Geoff Thorpe wrote: Can you get any log messages from the server as to errors it is reporting at the time these connections are being dumped that are *not* reported when the connections are going OK? It could be a race condition above the LDAP layer, or inside it (above the SSL layer) - and it might also turn out to be associated with the first connection/stream rather than the second. (Though knowing nothing about the application in question, it's difficult to know what the relationship between those two are - different threads?) Either way, it looks like the decision to break ties is made at the server, so that's probably where you should look to for clues as to why. I will see if I can dig something up. The server is OpenLDAP 2.0.22 running on NetBSD-1.5.2 mips. NetBSD-1.5.2 seems to come with openssl 0.9.5a, OpenLDAP is linked against that openssl. The clients are Red Hat Linux 7.2 boxes. I'm using nss_ldap and pam_ldap to have my user database and authentication performed out of LDAP. The clients have openssl 0.9.6b and I've also tried 0.9.7c. I'm doing starttls between the clients and server. When logging in nss_ldap makes the first LDAP over TLS connection to verify my user exists, and then when I supply my password pam_ldap makes the second LDAP over TLS to check my password. This second one is the one that fails. I have about 20 clients that have ~500Mhz cpus and everything works perfectly. On about 15 clients with 1700Mhz cpus, the second pam_ldap connection fails *unless* I bog down the client machine. Another clue. When I turn off nss_ldap and have my user account listed in /etc/passwd,/etc/group, but *still* use pam_ldap to get perform the password checking out of the LDAP server, it works! Your ssldump output is missing the cleartext negotiation including the STARTTLS command (there is a switch to make ssldump also show this part). I however doubt it will lead us anywhere. The analysis so far pretty much shows, that the server is closing down the connection. I must admit that I did not work with OpenLDAP, yet. Is OpenLDAP a multithreaded application? It might be possible that they have a race condition that leads to problems when a new connection is coming in from some host, while the old connection is not yet considered closed... Anyway we would need the output and error messages from the LDAP server. The ssldump output indicates that a new connection is attempted all the time, so that there should be no problem with session resumption. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Fwd: [BUG suggested PATCH] EVP_DecodeUpdate 0.9.6b 0.9.6c
On Fri, Apr 12, 2002 at 09:59:58AM +0200, Pavel Tsekov wrote: This is a forwarded message From: Pavel Tsekov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Thursday, April 11, 2002, 12:39:59 PM Subject: [BUG suggested PATCH] EVP_DecodeUpdate 0.9.6b 0.9.6c Any comments on this ? I posted on openssl-users but got no response at all - either confirming on denying... Your posting is still in my incoming queue. Obviously my team mates normally dealing with EVP issues are currently too busy to take care of it. But it won't be forgotten :-) Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: bug in ssl code
On Fri, Apr 12, 2002 at 01:59:17AM +0300, Arne Ansper wrote: [Detailed analysis about problems with state machine/non-blocking sockets when using implicit handshake deleted] Probably Bodo has more in-depth knowledge about this than myself, but let't start discussing it anyway :-) You do not point out in which version the problem occurs. Does it still occur with recent snapshots? Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Session cache / non-block membuf impl.
On Thu, Apr 11, 2002 at 02:35:16PM +0200, Øivind H. Danielsen wrote: The following two ssl3 negotiations illustrate a problem I have been having with the local variable got_new_session in the (s3_srvr.c) SSL3_accept function: [analysis deleted] You do not state which version of openssl you are using. There was a bug in 0.9.6c that was fixed in current snapshots (and therefore will be fixed in 0.9.6d and 0.9.7): *) The earlier bugfix for the SSL3_ST_SW_HELLO_REQ_C case of ssl3_accept (ssl/s3_srvr.c) incorrectly used a local flag variable as an indication that a ClientHello message has been received. As the flag value will be lost between multiple invocations of ssl3_accept when using non-blocking I/O, the function may not be aware that a handshake has actually taken place, thus preventing a new session from being added to the session cache. To avoid this problem, we now set s-new_session to 2 instead of using a local variable. [Lutz Jaenicke, Bodo Moeller] Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: X509_vfy.c function int check_issued() BUG..
On Wed, Apr 10, 2002 at 03:22:30PM -0400, Aslam wrote: I've been doing testing for new root ca certificate issuance and openssl's chain building/cert chain validation. And if I have both root ca old cert and root ca new cert (obtained by certificate refresh, i.e. old subject and old key pair is used to get the root ca new cert for a new time period) and time is such that root ca new cert is NOT_YET_VALID and new cert is added last in X509_STORE, then chain building fails with error = CERT_NOT_YET_VALID, even though valid root ca cert (old) is there in X509_STORE. Function static int check_issued(X509_STORE_CTX* ctx, X509* x, X509* issuer) in x509_vfy.c does check for subject dist name, subject/issuer key identifier, basic constaints etc match, but cert time validation is deffered till we have a stack bottom = end entity cert and top = self_signed root cert, i.e. till static int internal_verify(X509_STORE_CTX* ctx). So cause of this root ca new cert is added to the stack, but later in the internal_verify() call it fails with CERT_NOT_YET_VALID, what should happen is cert time validity must be done during building cert chain (adding certs to stack), not after it. So in all all certs in X509_STORE must be lloked before calling internal_verify() for cert signature check. Similar behaviour is seen if old cert is added last (top of the stack in X509_STORE) and it is expired, then error = CERT_EXPIRED, provided issued cert is still valid, which is basically a wrong practice to issue certs beyond CA valid time period. I am not sure that I understand you correctly. You have issued a new CA certificate based on the old key and tried to mimic the old certificate as good as possible. Now the verification routine has problems to distinguish between these certificates. The verification routines distinguish * the DN Distinguished Name * the AKID/SKID (authority key identifier of issued certificate must match the subject key identifier of the CA) * the serial number in the authority key identifer. You therefore could assure correct behaviour by making at least one of these properties different. To be fair: I don't have the time to look around for it, but I would expect that in some RFC this would also be listed as a requirement :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: wrong defines SN_xyz
On Wed, Apr 10, 2002 at 12:36:33PM +0200, Michael Bell wrote: Lutz Jaenicke schrieb: On Tue, Apr 02, 2002 at 10:07:27PM +0200, Lutz Jaenicke wrote: On Tue, Apr 02, 2002 at 09:25:00AM +0200, Michael Bell wrote: after I found the wrong definitions of SN_surname and SN_serialNumber I looked around and find the next problems in crypto/objects/ : SN_titletitle (now T) SN_description description (now D) SN_givenNamegn(now G) SN_initials initials (now I) LN_uniqueIdentifier x500UniqueIdentifier (now uniqueIdentifier) SN_rfc822Mailboxmail (now rfc822Mailbox) SN_pkcs9_emailAddress emailAddress (now Email) * SN_rfc822Mailbox is not wrong but a short name exists * I don't find a short name for SN_pkcs9_emailAddress. The related RFC only defines a long name Hmm... I have implemented the changes you recommend, but now I get a warning about a shortname mail to be defined twice. Maybe this was the reason why it was left out... I have attached the patch (including the problem). What do you recommend? Only objects.txt contains all necessary information; run the PERL scripts as used in Makefile.ssl to rebuild the other files. You only want to attach the patch :) Haha, if I would have to pay a fee every time I forget to press the a button... (In fact, that is a problems of the mutt user interface, you cannot press a once you think of the attachement but you have to remember when you finished editing...) The problem is that openssl does some magic things. mail -- internet 7 -- iana 7 -- dod 1 7 -- org 6 1 7 -- iso 3 6 1 7 -- 1.3.6.1.7 So let's start searching for this attribute but it is not an attribute. It is a hole subtree (http://www.alvestrand.no/objectid/1.3.6.1.7.html). Nevertheless the subtree is not part of objects.txt or any other file of OpenSSL so it is not a problem to change the name because mail or Mail was never used a reference. So we can change the name of internet 7 without any problems. I would like a name like internt_mail or internetMail. What do you think? Doen't sound bad. I would say internetMail would fit better into the usual naming scheme... Best regards, Lutz PS. Yesterday's attachement attached :-) -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus Index: objects.txt === RCS file: /e/openssl/cvs/openssl/crypto/objects/objects.txt,v retrieving revision 1.20.2.3 diff -u -r1.20.2.3 objects.txt --- objects.txt 2002/04/04 17:49:39 1.20.2.3 +++ objects.txt 2002/04/09 19:51:14 @@ -96,7 +96,7 @@ pkcs 9 : pkcs9 !module pkcs9 -pkcs9 1: Email : emailAddress +pkcs9 1: : emailAddress pkcs9 2: : unstructuredName pkcs9 3: : contentType pkcs9 4: : messageDigest @@ -534,12 +534,12 @@ X509 8 : ST: stateOrProvinceName X509 10: O : organizationName X509 11: OU: organizationalUnitName -X509 12: T : title -X509 13: D : description +X509 12: : title +X509 13: : description X509 41: name : name -X509 42: G : givenName -X509 43: I : initials -X509 45: : uniqueIdentifier +X509 42: gn: givenName +X509 43: : initials +X509 45: : x500UniqueIdentifier X509 46: dnQualifier : dnQualifier X509 72: role : role @@ -703,7 +703,7 @@ pilotObjectClass 22: : qualityLabelledData pilotAttributeType 1 : UID : userId pilotAttributeType 2 : : textEncodedORAddress -pilotAttributeType 3 : : rfc822Mailbox +pilotAttributeType 3 : mail : rfc822Mailbox pilotAttributeType 4 : info pilotAttributeType 5 : : favouriteDrink pilotAttributeType 6 : : roomNumber
Re: wrong defines SN_xyz
On Wed, Apr 10, 2002 at 01:13:05PM +0200, Michael Bell wrote: Lutz Jaenicke schrieb: Doen't sound bad. I would say internetMail would fit better into the usual naming scheme... I would prefer it too. Hmm. Just had another look into RFC1700... Even though it is not yet used in objects.txt, we will run into a problem once the first people start trying to use the subtree... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: VxWorks and OPEN SSL questions -
On Mon, Apr 08, 2002 at 08:39:11PM -0400, Bill Pringlemeir wrote: Praveen Bill Thanks for the help. I am coming along with my Praveen compilation on VxWorks platform. I am struck when I am tryo Praveen to compile the crypto/bio files. This is some to do with Praveen openssl/e_os.h Praveen When I removed the line sys/params.h from the e-os.h, then Praveen I get error from bss_bio.c. Praveen I am getting lost some where here. [ Hopefully people on openssl-dev don't mind this discussion? It seems slightly relevant. ] At least I don't mind and I am quite convinced that the discussion is relevant, as other readers may work on the same topic or might do so in the future. I have made modification to e_os.h as follows, ... If I am suppose to send this to some American government facility, I will stop posting any more information. I am not a lawyer, but discussions you send should be covered by the right on free speech. If you are going to send patches to be included, it should however be copied through to your government. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL/Java JSSE Handshake problem...
On Mon, Apr 08, 2002 at 06:23:12PM -0500, Kevin Regan wrote:
Hi,
The client and server are hanging at the moment (I have them both set up to
defer the handshake until they actually start doing reads and writes). Here
is the output from the Java (client) side:
%% No cached client session
*** ClientHello, v3.1
RandomCookie: GMT: 1001529913 bytes = { 73, 47, 149, 28, 97, 17, 208, 173,
40, 253, 177, 188, 173, 223, 166, 36, 123, 114, 130, 35, 168, 26, 51, 5, 70,
108, 161, 1 }
Session ID: {}
Cipher Suites: { 0, 5 }
Compression Methods: { 0 }
***
[write] MD5 and SHA1 hashes: len = 45
: 01 00 00 29 03 01 3C B2 22 39 49 2F 95 1C 61 11 ...)...9I/..a.
0010: D0 AD 28 FD B1 BC AD DF A6 24 7B 72 82 23 A8 1A ..(..$.r.#..
0020: 33 05 46 6C A1 01 00 00 02 00 05 01 00 3.Fl.
main, WRITE: SSL v3.1 Handshake, length = 45
[write] MD5 and SHA1 hashes: len = 44
: 01 03 01 00 03 00 00 00 20 00 00 05 3C B2 22 39 9
0010: 49 2F 95 1C 61 11 D0 AD 28 FD B1 BC AD DF A6 24 I/..a...(..$
0020: 7B 72 82 23 A8 1A 33 05 46 6C A1 01 .r.#..3.Fl..
Hmm. This is a TLSv1 client hello? Hmm:
lutzpc 27: openssl s_client -debug -tls1 -connect serv01:443
CONNECTED(0003)
write to 08149C18 [081539D0] (88 bytes = 88 (0x58))
- 16 03 01 00 53 01 00 00-4f 03 01 3c b3 33 22 c2 S...O...3.
0010 - 41 74 94 64 c2 a3 54 4c-41 36 d6 38 df 06 3a a0 At.d..TLA6.8..:.
0020 - 7e 2c fd 09 24 86 92 5e-d5 d2 94 00 00 28 00 16 ~,..$..^.(..
0030 - 00 13 00 0a 00 66 00 05-00 04 00 65 00 64 00 63 .f.e.d.c
0040 - 00 62 00 61 00 60 00 15-00 12 00 09 00 14 00 11 .b.a.`..
0050 - 00 08 00 06 00 03 01 ...
Would you consider using ssldump in helping you to analyze the handshake??
main, WRITE: SSL v2, contentType = 22, translated length = 16343
^^^
Hmm. This does not really indicate it is TLSv1, doesn't it???
and here is what I get on the server (OpenSSL) when I Ctrl-C the client:
26747:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:290:
That would fit the underlined statement above.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: openssl-0.9.6c through openssl-0.9.5 fail if $PERL is defined not as the binary perl
On Mon, Apr 08, 2002 at 07:13:34PM +, John Salinas wrote: First let me thank you for your wonderful product openssl. It works great and I am very thankful it is out there. I have found a small conflict in more recent version of the config or Configure script for version 0.9.c back through 0.9.5 that if $PERL is defined as anything but the binary location for perl the configure script will fail with a message: permission defined to /var/local/bin (or I guess whatever the path that $PERL is defined as). Personally I have $PERL defined as the source of perl and the place where I put new modules. I would think that your script should at least check if $PERL is defined to see if the path it is pointing to is a binary or not it will try to use it as a binary executable even if it points to a directory! Not a good idea. Perhaps if $PERL is defined you could either prompt to see if it is the correct value, test to see if it is the correct value or unset and set it again before your configure scripts exit. It is a very small problem but I expect it could confuse some newer user users. Even though it might have surprised you, using the PERL environment variable in the way OpenSSL does it is a comletely normal technique. There exist ideas to move to autoconf one fine day and integrating a suitable check for perl might be part of the move, but I think we should leave things as they are right now. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL/Java JSSE Handshake problem...
On Tue, Apr 09, 2002 at 08:52:29PM +0200, David Maurus wrote: This might have the same cause as the problem I encountered. Brad Whetmore from Sun helped me find this. According to TLS (which can be found e.g. here: http://www.ietf.org/rfc/rfc2246.txt ), in the final message exchanges from the TLS handshake, a client key exchange message is sent by the client. The client key exchange message contains a RSA encrypted premaster secret message, which in turn contains a field with the The latest (newest) version supported by the client.. In case of TLS, this would be 3.1. But due to the fact that some older servers did not behave correctly, some SSL client libraries send the protocol version number as agreed upon in the handshake (this is wrong according to TLS spec, but compatible to the old servers). This means they start with a 3.1 ClientHello, and after agreeing on protocol version 3.0 (SSLv3) they send a premaster secret with 3.0 as the version number. A correctly implemented TLS server will expect a 3.1 here. [this would explain the SSL3_GET_RECORD:wrong version number error you observed]. In my case, this wrong version number led to a bad_record_mac error as mentioned. Late versions of OpenSSL provide the SSL_OP_TLS_ROLLBACK_BUG that allows the server to ignore this protocol violation. It is however not enabled by default. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: wrong defines SN_xyz
On Tue, Apr 02, 2002 at 10:07:27PM +0200, Lutz Jaenicke wrote: On Tue, Apr 02, 2002 at 09:25:00AM +0200, Michael Bell wrote: after I found the wrong definitions of SN_surname and SN_serialNumber I looked around and find the next problems in crypto/objects/ : SN_titletitle (now T) SN_description description (now D) SN_givenNamegn(now G) SN_initials initials (now I) LN_uniqueIdentifier x500UniqueIdentifier (now uniqueIdentifier) SN_rfc822Mailboxmail (now rfc822Mailbox) SN_pkcs9_emailAddress emailAddress (now Email) * SN_rfc822Mailbox is not wrong but a short name exists * I don't find a short name for SN_pkcs9_emailAddress. The related RFC only defines a long name Hmm... I have implemented the changes you recommend, but now I get a warning about a shortname mail to be defined twice. Maybe this was the reason why it was left out... I have attached the patch (including the problem). What do you recommend? Only objects.txt contains all necessary information; run the PERL scripts as used in Makefile.ssl to rebuild the other files. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Undefined identifiers in objects.txt
On Thu, Apr 04, 2002 at 12:23:26PM +0200, Svenning Sorensen wrote:
Since I wanted to use our private enterprises OIDs, I used the form:
enterprises 1527 1: myobj : My Object
(same form as the dcObject already in there)
However, enterprises is undefined, so my object ended up at the root
(i.e. 1527.1 instead of 1.3.6.1.4.1.1527.1) without a warning.
I hacked a bit in objects.pl to catch this gotcha:
--- openssl-SNAP-20020402/crypto/objects/objects.pl Mon Dec 3 15:01:26 2001
+++ openssl-SNAP-20020402-sss/crypto/objects/objects.pl Thu Apr 4 11:12:46
2002
@@ -210,6 +210,8 @@
if (!($a[0] =~ /^[0-9]+$/))
{
$a[0] =~ s/-/_/g;
+ if (!defined($obj{$a[0]}))
+ { die $ARGV[0]:$o:Undefined identifier ,$a[0],\n; }
$pref_oid = OBJ_ . $a[0];
$pref_sep = ,;
shift @a;
=
As it turns out, both private and enterprises are undefined, so objects.txt needs
to be fixed to make it compile at all. This patch seemed least intrusive:
-- openssl-SNAP-20020402/crypto/objects/objects.txt Tue Mar 26 19:01:01 2002
+++ openssl-SNAP-20020402-sss/crypto/objects/objects.txt Thu Apr 4 10:15:27
2002
@@ -699,10 +699,10 @@
internet 6 : snmpv2: SNMPv2
internet 7 : mail : Mail
-private 1: enterprises : Enterprises
+Private 1: enterprises : Enterprises
# RFC 2247
-enterprises 1466 344 : dcobject : dcObject
+Enterprises 1466 344 : dcobject : dcObject
This makes sense to me. I have applied the patch, so it should be fixed in
the next snapshot.
I'm also a bit suspicious about the OIDs of secp192r1 and secp256r1.
In obj_dat.h they both end up having OID 0. Their corresponding OBJ_ macros
in obj_mac.h get mapped to OBJ_X9_62_prime{192,256}v1 (of which I suppose
they are aliases), though, so it may be OK.
I'm not into all the gory details of this magic - it just looked a bit odd to me...
I am not sure about these ones. Bodo Moeller overviewed these changes, based
on changes submitted by Nils Larsch.
I have copied them through on this email to receive their comments.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL/Java JSSE Handshake problem...
On Tue, Apr 02, 2002 at 02:34:00PM -0600, Kevin Regan wrote: I've run into the handshake problem with OpenSSL and Java JSSE. If I change the method used to create the SSL context from TLSv1_server_method to SSLv23_server_method, the problem is fixed. However, I'd like to know what the problem actually is and if this incompatibility will ever be fixed? Also, who is doing the correct thing here, JSSE or OpenSSL? I have not worked with JSSE, so I will give you a more general comment: strictly spoken, only TLSv1 has the official blessing of having become an RFC. All standards describing ... over TLS protocols officially would therefore only apply to TLSv1. In practice nearly everything is implemented to also support SSLv2 and SSLv3, in fact e.g. Netscape 4.x does only support these protocols and does not support TLSv1. The same holds for a lot of servers, therefore most clients send a SSLv2 client hello (in violation of the TLSv1 standard, but with a much better compatibility :-) Consequently: only supporting TLSv1 would adhere to the standard, but with respect to interoperability, also supporting at least older hello messages is recommended. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/objects obj_dat.h obj_mac.hobjects.txt
On Thu, Mar 28, 2002 at 11:33:02AM +0100, Michael Bell wrote: Richard Levitte - VMS Whacker schrieb: Lutz.Jaenicke jaenicke jaenicke26-Mar-2002 18:15:37 Lutz.Jaenicke jaenicke Lutz.Jaenicke jaenicke Modified:.Tag: OpenSSL_0_9_7-stable CHANGES Lutz.Jaenicke jaenickecrypto/objects Tag: OpenSSL_0_9_7-stable obj_dat.h obj_mac.h Lutz.Jaenicke jaenicke objects.txt Lutz.Jaenicke jaenicke Log: Lutz.Jaenicke jaenicke Make short names of objects RFC2256-compliant. Well, the thing that you fixed is something I define as a bug, and your fix would therefore be a bugfix, which I think should be applied to the 0.9.6 branch as well. This is really dangerous because it breaks index.txt of openssl ca. If somebody use 0.9.6 to build LDIF-files for LDAP-servers then all nodes with a certificate in the LDAP will be duplicated. If you try to revoke a certificate ia openssl ca vwith the new 0.9.6 then this fails because the DNs are not equal. If you add this patch to 0.9.6 then there must be a really good warning in the documentation or in the release notes. Hmm. I am not running an LDAP server and did not care about these details until now. Following your statement we must add an according note to the 0.9.7 release notes (the entry in the changelogs looks rather harmless until now :-). We should also leave 0.9.6d with the old behaviour, as the impact of the bug (yes, I also consider this to be a bug) is small compared to the impact of the incompatibility. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/objects obj_dat.h obj_mac.h objects.txt
On Wed, Mar 27, 2002 at 01:24:25PM +0100, Richard Levitte - VMS Whacker wrote: From: [EMAIL PROTECTED] jaenicke jaenicke26-Mar-2002 18:15:37 jaenicke jaenicke Modified:.Tag: OpenSSL_0_9_7-stable CHANGES jaenickecrypto/objects Tag: OpenSSL_0_9_7-stable obj_dat.h obj_mac.h jaenicke objects.txt jaenicke Log: jaenicke Make short names of objects RFC2256-compliant. If you haven't already done it, I'd suggest you apply that change to the 0.9.6 branch as well. I left this out intentionally as it _might_ break compatibility. Additionally: the people concerned about this problem seem to be the OpenCA developers and users and they are using openssl-0.9.7-dev snapshots because of required extensions anyway. Of course, I could easily apply the same change to 0.9.6-stable, if this is considered useful. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: serialNumber with openssl ca
On Fri, Mar 15, 2002 at 03:19:33PM +0100, Michael Bell wrote: I used openssl ca -subj If I used serialNumber in the DN then OpenSSL reports the following: The Subject's Distinguished Name is as follows serialNumber :PRINTABLE:'02' commonName:PRINTABLE:'ra.hu-berlin.de' organizationalUnitName:PRINTABLE:'Trustcenter' organizationName :PRINTABLE:'Humboldt-Universitaet zu Berlin' countryName :PRINTABLE:'DE' Certificate is to be certified until Mar 7 14:38:38 2003 GMT (365 days) Now you can see the output of openssl x509 -text: Subject: SN=02, CN=ra.hu-berlin.de, OU=Trustcenter, O=Humboldt-Universitaet zu Berlin, C=DE There are three files which are using definitions which are not conform to the standards: crypto/objects/objects.h crypto/objects/obj_dat.h crypto/objects/obj_mac.h The use SN_surname and SN_serialNumber (SN == Short Name?). SN_serialNumber SN SN_surname S I have just checked in an according patch. Please note that objects.h is no longer used (well, the file is still available, but the actual information is #ifdef'ed out and obj_mac.h is included). Please test out the next snapshot. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug in X509_check_private_key
On Tue, Mar 26, 2002 at 02:53:22PM +0100, Maas-Maarten Zeeman wrote:
I discovered a small bug in X509_check_private_key.
EVP_PKEY *X509_get_pubkey(X509 *x)
{
if ((x == NULL) || (x-cert_info == NULL))
return(NULL);
return(X509_PUBKEY_get(x-cert_info-key));
}
int X509_check_private_key(X509 *x, EVP_PKEY *k)
{
EVP_PKEY *xk=NULL;
int ok=0;
-- xk=X509_get_pubkey(x); --- the problem
if (xk-type != k-type)
{
If this function is called with x set to NULL, it it will crash, because
xk is not checked for NULLs.
Handling of NULL pointers is not consistent within OpenSSL.
Finally it comes down to a different point: calling X509_check_private_key()
with x=NULL is not allowed. It is as buggy as calling any function with
an invalid argument: it may crash.
Please don't take this as an offense. I simply want to say that we are aware
that we cannot handle all thinkable cases of incorrect usage of the API.
We can (and probably will) fix the issue you just pointed out, but I am
sure that you will find much more of these cases, if you start searching :-)
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: buglet with string representation of DNs?
On Mon, Mar 18, 2002 at 10:53:05AM -0500, Harald Koch wrote: objects.txt defines the following: X509 4 : S : surname X509 5 : SN: serialNumber (X509 4 is 2.5.4.4). RFC2256 defines surname (2.5.4.4) as 'sn', and 2.5.4.5 as serialNumber, creating a conflict when going from a certificate subject DN to an LDAP DN. I can't find a justification for the shortforms currently in objects.txt anywhere in the PKIX documents. That's not to say there isn't a justification, because I don't have a current X.500 series that defines these attributes. :-) My recommendation would be to change the surname shortform to 'sn' to match LDAP, and to remove or change the serialnumber shortform. Comments? I did quite some research on the Web and did find that in all contexts with respect to LDAP your complaint is correct. I also found a small number of locations, e.g. http://support.entegrity.com/private/doclib/docs/osfhtm/admin/admingd/Adming66.htm at which the OpenSSL style is used. (Please not that I don't have a clue within which context entegrity.com is to be seen, the location was just found by Google :-). In some places I found even more strange results which seem to result from typos, as the term CN was used... For me it seems, that the recommended change makes sense. I am however not sure whether this will break existing applications. Steve Henson is most familiar with the X.509 part of OpenSSL and should give his statement. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
