[openssl.org #766] minor bug in apps/apps.c
Hello folks,
there seems to be a minor bug
in the pasword getter:
Bye
Goetz
Index: apps/apps.c
===
RCS file: /usr/cvsroot/openssl/apps/apps.c,v
retrieving revision 1.73
diff -u -r1.73 apps.c
--- apps/apps.c 2003/10/29 14:25:50 1.13
+++ apps/apps.c 2003/11/14 14:54:45
@@ -501,7 +501,7 @@
{
const char *password =
((PW_CB_DATA *)UI_get0_user_data(ui))-password;
- if (password[0] != '\0')
+ if (password password[0] != '\0')
{
UI_set_result(ui, uis, password);
return 1;
@@ -525,7 +525,7 @@
{
const char *password =
((PW_CB_DATA *)UI_get0_user_data(ui))-password;
- if (password[0] != '\0')
+ if (password password[0] != '\0')
return 1;
}
default:
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #747] -pre and -post cmd line params for openssl cmds
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #747] -pre and -post cmd line params for openssl cmds
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #492] SSL: server root certs and client auth.
Hello Steve, Stephen Henson via RT wrote: I've committed a fix to address this issue which will appear in the next dev and stable snapshot (i.e. so it will appear in 0.9.7a). Let me know of any problems ASAP. I finally got around to do some quick tests. Seems to be OK. Could SSL_MODE_NO_AUTO_CHAIN be the default, with an additional flag SSL_MODE_AUTO_CHAIN ? Now I have to ask Ralf Engelschall to set the flag in mod_ssl... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #492] SSL: server root certs and client auth.
Hello Steve, Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Mon Feb 10 16:53:48 2003]: Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Fri Feb 7 14:09:28 2003]: It really needs replacing with something less horrible. For example it might: 1. Build the chain using the normal certificate verify code including the usual checks on validity and using appropriate purpose and trust. 2. Give a (fatal?) error if the verification fails. 3. Include a flag to exclude the root CA from outputted chain 4. Include an flag to disable the automatic chain building altogether and rely on the chain being correctly present in the extra certs of the context. I don't see a need for points 3 and 4. Points 1 to 3 are largely doing what it does now but properly. However it would require some changes to OpenSSL and some new APIs for example for new selectable purposes and trust settings for the chain build and (possibly) a new cert store. OK. I should clarify myself: It is to do it correctly, but not needed to fix the actual problem. However option 4 easy to do and could be argued as being a bug fix. OK. Perhaps something like: build the chain only with the certs supplied with SSL_CTX_add_extra_chain_cert() If the CA certs for the server cert are in a seperate list, the content of the cert chain is in control of the user. And if he doesn't want the root cert in the chain, he only has to exclude them in the config file. The actual bug is only because OpenSSL tried to be to smart and included in the list certificates it never was told to include... All I want to have is something like: build the list of server CA certs from the given file (or build by SSL_CTX_add_extra_chain_cert()) (in the order I give) and _don't_ include any other certificates... That's exactly what point 4 would do. You do something like: SSL_CTX_set_mode(ctx, SSL_MODE_NO_AUTO_CHAIN); at some stage and it would then just use the supplied certificate(s) in SSL_CTX_add_extra_chain_cert(). That are two different things: 1. build the chain with the certs from SSL_CTX_add_extra_chain_cert() 2. verify the chain is correct (trust settings OK, certs not expired,...) 5. Cache the path after it has been determined. Or build it one time and reuse it... Which leads to the interesting problem of when to build the chain. If its done on first use this will result in configuration errors only being apparent after a client connects. I think it should be done in SSL_CTX_add_extra_chain_cert(). But the return value contains to few information: only OK or failed. But the chain has 3 states: * error in cert chain * chain certs vaild but incomplete * chain certs valid and complete How integrate that in the actual interface ? since at least mod_ssl test for != 0, a quick solution would be: * error in cert chain = 0 * chain certs vaild but incomplete = 1 * chain certs valid and complete = 2 On the other hand the way that the various certificates and stores are presented in arbitrary order, not to mention a new SSL_MODE_NO_AUTO_CHAIN flag makes it trickier to determine when its OK to build the chain. As I suggested: Build it in SSL_CTX_add_extra_chain_cert() and return a different code for a complete chain... Of course the cached chain might also become invalid at some point in the future, such as when a certificate expires... Opens an other question: There are two validity models for cert chains: 1. A CA cert needs only to be be valid the moment the end entity cert is issued 2. A CA cert must be valid the complete life time of the end entity cert. In both cases you only have to check for expired CA certificates when you add a certificate to the chain... Becomes more complicated if you add OCSP... So you check the complete chain in SSL_CTX_add_extra_chain_cert() and check the host certificate when it is needed... But if you want to use the chain until any certificate in it expires, you can add a time stamp to it (this chain expires at ...) Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #492] SSL: server root certs and client auth.
Hello Steve, Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Mon Feb 10 20:02:40 2003]: OK. I should clarify myself: It is to do it correctly, but not needed to fix the actual problem. However option 4 easy to do and could be argued as being a bug fix. OK. Perhaps something like: build the chain only with the certs supplied with SSL_CTX_add_extra_chain_cert() Perhaps I should clarify myself too :-) The current situation is not good. If the primitive auto chain building comes up with the wrong answer then there isn't any easy method I can think of that will allow it to fix things. ACK Giving no certificate store at all and doing all its own verification might work but it's a hack. As a result IMHO we need a way to do *something* in OpenSSL 0.9.7X. If it is decided that a 0.9.7X fix is needed then this should be a minimal bug fix solution that keeps the changes in functionality down to a minimum but gives the application some method of correcting things when the chain build breaks. ACK For that maybe a new flag or possibly auto disable of the chain build if any extra certs are added. After all if the application is supplying extra certs it presumably is expecting the auto chain build to fail anyway? I can't see any legitimate reason for supplying extra certs *and* having auto chain build. That confused me too. The extra certs would be sent verbatim which is what 0.9.7 currently does anyway. Doing things properly will need new functionality and new functions and possibly break existing applications. As such that should be a 0.9.8 target. ACK For example what purpose and trust settings do you use in the chain building? The defaults will be SSL server for servers and SSL client for clients but some applications might need something different which the current primitive chain build will handle but the correct version wont. I don't think that we should do there to much checks. We should check: * the validity period (begin end) of all certs * the trust settings for all certificates * the purpose for the CA certs I don't think we really should check the purpose of the own certificate. (At least not break if it doesn't matches.) A mismatching purpose should result in a warning but not in an error. But since OpenSSL has no warnings... If the purpose of the certificate doesn't match, the peer should decide if a connection is established. In special cases it is usefull to use a client cert for a server and a server key for a client. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #105] Problem build 0.9.7 SNAP with ./Configure debug
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #97] About 0.9.6a(b) and des_encrypt1()
Richard Levitte - VMS Whacker wrote: From: Jani Taskinen [EMAIL PROTECTED] sniper From CHANGES: sniper sniper *) Rename 'des_encrypt' to 'des_encrypt1'. This avoids the clashes sniper with des_encrypt() defined on some operating systems, like Solaris sniper and UnixWare. sniper [Richard Levitte] sniper sniper sniper Just wanted to let you guys know, that also sniper this symbol is in use by Solaris (7), libcrypt: sniper sniper # nm /usr/lib/libcrypt.a | grep des_encrypt sniper U _des_encrypt sniper des_encrypt.o: sniper T _des_encrypt1 sniper W des_encrypt1 sniper 025c T _des_encrypt sniper U _des_encrypt1 sniper 025c W des_encrypt sniper 01bc t des_encrypt_nolock Hmm, it feels like it's really time for a rename (basically, change des to DES in all names, and thereby follow the convention used everywhere else in OpenSSL), or this becomes an impossible task. openssl_des_... ? in the sources we can have a #define des_...() openssl_des_...() By Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #98] OpenSSL engine ctrl: handling of strings
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #89] missing prototypes for functions
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #63] something like a bug in pkcs12: p12_kiss.c
Götz Babin-Ebell via RT wrote:
Oups.
It seems I didn't mention the OpenSSL version:
0.9.6c / 0.9.7 (snap from 28.05.2002)
Sorry...
Hello folks,
there seems to be a bug in pkcs12/p12_kiss.c:
PKCS12_parse():
if you enter the function with an allocated
ca stack and the parse fails,
the ca stack will be deallocated and the pointer not cleared.
[...]
[...]
int PKCS12_parse (PKCS12 *p12, const char *pass, EVP_PKEY **pkey, X509
**cert,
STACK_OF(X509) **ca)
{
int freeca=0;
/* Check for NULL PKCS12 structure */
if(!p12) {
PKCS12err(PKCS12_F_PKCS12_PARSE,PKCS12_R_INVALID_NULL_PKCS12_POINTER);
return 0;
}
/* Allocate stack for ca certificates if needed */
if ((ca != NULL) (*ca == NULL)) {
if (!(*ca = sk_X509_new_null())) {
PKCS12err(PKCS12_F_PKCS12_PARSE,ERR_R_MALLOC_FAILURE);
return 0;
}
freeca=1;
}
[...]
err:
if (pkey *pkey) EVP_PKEY_free(*pkey);
if (cert *cert) X509_free(*cert);
if (ca freeca) sk_X509_pop_free(*ca, X509_free);
return 0;
[...]
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
