Re: Engine version build problems under win32
From: Baber Amin [EMAIL PROTECTED] BAMIN I am trying to build the engine version (0.9.6c-engine) under win32 BAMIN using VC6.x. It seems to be going fine till the compile for hw_aep.c, BAMIN which includes unistd.h. That seems to cause problems under win32. Replace that inclusion line with the following and try it out: #include openssl/e_os.h #ifndef MSDOS #include unistd.h #else #include process.h typedef int pid_t; #endif BAMIN Is the engine build not supported under win32, or just not protected BAMIN properly? There weren't enough tests done, it appears, so this is a bug. It will be fice in 0.9.6d, which I hope we'll release quite soon. BAMIN Should any of the code under crypto/engine be compiled if the no_hw BAMIN is turned on. It seems that inclusion of header files is not protected BAMIN by that flag in hw-aep.c and possibly other files. Is that on purpose? Not quite. I'm restructuring that as we speak. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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]
Futher debug of race condition in 0.9.6b/c
sshd/ftpd/telnetd - pam_ldap - libldap - libssl/libcrypto To recap, when my dual processor Pentium III is idle, I *always* get a return value of 0 from SSL_connect. If I bog down the box, I get 1 and everything works (login sucessful). I added a check for SSL_get_error, and I get SSL_ERROR_SYSCALL. I check the error queue with ERR_get_error() My luck, I get 0 back from ERR_get_error(). The man page says, if ERR_get_error returns 0, an EOF was observed that violates the protocol. sigh I just want my LDAP authentication to work on these two machines out of about a dozen where it works fine. The machines that work are slower 500Mhz boxes, and the failure on a dual P3, and a single CPU AMD 1700+. pam_ldap is using libldap (further using OpenSSL) to do a starttls connection against a remote OpenLDAP server. I'm just banging my head against the keyboard here. Dax __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Futher debug of race condition in 0.9.6b/c
On Fri, 8 Feb 2002, Howard Chu wrote: Try using strace to log all system calls. Until you know which calls have failed, it's tough to isolate what's going on. when using strace on sshd, I couldn't get it to fail. Not using strace, it fails every time. Dax __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Futher debug of race condition in 0.9.6b/c
On Fri, Feb 08, 2002 at 01:53:11AM -0700, Dax Kelson wrote: sshd/ftpd/telnetd - pam_ldap - libldap - libssl/libcrypto To recap, when my dual processor Pentium III is idle, I *always* get a return value of 0 from SSL_connect. If I bog down the box, I get 1 and everything works (login sucessful). I added a check for SSL_get_error, and I get SSL_ERROR_SYSCALL. I check the error queue with ERR_get_error() My luck, I get 0 back from ERR_get_error(). The man page says, if ERR_get_error returns 0, an EOF was observed that violates the protocol. sigh I just want my LDAP authentication to work on these two machines out of about a dozen where it works fine. The machines that work are slower 500Mhz boxes, and the failure on a dual P3, and a single CPU AMD 1700+. pam_ldap is using libldap (further using OpenSSL) to do a starttls connection against a remote OpenLDAP server. I'm just banging my head against the keyboard here. Start by using ssldump (http://www.rtfm.com/ssldump). We really need to see what is going over the wire... (an EOF... would mean that it is the peer closing the connection... is this really true?). 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: SQL DB instead of index.txt
Dr S N Henson wrote: Ben Laurie wrote: Dr S N Henson wrote: The self signed cert was only an example. There are other cases which could apply as well. An example would be explicit trust of an EE certificate. That isn't supported in OpenSSL yet but it will be at some point. It would however have a similar criteria: only an exact match would be acceptable. I believe this is supported (by writing appropriate callbacks) - I'm sure I remember doing it at some point. Well yes you can do most things with callbacks. I was referring to a method where you could (for example) place an EE certificate in a trusted store, set a trust this certificate for some purpose setting on it and a certificate verify would automatically succeed even though the rest of the chain was absent. Right. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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 [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
make report
I'm a complete Linux newbie here, submitting this report for the common good. I'm trying to get sshd working on my RedHat 7.2 box and this openssl install was the last in a series of frustrations. Hope it helps someone somewhere. Thanks, Chaz Checking compiler... Running make... make[1]: Entering directory `/root/openssl-0.9.6c' + rm -f libcrypto.so.0 + rm -f libcrypto.so + rm -f libcrypto.so.0.9.6 + rm -f libssl.so.0 + rm -f libssl.so + rm -f libssl.so.0.9.6 making all in crypto... make[2]: Entering directory `/root/openssl-0.9.6c/crypto' making all in crypto/md2... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/md2' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/md2' making all in crypto/md4... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/md4' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/md4' making all in crypto/md5... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/md5' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/md5' making all in crypto/sha... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/sha' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/sha' making all in crypto/mdc2... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/mdc2' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/mdc2' making all in crypto/hmac... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/hmac' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/hmac' making all in crypto/ripemd... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/ripemd' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/ripemd' making all in crypto/des... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/des' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/des' making all in crypto/rc2... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/rc2' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/rc2' making all in crypto/rc4... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/rc4' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/rc4' making all in crypto/rc5... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/rc5' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/rc5' making all in crypto/idea... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/idea' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/idea' making all in crypto/bf... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/bf' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/bf' making all in crypto/cast... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/cast' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/cast' making all in crypto/bn... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/bn' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/bn' making all in crypto/rsa... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/rsa' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/rsa' making all in crypto/dsa... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/dsa' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/dsa' making all in crypto/dh... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/dh' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/dh' making all in crypto/dso... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/dso' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/dso' making all in crypto/buffer... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/buffer' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/buffer' making all in crypto/bio... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/bio' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/bio' making all in crypto/stack... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/stack' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/stack' making all in crypto/lhash... make[3]: Entering directory `/root/openssl-0.9.6c/crypto/lhash' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/lhash' making all in crypto/rand... make[3]:
Re: bug in openssl session cache
On Thu, Feb 07, 2002 at 03:38:32PM +0200, Izhar Shoshani Levi wrote:
I found a bug in ssl session cache, please check it.
SSL_CTX_session_remove trying to find the session in the cache and delete it
but when calling SSL_SESSION_list_remove, in case that r != NULL the wrong
session is
sent to the function, instead of sending r which is the one that is in the
cache c is been sent.
I had a look into the problem in the meantime. The problem seems to arrive
from the following construct:
* One can pass a copy of a session to SSL_CTX_remove_session() that
is not in the internal session cache. Normally the operation would
simply fail.
* The session could have been created by copying a session, so that a
SSL_SESSION with the same contents is available inside the session
cache.
* lh_delete() will only check the hash value of the contents and will
thus react by removing the session that is inside the session cache.
Consequently, the bug report above is correct.
However, I would consider making a different change: if the (pointer to
an SSL_SESSION object) passed to SSL_CTX_remove_session() is not
a part of the session cache, the removal is not performed.
Thus:
if(lck) CRYPTO_w_lock(CRYPTO_LOCK_SSL_CTX);
+ if ((r = (SSL_SESSION *)lh_retrieve(ctx-sessions,c)) == c)
r=(SSL_SESSION *)lh_delete(ctx-sessions,c);
if (r != NULL)
{
ret=1;
SSL_SESSION_list_remove(ctx,c);
}
Any other opinions on what is the correct solution?
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: make report
Charles McCabe wrote: I'm a complete Linux newbie here, submitting this report for the common good. I'm trying to get sshd working on my RedHat 7.2 box and this openssl install was the last in a series of frustrations. Hope it helps someone somewhere. [snip] gcc -I.. -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 -c -o p12_init.o p12_init.c p12_init.c: In function `PKCS12_init': p12_init.c:98: Internal error: Segmentation fault. Please submit a full bug report. See URL:http://bugzilla.redhat.com/bugzilla/ for instructions. make[3]: *** [p12_init.o] Error 1 make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/pkcs12' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/root/openssl-0.9.6c/crypto' make[1]: *** [sub_all] Error 1 make[1]: Leaving directory `/root/openssl-0.9.6c' That looks suspiciously like a C compiler bug. See if you can get an updated version. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
REMOVE
REMOVE --- http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: an attack against SSH2 protocol
Wei Dai [EMAIL PROTECTED]: [Posted to sci.crypt and the IETF SSH working group mailing list.] Phil Rogaway observed that CBC mode is not secure against chosen- plaintext attack if the IV is known or can be predicted by the attacker before he choses his plaintext [1]. Similarly, CBC mode is not secure if the attacker can observe the last ciphertext block before choosing the next block of plaintext, because the last block of ciphertext essentially serves as the IV for the rest of the message. The attack itself is very simple. Remember that in CBC mode, each plaintext block is XOR'ed with the last ciphertext block and then encrypted to produce the next ciphertext block. Suppose the attacker suspects that plaintext block P_i might be x, and wants to test whether that's the case, he would choose the next plaintext block P_j to be x XOR C_(i-1) XOR C_(j-1). If his guess is correct, then C_j = Encrypt(P_j XOR C_(j-1)) = Encrypt(P_i XOR C_(i-1)) = C_i, and so he can confirm his guess by looking at whether C_j = C_i. The SSH2 protocol, when used with a block cipher in CBC mode, does allow the attacker to observe the last ciphertext block of a packet, which is then used as the (implicit) IV of the next packet. [...] [1] http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt I have received some comments through private email. Apparently the exact same weakness was known for IPSec and may also exist in TLS (I haven't read enough of its RFC to be sure) [...] In TLS, the IV for subsequent records is the last ciphertext block from the previous record [RFC 2246], and plaintext blocks usually consist of raw application data followed by a MAC, so the attack applies. (Having the MAC at the *beginning* of each packet would avoid the attack.) In his CRYPTO 2001 paper The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?), Hugo Krawczyk supposedly shows that SSL/TLS with CBC encryption is secure -- but he assumes a random IV for each encrypted block, which is not how the actual SSL protocol works. Another problem with CBC as used in SSL/TLS was pointed out by Serge Vaudenay, see URL:http://www.openssl.org/~bodo/tls-cbc.txt. That one can easily be avoided by implementations. To avoid the new attack without changing the protocol definition, implementations would have to send an empty fragment before application data to ensure IV randomization. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: race condition in openssl 0.9.6b/c
Dax Kelson [EMAIL PROTECTED]: I'm having a problem where two RHL7.2 LDAP clients out of many don't authenticate against an OpenLDAP server. They are using starttls to connect to the server. The chain is sshd - pam_ldap - openldap - OpenSSL. In openldap-2.0.21/libraries/libldap/tls.c line ~625 err = SSL_connect( ssl ); If the failing client is slightly bogged down by ltracing the sshd process, then err == 1 (sucess), otherwise err == 0 (failure), [...] Details: pam_ldap.so calls ldap_start_tls_s. I tracked that down to: openldap-2.0.21/libraries/libldap/tls.c Eventually the ldap_int_tls_connect function is called. The important lines from this function are the OpenSSL functions: ssl = alloc_handle( ctx ); (creates ssl handle) err = SSL_connect( ssl ); SSL_connect() returning 0 indicates that a read attempt for the underlying channel returned 0, which usually stands for EOF. If libldap uses sockets for I/O, you should watch the actual socket operations to see what is going on. Take a look at the call to readsocket() in crypto/bio/bss_sock.s (readsocket() is actually read() on Unix platforms, see e_os.h). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
