This sounds EXACTLY like what I ran across - right down to the mask values
and missing bit (low bit of 2nd nibble is missing).
All I had to do was call SSL_CTX_set_tmp_dh () after creating the context
(SSL_CTX_new()). See "s_server.c" in the "apps" directory, and use the code
in the function "get_dh512()". Search for the single call to that function
in "s_server.c" for an example of its use and how to subsequently call
SSL_CTX_set_tmp_dh().
Do this and your code will probably spring to life; mine did.
For the background on this, the missing mask bit is 'kEDH'. This is set
only if 'dh_tmp' in the CERT structure is non-NULL when it is processed in
"ssl_set_cert_masks (in ssl_lib.c)". The only way this dh_tmp is set (that
I could find) is when a successful call is made to SSL_CTX_set_tmp_dh (),
which ultimately happens in s3_lib.c (search for the case
SSL_CTRL_SET_TMP_DH in that module to see the code).
Hope this helps, and once again:
MANY THANKS to Dr. Stephen Henson for sending me down the right path.
Bill Rebey
-----Original Message-----
From: James Bailey [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 19, 2000 8:30 AM
To: [EMAIL PROTECTED]
Subject: Re: HELP for $$$$
I too am in a similar situation. When trying to use ssl to connect from
a test client to a test server using RSA certificates everything runs
smoothly. However, when switching to DSA certificates the cipher
selection fails.
I too wish to disable all RSA support so that my end product isn't
hindered by licensing nonsense from companies, and as such I am using
the no-rc5, no-idea and no-rsa flags for the config script.
I have looked into the problem as much as I can, but have a severly
limited knowledge of how and why a cipher is choosen.
in s3_lib.c, function ssl3_choose_cipher, the alg is anded with an emask
( I presume this is some sort of functionality check ) before a cipher
is selected, when running with debug on the following output was
generated :
Have:
0x80b291c:EDH-DSS-DES-CBC3-SHA
0x80b2b24:DHE-DSS-RC4-SHA
0x80b2afc:EXP1024-DHE-DSS-RC4-SHA
0x80b2aac:EXP1024-DHE-DSS-DES-CBC-SHA
0x80b28f4:EDH-DSS-DES-CBC-SHA
0:[00000050:00000140]0x80b291c:EDH-DSS-DES-CBC3-SHA
0:[00000050:00000140]0x80b2b24:DHE-DSS-RC4-SHA
0:[00000050:00000140]0x80b2afc:EXP1024-DHE-DSS-RC4-SHA (export)
0:[00000050:00000140]0x80b2aac:EXP1024-DHE-DSS-DES-CBC-SHA (export)
0:[00000050:00000140]0x80b28f4:EDH-DSS-DES-CBC-SHA
0:[00000050:00000140]0x80b28cc:EXP-EDH-DSS-DES-CBC-SHA (export)
50 is the alg, and when anded with an emask of 140, does not equal 50.
As all these ciphers have the same alg, none of them pass, and so no
cipher is choosen.
Please can someone offer some more indepth knowledge as to what is going
on here. Should there be more ciphers to choose from?
I hope that this insight proves usefull, and wish to offer thanks in
advance for any help given,
Regards,
dgym bailey
______________________________________________________________________
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]
