[openssl.org #810] EXP1024 bug uncovered in 0.9.6k
In versions engine-0.9.6l and engine-0.9.6k it is no longer possible to
connect using the EXP1024-DES-CBC-SHA cipher suite:
V:\external\openssl\openssl-engine-0.9.6k\win32\out32.dbg-do_masm>openssl
versio
n
OpenSSL 0.9.6k [engine] 30 Sep 2003
V:\external\openssl\openssl-engine-0.9.6k\win32\out32.dbg-do_masm>openssl
s_clie
nt -connect localhost:4433 -cipher EXP1024-DES-CBC-SHA
Loading 'screen' into random state - done
CONNECTED(0134)
depth=0
/C=IL/ST=Israel/L=Herzeliya/O=Gilian/OU=RND/CN=Gilian/[EMAIL PROTECTED]
n.com
verify error:num=18:self signed certificate
verify return:1
depth=0
/C=IL/ST=Israel/L=Herzeliya/O=Gilian/OU=RND/CN=Gilian/[EMAIL PROTECTED]
n.com
verify error:num=10:certificate has expired
notAfter=Nov 11 12:40:09 2003 GMT
verify return:1
depth=0
/C=IL/ST=Israel/L=Herzeliya/O=Gilian/OU=RND/CN=Gilian/[EMAIL PROTECTED]
n.com
notAfter=Nov 11 12:40:09 2003 GMT
verify return:1
2656:error:140820A7:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:missing
export tm
p rsa key:.\ssl\s3_clnt.c:1791:
It IS possible to connect using engine-0.9.6g, the latest that I tested.
I think I traced the problem to ssl3_check_cert_and_algorithm() in
s3_clnt.c:
if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) &&
!has_bits(i,EVP_PKT_EXP))
{
#ifndef NO_RSA
if (algs & SSL_kRSA)
{
if (rsa == NULL
|| RSA_size(rsa) >
SSL_C_EXPORT_PKEYLENGTH(s->s3->tmp.new_cipher))
{
SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,SSL_R_MISSING_EXPORT_TMP_RSA_KEY)
;
goto f_err;
}
}
An EXP1024 algorithm will still be considered an export algorithm
(SSL_C_IS_EXPORT), but the public key supplied in the server's certificate
message will not be considered an export key (EVP_PKT_EXP) because it has
more than 512 bits. Since no server key exchange messaqe was sent (rsa ==
NULL), an error will result. In other words, the code does not take in to
account the possibility of an EXP1024 cipher suite that is capable of
handling a 1024-bit RSA key despite being an export cipher suite.
I think the reason why it worked up to 0.9.6j is Richard Levitte's fix
(CHANGES):
*) Change X509_certificate_type() to mark the key as exported/exportable
when it's 512 *bits* long, not 512 bytes.
[Richard Levitte]
Previously ALL public RSA keys were considered export keys, so the test
succeeded even with EXP1024 and even non-1024 EXP ciphersuites with a
misconforming server that does not send out a ServerKeyExchange message even
when it should. Richard's fix uncovered the ssl3_check_cert_and_algorithm()
bug.
I suggest that the fix to THIS bug could involve testing for
SSL_C_IS_EXPORT56 instead of, or in addition to, testing for
SSL_C_IS_EXPORT, but I am not sufficiently well-versed in this area of the
code to be certain.
Thanks in advance,
Adi Stav
Infrastructure Team
Gilian Technologies <http://www.gilian.com/>
tel: 972-9-9560036 x.260
fax: 972-9-9565668
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Gilian's G-Server awarded SC Magazine Best Buy award.
The Verdict: "A most complete and effective way of protecting your corporate
web presence"
Click here to read all about it
<http://www.scmagazine.com/scmagazine/2003_08/test_01/index.html> or contact
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> for more information
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
EXP1024 bug uncovered in 0.9.6k
In versions engine-0.9.6l and engine-0.9.6k it is no longer possible to
connect using the EXP1024-DES-CBC-SHA cipher suite:
V:\external\openssl\openssl-engine-0.9.6k\win32\out32.dbg-do_masm>openssl
versio
n
OpenSSL 0.9.6k [engine] 30 Sep 2003
V:\external\openssl\openssl-engine-0.9.6k\win32\out32.dbg-do_masm>openssl
s_clie
nt -connect localhost:4433 -cipher EXP1024-DES-CBC-SHA
Loading 'screen' into random state - done
CONNECTED(0134)
depth=0
/C=IL/ST=Israel/L=Herzeliya/O=Gilian/OU=RND/CN=Gilian/[EMAIL PROTECTED]
n.com
verify error:num=18:self signed certificate
verify return:1
depth=0
/C=IL/ST=Israel/L=Herzeliya/O=Gilian/OU=RND/CN=Gilian/[EMAIL PROTECTED]
n.com
verify error:num=10:certificate has expired
notAfter=Nov 11 12:40:09 2003 GMT
verify return:1
depth=0
/C=IL/ST=Israel/L=Herzeliya/O=Gilian/OU=RND/CN=Gilian/[EMAIL PROTECTED]
n.com
notAfter=Nov 11 12:40:09 2003 GMT
verify return:1
2656:error:140820A7:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:missing
export tm
p rsa key:.\ssl\s3_clnt.c:1791:
It IS possible to connect using engine-0.9.6g, the latest that I tested.
I think I traced the problem to ssl3_check_cert_and_algorithm() in
s3_clnt.c:
if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) &&
!has_bits(i,EVP_PKT_EXP))
{
#ifndef NO_RSA
if (algs & SSL_kRSA)
{
if (rsa == NULL
|| RSA_size(rsa) >
SSL_C_EXPORT_PKEYLENGTH(s->s3->tmp.new_cipher))
{
SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,SSL_R_MISSING_EXPORT_TMP_RSA_KEY)
;
goto f_err;
}
}
An EXP1024 algorithm will still be considered an export algorithm
(SSL_C_IS_EXPORT), but the public key supplied in the server's certificate
message will not be considered an export key (EVP_PKT_EXP) because it has
more than 512 bits. Since no server key exchange messaqe was sent (rsa ==
NULL), an error will result. In other words, the code does not take in to
account the possibility of an EXP1024 cipher suite that is capable of
handling a 1024-bit RSA key despite being an export cipher suite.
I think the reason why it worked up to 0.9.6j is Richard Levitte's fix
(CHANGES):
*) Change X509_certificate_type() to mark the key as exported/exportable
when it's 512 *bits* long, not 512 bytes.
[Richard Levitte]
Previously ALL public RSA keys were considered export keys, so the test
succeeded even with EXP1024 and even non-1024 EXP ciphersuites with a
misconforming server that does not send out a ServerKeyExchange message even
when it should. Richard's fix uncovered the ssl3_check_cert_and_algorithm()
bug.
I suggest that the fix to THIS bug could involve testing for
SSL_C_IS_EXPORT56 instead of, or in addition to, testing for
SSL_C_IS_EXPORT, but I am not sufficiently well-versed in this area of the
code to be certain.
Thanks in advance,
Adi Stav
Infrastructure Team
Gilian Technologies <http://www.gilian.com/>
tel: 972-9-9560036 x.260
fax: 972-9-9565668
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Gilian's G-Server awarded SC Magazine Best Buy award.
The Verdict: "A most complete and effective way of protecting your corporate
web presence"
Click here to read all about it
<http://www.scmagazine.com/scmagazine/2003_08/test_01/index.html> or contact
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> for more information
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
SSL sniffer
Hello, I'm looking for advice on SSL-related problems in my application. I'm developing an OpenSSL-based SSL sniffer that monitors decrypted SSL traffic using the webserver's private keys on real site traffic (similar to ssldump). For some reasons, part of the SSL traffic is not being decrypted. I'm looking for possible reasons for this. The ones I am currently aware of are: - Frames out of order. - Packet losses in the network. - Missing keys. - Using Diffie - Hellman - Temporary keys for export grade browsers. - Resumed sessions that started after the sniffer started. Are there any other possible reasons for this phenomenon? Thanks in advance, Adi Stav __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #49] More malloc check fixes
A patch for more malloc return value checking fixes is attached. Incidentally this also includes the fix for buf #55 by Zoltan Glozik. Thanks, -- Adi Stav - developer Topaz Prism R&D Mercury Interactive +972-3-5399481 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #49] Patch on top malloc fix
Hello, The last malloc fix I sent introduced its own rather silly bug. Please apply the attached patch on top -- sorry. Thanks, -- Adi Stav - developer Topaz Prism R&D Mercury Interactive +972-3-5399481 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #49] more fixes
Hello, A slightly more involved audit uncovered a few more places of unchecked return values from BN functions. The attached diff contains both the old and the new fixes. I only looked in the code that our application is actually using (especially RSA_private_decrypt and downwards), so you might want to run your own additional audit to be certain. Thanks, -- Adi Stav - developer Topaz Prism R&D Mercury Interactive +972-3-5399481 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #49] Unchecked return values
Hello, There are numerous places in OpenSSL, especially in the BN library, where return values of calls to malloc() or calls to functions that can fail due to malloc() are not checked. This can cause at least crashes that I observed when running an application using OpenSSL in low-memory situations (e.g., using ulimit -v). There is also at least one case (rsa_eay.c) where a return value is indeed checked but the error handling is incorrect regarding the destruction of objects on the stack that haven't yet been initialized, again resulting in a crash. Attached is a diff to fix _some_ instances of these two issues. Thanks, -- Adi Stav - developer Topaz Prism R&D Mercury Interactive +972-3-5399481 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[no subject]
There is an input sanity check in asn1_lib.c that is #if'd out for some reason. In its absence, a corrupt certificate read by d2i_X509() can at least crash the process. Additionally, the sanity checks both there and in a_bytes.c do not take into account a possibility of negative length and of pointer wrap-around, with similar results. Code to demonstrate the bug (just run it for a few hours) and a diff are attached. Was the #if'ing out of the test intentional, and am I risking anything by enabling it? Right now I am patching openssl-engine-0.9.6c privately, but of course I'd be much happier to know I'd be able to just use plain vanilla 0.9.6d. Thanks for the excellent library, and thanks in advance for your reply, -- Adi Stav - developer Topaz Prism R&D Mercury Interactive +972-3-5399481 [EMAIL PROTECTED] test_d2i_X509.c Description: Binary data openssl.diff Description: Binary data
