Re: MS CAPI OpenSSL Engine?
Bryce Why not make the MS CAPI engine available for download. We are interested and I suspect quite a few others would have an interest also. I suspect a lot of people are interested but don't want to admit they use Microsoft. You know, only the big boys use OpenSSL on UNIX. However, the truth is, over 80% of all OpenSSL usage is on Microsoft Windows! Ken In summary the MS CAPI engine provides: - Support for RSA signing and verification operations that will work w/ non-exportable MS CAPI private keys, should work with any CAPI-compliant HW token (testing it w/ Rainbow iKey's this week) - Full access to any MS CAPI keystore, implemented a certificate lookup library that implements the X509_LOOKUP_METHOD interface (thus when verifying the certificate chain the MS CAPI Root and CA keystores can be used) - Engine interface to MS CAPI random number generator - SSL interface to allow visual selection of client certificate during negotiation phase (IE/Mozilla style, using an SSL (undocumented?) hook) --- Frédéric_Giudicelli [EMAIL PROTECTED] wrote: I already did this announce, but nobody seemed to care at the time :) I developed some BIO support for the MS SSPI, allowing to initiate from openssl some SSL connection using a MS PCERT_CONTEXT, I would gladely provide it to the OpenSSL project. Does your engine provide access to the certificate, or just the RSA bi-key ? Frédéric Giudicelli http://www.newpki.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-398-0221 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #430] segementation fault with openssl 0.9.7
I just ran it on Windows XP, with OpenSSL-0.9.7 and do not get a crash. Ken [[EMAIL PROTECTED] - Wed Jan 1 15:40:21 2003]: Hi, I have trouble running the following command with openssl version 0.9.7 openssl ca -policy policy_anything -out newcert.pem \ -passin pass:whatever -key whatever -extensions xpserver_ext \ -extfile xpextensions -infiles newreq.pem It works fine with the 0.9.7-beta3 release but all later releases seem to segfault. The segfault occures in the CONF_modules_unload when sk_num is called the results returned differ. In beta3 the result returned is 0x2 whilst in the 0.9.7 release the eax register contains the following value 0x4212dfd8. If this is a known problem, sorry for taking up your time. I also get a crash at that place when I do a very simple command like: openssl ca -infiles it gives the file not found error then crashes. However that return value from sk_num suggests something has been corrupted. Running under a debugging malloc library causes a crash earlier on with a double free error on something which is only freed once. Very odd... What platform is this on? Does anyone else get a crash with: openssl ca -infiles __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-398-0221 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL-0.9.7
The OpenSSL-0.9.7 release is the best release I have ever seen! Works great on Windows XP and Redhat 6.0. First time I have ever compiled on both Windows and Linux and got NO compile errors and everything worked without having to make a patch. I also tested the Kerberos 5 authentication with both the Stanford SRP telnet server (release 2.0.0-beta3 and 1.7.5) and a modified proftp server using the TLS/SSL patch from Peter Runestig. The Kerberos 5 support within proftp was added locally (minor change based upon Peter's Kerberos 5 support in the SRP telnet server). Ken __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-398-0221 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Certificate Request Error
I am getting an error with OpenSSL 0.9.7 when trying to generate a certificate. It appears that the uniqueIdentifier is no longer valid. Is this correct? The following is the error: Certificate request failed Certification Request Failed /usr/local/ssl/bin/openssl ca -config /usr/local/ssl/openssl.cnf -in /tmp/cert8.req -out /tmp/cert8.result -policy policy_anything rc = 256 FriendlyName = req = Using configuration from /usr/local/ssl/openssl.cnf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'US' stateOrProvinceName :PRINTABLE:'Texas' localityName :PRINTABLE:'Katy' organizationName :PRINTABLE:'InterSoft International Incorporated' organizationalUnitName:PRINTABLE:'Systems Development' emailAddress :IA5STRING:'[EMAIL PROTECTED]' commonName :PRINTABLE:'xp.netterm.com' uniqueIdentifier:unknown object type in 'policy' configuration unable to write 'random state' __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-398-0221 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #421] bug: 097snap don't include krb5 inc dir in pkgconfig
Did you do a config with:
--with-krb5-flavor=MIT
[openssl-097-snap 2002-12-28 build on RedHat8 with MIT's krb5 libs]
When I try to build packages that include ssl.h, it fail on:
---START
In file included from /usr/include/openssl/ssl.h:179,
from configure:6400:
/usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory
---END
openssl.pc is:
---START
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: OpenSSL
Description: Secure Sockets Layer and cryptography libraries and tools
Version: 0.9.7-beta7-dev
Requires:
Libs: -L${libdir} -lssl -lcrypto -L/usr/kerberos/lib -lgssapi_krb5
-lkrb5 -lcom_err -lk5crypto -lresolv -ldl
Cflags: -I${includedir}
---END
includedir don't has /usr/kerberos/include
Ricardo.-
--
Ricardo Ariel Gorosito [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
Support
InterSoft International, Inc.
Voice: 888-823-1541, International 281-398-7060
Fax: 888-823-1542, International 281-398-0221
[EMAIL PROTECTED]
http://www.securenetterm.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: IMPORTANT: please test snapshot openssl-0.9.7-SNAP-20021213
A lot of developers have waited a very long time for 0.9.7, over two years, and now
that its in final beta tests, a discussion is active about making major changes to it.
Does not make sense.
Ken
On Thu, 26 Dec 2002, Richard Levitte - VMS Whacker wrote:
levitte In message [EMAIL PROTECTED] on Thu, 26 Dec 2002 23:31:38
+0100, Andy Polyakov [EMAIL PROTECTED] said:
levitte
levitte appro Yet I'd dare:-) If it was up to me and if Tim is with us [i.e. is
ready
levitte appro to swiftly verify a snapshot on explicit request], I'd pull it
[unified
levitte appro *586-elf.o rules] even now:-) I have Linux and Solaris/Intel,
levitte appro login.openssl.org is a FreeBSD machine... So shall we?
levitte
levitte I suggest not. Can you say that you cover for all possible variants
levitte of Linux? All variants of FreeBSD? What about OpenBSD? What about
levitte NetBSD?
I'm ready to test.
But Richard is right, we're talking about a major change.
[snip]
levitte appro As far as I can tell the only target that shouldn't work in
levitte appro 0.9.7-beta6 is sco5-gcc and only if you don't have GNU
levitte appro assembler around. The rest of targets should work. They lack
levitte appro assembler support, but they're operational. What is being
levitte appro discussed here is *proposed* patch adding support for assembler
levitte appro modules to the targets in question.
levitte
levitte OK, now I have a better picture. For some reason, I didn't see the
levitte beginning of this thread. If sco5-gcc currently doesn't use any
levitte assembler and works with such a configuration, I'd also leave it be
levitte until 0.9.7a.
Here is where we stand.
Without adding my patch to support ASM on UnixWare and OpenServer
The UnixWare cc targets are OK
sco3-gcc OK
sco5-cc and sco5-cc-pentiun OK
sco5-gcc FAILS (removing ${x86_elf_asm} should fix this)
I don't think anyone tries to put gnu ld on
SCO OpenServer 5.
I'd really like to see the ... sed 's/^#.*//' ... in
openssl-0.9.7/crypto/bf/Makefile.ssl
openssl-0.9.7/crypto/bn/Makefile.ssl
openssl-0.9.7/crypto/cast/Makefile.ssl
openssl-0.9.7/crypto/des/Makefile.ssl
openssl-0.9.7/crypto/md5/Makefile.ssl
openssl-0.9.7/crypto/rc4/Makefile.ssl
openssl-0.9.7/crypto/rc5/Makefile.ssl
openssl-0.9.7/crypto/ripemd/Makefile.ssl
openssl-0.9.7/crypto/sha/Makefile.ssl
replaced with ... perl -pi -e 's/ ?([\.,@]) +/\1/g; s/ +:/:/g; s/#.*//;' ...
in 0.9.7
Then we could add ${x86_sol_asm} to the UnixWare/OpenUNIX targets
giving them asm support.
We can leave the major rework to 0.9.7a
--
Tim Rice Multitalents(707) 887-1469
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
Support
InterSoft International, Inc.
Voice: 888-823-1541, International 281-398-7060
Fax: 888-823-1542, International 281-398-0221
[EMAIL PROTECTED]
http://www.securenetterm.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: IMPORTANT: please test snapshot openssl-0.9.7-SNAP-20021213
Whats wrong with Windows? Ken In message 3E0B49CA.4377.9884857@localhost on Thu, 26 Dec 2002 18:26:18 -0600, Kenneth R. Robinette [EMAIL PROTECTED] said: support A lot of developers have waited a very long time for 0.9.7, over two years, and now support that its in final beta tests, a discussion is active about making major changes to it. support Does not make sense. I entirely agree with you. However, it seems like that's discussions for the future, mostly. However, considering we still have unfixed errors on some supported platforms (Windows), it looks like the release won't happen within the specified time range. I don't expect it to be delayed with more than a week... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-398-0221 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and compression using ZLIB
From: pobox [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject:Re: OpenSSL and compression using ZLIB Date sent: Fri, 29 Nov 2002 15:22:18 -0600 Send reply to: [EMAIL PROTECTED] I was not sure either, and perhaps I did not take the time to completely understand what Geoff was really saying. If so, I apologize. However I do agree with the statements below. The other thing that concerns me a little is the use of a zlib dll in the Microsoft Windows environment. OpenSSL 0.9.7 makes use a zlib dll, although it could be optional. The specs are not really clear in this area, and I have always had to mess around with the final makefile to get compression and the Kerberos option to even work. I have been burned several times with the use of zlib dll's, since quite a few Windows based programs distribute zlib dll's and not all are compatible, but all appear to have the same exports. However, this is not an issue if in there is an option to use static zlib functions linkage. Getting the OpenSSL zlib support to operate like the statements below, with the ability the specify a compression level would allow us, and other Windows based developers of SSH clients, get rid of some redundent logic. Most developers of these clients already use the OpenSSL EVP cipher support. I suspect most UNIX SSH developers do also. We also use zlib compression within our SSL/TLS based telnet client which communicates mainly with the SRP project telnet server. Ken On November 27, 2002 03:24 pm, Kenneth R. Robinette wrote: Um, well that's one approach. But its a little like saying Lets let SSL/TLS take care of agreeing on a cipher type, and then leave it up to the user application to take care of the actual encryption/decrytion. I would rather see the most commonly used methods inplemented within SSL/TLS itself. If the SSL/TLS implementation is doing the (de)compression I don't see what your point is. Ie. with this compression method negotiated by the client and server, the SSL/TLS would still be responsible for handling compression - it would just handle it on the application data before applying the SSL/TLS framing rather than compressing data inside it. From the application point of view, there's no need to implement anything. Did you misunderstand me or vice versa? Geoff, I can't speak for Kenneth, but I'm not sure I get what you're saying here. The data is first compressed and then encrypted according to RFC2246. In my mind, once the application hands the data to OpenSSL via SSL_write() or BIO_write() or _puts() or whatever it is no longer application data, even if compression has been negotiated. I think it is best to firstly get the decompressor correct. My belief is that a single decompressor can transparently handle the following three possible compression scenarios: 1) Each record is compressed independently. The dictionary is reset before each record. This appears to be the way OpenSSL currently works (flush is Z_FULL_FLUSH). Compression ratio is worst of the three. 2) The dictionary is not reset between records. However, the current compression buffer can be flushed (Z_SYNC_FLUSH), so that uncompressed data does not span an SSL record boundary. Compression ratio is better than #1. 3) The compression buffer is not flushed between records. Uncompressed data may span SSL record boundaries. Best compression ratio. #1 is the 'safest' in that it seems to make compression as transparently to client applications as is possible. #2 is almost as safe. For the most part, #2 will be just as safe as #1. In fact, I can't really think of any reasonable scenarios in which this is not true, but strange things are possible with acceleraters, proxies, shims and whatnot. At least #2 is absolutely necessary, e.g. for client protocols like EAP-TLS. A decompressor that has this functionality would be backward compatible with the current OpenSSL scheme and forward compatible with almost any reasonable implementation of ZLIB over TLS. ___ ___ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ___ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-398-0221 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and compression using ZLIB
Date sent: Wed, 27 Nov 2002 14:58:24 -0500 From: Geoff Thorpe [EMAIL PROTECTED] Subject:Re: OpenSSL and compression using ZLIB To: [EMAIL PROTECTED] Copies to: Le Saux, Eric [EMAIL PROTECTED], royop@tb- solutions.com Send reply to: [EMAIL PROTECTED] Um, well that's one approach. But its a little like saying Lets let SSL/TLS take care of agreeing on a cipher type, and then leave it up to the user application to take care of the actual encryption/decrytion. I would rather see the most commonly used methods inplemented within SSL/TLS itself. Ken On November 27, 2002 12:33 pm, Le Saux, Eric wrote: Yes, very interesting. This is another way of adding compression to the data pipe. I have not looked at the code, but I assume that the compression state is maintained for the whole life of the communication channel, which is what gives the best results. Um, out of curiosity ... wouldn't this be the easiest way to implement a custom compression method anyhow? Ie. define the compression method so that the SSL/TLS handshake can take care of agreeing (or not) about compression at each end, but do not implement the method inside SSL/TLS processing - ie. if that compression method is agreed, cause a zlib BIO to be inserted (or removed, in the case of a renegotiation perhaps) onto the application side of the SSL object's BIO chain (um, actually chains, one each for read and write I suppose) ... this essentially does what Pablo was referring to but lets the SSL/TLS handshake take care of negotiating compression with the peer. The latter is the problem with just putting the compression layer inside the SSL/TLS layer, you need an out-of-band (read: application) mechanism to decide when to use it or not. It sounds a bit magic(k) though ... hmm ... perhaps buffering/flushes would be the problem when applications use non-blocking sockets? If not, this sounds easier than putting the zlib manipulation inside the SSL/TLS layer and would probably give faster and better compression too. oh yes: Pablo J Royo wrote; I think the BIO would mantain the context (as z_stream struct of ZLIB do) among several calls to BIO_write/read, so if you want to compress communication data you have to chain this zBIO with a socket BIO. almost - presumably the socket BIO you refer to is on the SSL/TLS data side rather than the application data side, in which case your compression won't do much. Compression is only useful on the assumption that the application data itself is compressible, and by the time you get SSL/TLS data - it's (hopefully) too well encrypted for compression to have much effect. :-) I assume you ment to chain it with a memory/buffer BIO? Ie. going from; -- write_BIO -- -- \ [app] [SSL] socket_BIO -- read_BIO -- -- / to; -- write_BIO -- zlib_BIO -- --\ [app][SSL] socket_BIO -- read_BIO -- zlib_BIO -- --/ ? Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ___ ___ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ___ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-398-0221 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ZLIB Compression method
Once you make the SSL_COMP_add_compression_method() call to turn on zlib compression, how do you turn it off? It appears that if you have OpenSSL static linked, once you turn it on, the only way to get rid of it is to exit the application. From what I can tell, none of the normal cleanup operations removes it and I cannot find any funtion that turns it off. Ken __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-560-9170 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #277] COMP_zlib Problem
Subject:Re: [openssl.org #277] COMP_zlib Problem From: Lutz Jaenicke via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Copies to: [EMAIL PROTECTED] Date sent: Tue, 10 Sep 2002 10:15:19 +0200 (METDST) Send reply to: [EMAIL PROTECTED] Lutz There is still a problem in kssl.c which prevents the OpenSSL- 0.9.7beta3 server code from working when Kerberos 5 authentcation is requested. I sent the code necessary to fix this many months ago (I worked with Dr. Henson on the problem). The code I sent must have been lost, thown away or discarded. It consisted of a short patch to kssl.c in the ssl directory. What is the correct procedure to follow to get this fixed? I really don't care if my patch is used or someone elses; I just would like to see this stuff work as distributed. Ken On Mon, Sep 09, 2002 at 10:43:51AM -0500, Kenneth R. Robinette wrote: If one calls COMP_METHOD *comp = COMP_zlib(), the first time this call is made, a valid COMP_METHOD is returned, and the comp-type is set correctly. However, if you make the call a second time, a valid COMP_METHOD is returned, however the comp-type is set to 0. That does not make sense to me. COMP_zlib in any case of success returns a pointer to the zlib_method structure, which is a static entry in crypto/comp/c_zlib.c. There the type member is set to NID_zlib_compression. Thus the only reason why type is 0 would be that zlib_method would be overwritten (destroyed). However: If COMP_zlib() fails, a pointer to the zlib_method_nozlib structure is returned. This is also a valid pointer (not a NULL pointer), but it does not provide any compression at all. Its type is NID_undef, which in turn is 0. From the code, it seems, that this would be the result with ZLIB_SHARED and COMP_zlib() being called more than once. zlib_loaded is true (succussfully loaded the first time) and then meth is not set to zlib_method again... I am not sure about the intended behaviour, but it probably is not intended this way (read this: it seems to be a bug to me :-). I have therefore bounced this issued into the request tracker. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] Cottbus.DE 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 openssl- [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] _ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-560-9170 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
COMP_zlib Problem
If one calls COMP_METHOD *comp = COMP_zlib(), the first time this call is made, a valid COMP_METHOD is returned, and the comp-type is set correctly. However, if you make the call a second time, a valid COMP_METHOD is returned, however the comp-type is set to 0. This is with OpenSSL 0.9.7-beta3, on Windows XP. The call is from a windows .com object. OpenSSL 0.9.7 is static linked to the .com object, but the same thing happens if linked with the OpenSSL 0.9.7 dll's. This was observed when the Windows FTPS application starts, connects to a FTPS server supporting compression. On the first connect, everything works fine. However if you disconnect, then connect to the same host again (without exiting the Windows client), the windows client calls COMP_zlib to get the method, then checks the comp-type to make sure its valid. It fails on this check, since it is zero. If however, you remove the check for the type, and just check the pointer returned form COMP_zlib(), everything works. Note that after the first connect, and prior to the second connect, SSL was closed down properly, for both the command and data channel ssl connections. If you exit the windows client after a connect, and start it again, then connect, it works ok. Appears to be some type of reenterable problem. Futher, the entry point OpenSSLDie is missing in the libeay32.def file, resulting in undefines when compiling ssleay32.lib. In program ssl/s3_srvr.c, line 1591, there is a typo problem on: if(enc.pms_length sizeof pms) which should be: if(enc_pms.length sizeof(pms) Ken __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-560-9170 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util mkerr.pl
Date sent: Wed, 14 Aug 2002 13:51:43 +0100 From: Ben Laurie [EMAIL PROTECTED] To: Arne Ansper [EMAIL PROTECTED] Copies to: [EMAIL PROTECTED], Bodo Moeller [EMAIL PROTECTED] Subject:Re: cvs commit: openssl/util mkerr.pl Send reply to: [EMAIL PROTECTED] This is really amazing. A security library that can get corrupted and the developers don't have a clue on how to fix it properly. If a library cannot detect a problem and report that problem to the calling application, for proper handling, then perhaps that library should be put into quarantine until a valid rational plan to fix the library has been formulated. Ken Arne Ansper wrote: Example: when working through the internal session cache we learn, that the linked list is corrupted, we have dangling pointers and don't know what is going on. This would touch all threads using the same SSL_CTX. Thus: we don't know how to repair it - abort(). to make it more extreme: why stop here? perhaps the right solution is to reboot the machine? what if some standalone application thinks that the best solution for _its own_ problems is to reboot the machine? (happens all the time under the windows btw, you install some crap and the installer happily reboots your system). for me it's not different if some library thinks that the best solution for _its own_ problems is to kill the application. the application must have a control. if the internal error (it would be correct to call them bugs, btw) happens, application must get this information and then it's up to the application to deal with it. if it's simple commandline tool it can call abort by itself. if its complex application it might unload the openssl and reload it later. or save its state and restart. only application knows what the right thing to do is. The point is that the application is now in an inconsistent state and cannot reliably know anything. Even returning from a function could cause an exploit. The only safe thing to do is abort (now I think about it, probably die() shouldn't even print an error message). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl- [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] _ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-560-9170 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #86] Bug in RSA_check_key
transparent operations, perhaps RSA_is_valid()? Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl- [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Kenneth R. Robinette President InterSoft International, Inc. Voice:888-823-1541 or 281-398-7060 Fax:888-823-1542 or 281-560-9170 http://www.securenetterm.com _ __ 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
From: James Yonan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Copies to: [EMAIL PROTECTED] Subject:OpenVPN and OpenSSL 0.9.7 was: Re: Integration of AES algorith to OpenSSL Crypto library Date sent: Fri, 3 May 2002 09:09:01 -0600 Send reply to: [EMAIL PROTECTED] I know this may sound simplistic, but since you are the author of OpenVPN, why don't you make a simple check for the OpenSSL version and use 0.9.7 the way it was designed to be used. If the check indicates you are using 0.9.6, use the method you currently use. One of the developers commented recently that OpenSSL has a *LOT* of overhead, both in size and complexity, just to try to keep everyone happy. Ken 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. James Yonan OpenVPN developer http://openvpn.sourceforge.net/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl- [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] _ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-560-9170 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Missing define in err.h
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? Ken __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-560-9170 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL_CTX_set_cipher_list
I am trying to fix an old Open Source application using BIO_do_handshake, and convert that app to use OpenSSL 0.9.7. During testing, I discovered that the application would work when using the OpenSSL Window dll's, but not when static linked. 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? Ken __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-560-9170 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL 0.9.7 SNAP
From: Kenneth R. Robinette [EMAIL PROTECTED]
Organization: InterSoft International, Inc.
To: [EMAIL PROTECTED]
Date sent: Mon, 25 Mar 2002 14:32:17 -0600
Subject:OpenSSL 0.9.7 SNAP
Send reply to: [EMAIL PROTECTED]
In a followup to my posting yesterday, I have tested the following
code to replace lines 2050-2079 within kssl.c
This was tested with a Redhat 6.0 system, using SRP-1.7.5 and a
Windows based SSL client.
if (!EVP_CipherInit(ciph_ctx,enc,kssl_ctx-key,iv,0))
{
kssl_err_set(kssl_err, SSL_R_KRB5_S_INIT,
EVP_DecryptInit_ex error decrypting
authenticator.\n);
krb5rc = KRB5KRB_AP_ERR_BAD_INTEGRITY;
goto err;
}
outl = dec_authent-cipher-length;
if (!EVP_Cipher(ciph_ctx,unenc_authent,dec_authent-cipher-
data,outl))
{
kssl_err_set(kssl_err, SSL_R_KRB5_S_INIT,
EVP_Cipher error decrypting
authenticator.\n);
krb5rc = KRB5KRB_AP_ERR_BAD_INTEGRITY;
goto err;
}
Ken
In the 0.9.7 SNAPS, kssl.c, located in the ssl directory has a
problem on the EVP_DecryptFinal_ex fuction.
The kerberos ticket that is being decryped in lines 2050-2078 was
encrypted by Kerberos itself, not by OpenSSL. It would appear that
the Kerberos padding logic is NOT the same as the current OpenSSL EVP
padding logic.
In my test case, the kerberos ticket to be decrypted has a length of
112 bytes, which is a multiple of the DES blocksize. There is no
padding on the encrypted data. OpenSSL expects padding, in this case
8 bytes, which of course is not present. The call to
EVP_DecryptUpdate returns an outl value of 104, then the call to
EVP_DecryptFinal_Ex fails because of the lack of padding. If you
dump the contents of the buffer decrypted by the EVP_DecryptUpdate
call, the data is correct. In fact you can comment out the
EVP_DecryptFinal_ex call, adjust outl to 112 bytes, and everything
else works as it should However commenting out the
EVP_DecryptFinal_ex call will prevent the proper cleanup of the
structures involved.
Perhaps it would be better to use Kerbers 5 to decrypt the ticket, or
lower level OpenSSL calls.
I attempted to use the optional set padding call, but without
success.
Ken
__
Support
InterSoft International, Inc.
Voice: 888-823-1541, International 281-398-7060
Fax: 888-823-1542, International 281-560-9170
[EMAIL PROTECTED]
http://www.securenetterm.com
__
OpenSSL Project
http://www.openssl.org
Development Mailing List openssl-
[EMAIL PROTECTED]
Automated List Manager
[EMAIL PROTECTED]
_
Support
InterSoft International, Inc.
Voice: 888-823-1541, International 281-398-7060
Fax: 888-823-1542, International 281-560-9170
[EMAIL PROTECTED]
http://www.securenetterm.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
OpenSSL 0.9.7 Recent SNAPS
In the latest 0.9.7 SNAPS, when using the default DES behavior, the function user function des_random_seed is getting defined to DES_random_seed, which is coming up as undefined in the link step. Ken __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-560-9170 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL 0.9.7 SNAP
In the 0.9.7 SNAPS, kssl.c, located in the ssl directory has a problem on the EVP_DecryptFinal_ex fuction. The kerberos ticket that is being decryped in lines 2050-2078 was encrypted by Kerberos itself, not by OpenSSL. It would appear that the Kerberos padding logic is NOT the same as the current OpenSSL EVP padding logic. In my test case, the kerberos ticket to be decrypted has a length of 112 bytes, which is a multiple of the DES blocksize. There is no padding on the encrypted data. OpenSSL expects padding, in this case 8 bytes, which of course is not present. The call to EVP_DecryptUpdate returns an outl value of 104, then the call to EVP_DecryptFinal_Ex fails because of the lack of padding. If you dump the contents of the buffer decrypted by the EVP_DecryptUpdate call, the data is correct. In fact you can comment out the EVP_DecryptFinal_ex call, adjust outl to 112 bytes, and everything else works as it should However commenting out the EVP_DecryptFinal_ex call will prevent the proper cleanup of the structures involved. Perhaps it would be better to use Kerbers 5 to decrypt the ticket, or lower level OpenSSL calls. I attempted to use the optional set padding call, but without success. Ken __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-560-9170 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/ssl kssl.c
Date sent: Tue, 19 Mar 2002 14:39:00 -0500
From: Vern Staats [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject:Re: cvs commit: openssl/ssl kssl.c
Send reply to: [EMAIL PROTECTED]
I just wish the logic worked, then I would not have to worry about
turning on the debug stuff!
Ken
On Tue, Mar 19, 2002 at 06:37:35PM +, Dr S N Henson wrote:
Jeffrey Altman wrote:
To make it very clear, the locations that I'm seeing warnings are:
ssl\kssl.c:
In print_krb5_data() kdata-length is unsigned
In print_krb5_keyblock() keyblk-length is unsigned
[...etc]
As I mentioned I got kerberos 1.2.4 sources from:
http://non-us.debian.org/debian-non-US/pool/non-US/main/k/krb5
kdata is of type krb5_data and in my version the kerberos header file
krb5.h contains:
typedef struct _krb5_data {
krb5_magic magic;
int length;
char FAR *data;
} krb5_data;
This is in kerbsrc.zip generated from Unix. I've checked the linux
headers and the same thing is in there. Maybe there are different
versions of the source with different types for this field?
I think .length has always been int, at least for MIT KRB5 1.0.6
through 1.2.3. I haven't done anything on the PC side, except
for cygwin, which would have been the same as Unix.
I'll just cast it to (int) in the above cases, that should shut the
compiler up.
Seems reasonable to me.
--
My company prefers to have that kind of decision
made by
uninformed executives. We call it Empowerment. --
Dilbert
[EMAIL PROTECTED]
Vern Staats, ASC/HPTS, WPAFB OH 45433, 937-255-1616
__
OpenSSL Project
http://www.openssl.org
Development Mailing List openssl-
[EMAIL PROTECTED]
Automated List Manager
[EMAIL PROTECTED]
_
Support
InterSoft International, Inc.
Voice: 888-823-1541, International 281-398-7060
Fax: 888-823-1542, International 281-560-9170
[EMAIL PROTECTED]
http://www.securenetterm.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/ssl kssl.c
Date sent: Fri, 15 Mar 2002 9:35:06 EST From: Jeffrey Altman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Copies to: [EMAIL PROTECTED] Subject:Re: cvs commit: openssl/ssl kssl.c Send reply to: [EMAIL PROTECTED] This is somewhat confusing. I just compiled the current snapshot of OpenSSL on Linux using a unmodified MIT 1.2.4 distribution straight from the MIT site and got no errors at all. I also compiled againt the unmodified MIT PC kfw-2.1.2 distrubution straight form the MIT site and got no erros at all. In email received from Tom Wu, the developer of a UNIX based advanced telnet/tls server supporting the TLS based Kerberos 5 authentication, received last night, he indicated that he also was able to get a clean compile using the MIT 1.2.4 distribution and the latest OpenSSL snapshot. Can there be two completely different MIT 1.2.4 UNIX/PC distributions? Ken Steve: Which flavor of Kerberos 5 are you using? Which release? I have a feeling the reasons that you are I are seeing different warnings is because the types of the fields in different flavors or versions are different. I'm compiling against MIT 1.2.4 which is the current release. Some of your changes are producing warnings which are of course treated as fatal when compiling OpenSSL. - Jeff steve 13-Mar-2002 14:58:36 Modified:ssl Tag: OpenSSL_0_9_7-stable kssl.c Log: Undo previous patch: avoid warnings by #undef'ing duplicate definitions. Suggested by Kenneth R. Robinette [EMAIL PROTECTED] Revision ChangesPath No revision No revision 1.20.2.4 +9 -6 openssl/ssl/kssl.c Index: kssl.c === RCS file: /e/openssl/cvs/openssl/ssl/kssl.c,v retrieving revision 1.20.2.3 retrieving revision 1.20.2.4 diff -u -r1.20.2.3 -r1.20.2.4 --- kssl.c 2002/03/12 19:38:14 1.20.2.3 +++ kssl.c 2002/03/13 13:58:33 1.20.2.4 @@ -129,17 +129,20 @@ #define krb5_timeofday kssl_krb5_timeofday #define krb5_rc_default kssl_krb5_rc_default -#ifndef krb5_rc_initialize -#define krb5_rc_initialize kssl_krb5_rc_initialize +#ifdef krb5_rc_initialize +#undef krb5_rc_initialize #endif +#define krb5_rc_initialize kssl_krb5_rc_initialize -#ifndef krb5_rc_get_lifespan -#define krb5_rc_get_lifespan kssl_krb5_rc_get_lifespan +#ifdef krb5_rc_get_lifespan +#undef krb5_rc_get_lifespan #endif +#define krb5_rc_get_lifespan kssl_krb5_rc_get_lifespan -#ifndef krb5_rc_destroy -#define krb5_rc_destroy kssl_krb5_rc_destroy +#ifdef krb5_rc_destroy +#undef krb5_rc_destroy #endif +#define krb5_rc_destroy kssl_krb5_rc_destroy #define valid_cksumtype kssl_valid_cksumtype #define krb5_checksum_size kssl_krb5_checksum_size __ OpenSSL Project http://www.openssl.org CVS Repository Commit List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. Interfaces with OpenSSH __ OpenSSL Project http://www.openssl.org Development Mailing List openssl- [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] _ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-560-9170 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL 0.9.7 - HMAC_cleanup
The HMAC_cleanup() function is defined in the current SNAP but must not be implemented. Calling this function will compile correctly but will result in link errors. Ken __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-560-9170 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
