> On Thu, Aug 12, 1999 at 12:00:00AM +0000, Jeffrey Altman wrote:
>
> > I am setting the cipher list on both my client and server
> >
> > ADH-DES-CBC3-SHA:ADH-DES-CBC-SHA
> >
> > and then attempt to make a TLSv1 connection and get the following
> > error:
> >
> > [TLS - handshake starting]
> > [TLS - FAILED]
> > 235:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
> > failure:.\ssl\s3_pkt.c:774:SSL alert number 40
> >
> > Is anyone successfully using these ciphers?
>
> You mention SSL_ALLOW_ADH in the subject line, and if the library is
> compiled with -DSSL_ALLOW_ADH, those ciphers indeed work (as you can
> easily test by running "openssl s_server -cipher ADH" [beware that
> s_server must be run in the apps directory so that it can find its
> certificate and key even though those are not needed for ADH ciphers]
> and "openssl s_client -cipher ADH". Note that both need the -cipher
> option as the current default cipher list does not include ADH).
Hmm. Then I wonder what I am doing wrong.
I can make a pure TLS connection but the connection fails when I
attempt to start it midstream. I guess I have some debugging to do.
>
> > The reason why I want them is that by using them I do not need to
> > worry about certificates. I want to use TLS for privacy but I am
> > willing to use Kerberos V5 for mutual end-user to host authentication.
> > I plan to avoid the man in the middle attack which is possible when
> > using the ADH ciphers by including the following ASN.1 structure
> > in the Kerberos V5 checksum field.
> >
> > TLS_CHECKSUM_DATA ::= SEQUENCE {
> > authentication-type-pair OCTET_STRING, -- 2 bytes
> > SSLversion INTEGER, -- SSL version number
> > Cipher OCTET_STRING, -- the 3 byte cipher ID
> > Session_ID OCTET_STRING, -- the Session ID
> > Master_key OCTET_STRING, -- the master key
> > }
>
> This is not secure. The master secret is derived from data
> transmitted in clear and the premaster secret, which is just the
> result of the DH exchange, which *can* be influenced by an attacker in
> a way such that the client and server agree on its value and the
> attacker knows it too.
Do you have another suggestion?
Is there anyway to do this which does not require the use of
signed certificates?
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
