Hi Girish,
Thanks for replying.
I am specifying the ssl method as SSLv23_method()
while creating the SSL context. As I understand, the method set in the context
will apply to all the SSL instances I create with this context.
I tried using SSLv3_method() as well, but still
the application can not connect. I still dont understand why the header sent by
the server suggests that there are only 2 bytes to be read in the server
hello??
========
> SSL_connect:SSLv3 write client hello
A
> read from 0x80e6a10 [0x80ecf58] (5 bytes => 5 (0x5))
> 0000 - 15 03 00 00 02
> .....
> read from 0x80e6a10 [0x80ecf5d] (2 bytes => 2 (0x2))
> 0000 - 02 28
> .(
> <<< SSL 3.0 Alert [length 0002], fatal
> handshake_failure
> 02 28
========
> read from 0x80e6a10 [0x80ecf58] (5 bytes => 5 (0x5))
> 0000 - 15 03 00 00 02
> .....
> read from 0x80e6a10 [0x80ecf5d] (2 bytes => 2 (0x2))
> 0000 - 02 28
> .(
> <<< SSL 3.0 Alert [length 0002], fatal
> handshake_failure
> 02 28
========
Has someone faced this kind of problem earlier?
Could anyone throw some more light on this?
~ Urjit
----- Original Message -----
From: "Girish Venkatachalam" <[EMAIL PROTECTED]>
Sent: Wednesday, July 05, 2006 5:19
PM
Subject: Re: Connection problem with some ciphers
... ServerHello seems to be the problem
specified in SSL_set_ssl_method() ? Most
interoperability problems are caused due to this.
Since some cipher suites are not supported in some
protocols it might be a good guess. :-)
HTH,
Girish
--- Urjit Gokhale <[EMAIL PROTECTED]>
wrote:
> Hello everyone,
>
> I have a sample client-server application written in
> C, that communicates
> using SSL. I observed that for some cipher suites,
> the client and server
> fail to establish ssl connection. But for the same
> cipher, the s_client and
> s_server can establish ssl connection and exchange
> data. The certificates
> used by my application and by s_client and s_server
> are same. So I fail to
> understand what might be going wrong when my client
> and server try to
> connect.
>
> To check if my client or server is causing the
> problem, I ran my client with
> s_server and ran my server with s_client.
> my client can connect to s_server without any
> trouble.
> But s_client can not connect to my server.
>
> Here is information s_client dumps on my screen:
> =================
> (urjit) test_app>openssl s_client -cipher
> 'EXP-DES-CBC-SHA' -connect
> localhost:7777 -verify client_cert/cacert.pem -cert
> client_cert/cli-cert.pem -crlf -key
> client_cert/cli-key.pem -ssl3 -debug -msg -state
> verify depth is 0
> CONNECTED(00000003)
> SSL_connect:before/connect initialization
> write to 0x80e6a10 [0x80f1768] (50 bytes => 50
> (0x32))
> 0000 - 16 03 00 00 2d 01 00 00-29 03 00 44 ab 8b 5e
> db ....-...)..D..^.
> 0010 - df 4c 4d ff 08 f9 2b 85-9c 1e 1b 49 04 00 db
> 92 .LM...+....I....
> 0020 - 59 53 17 7c a7 45 98 ca-c6 33 48 00 00 02 00
> 08 YS.|.E...3H.....
> 0030 - 01
> .
> 0032 - <SPACES/NULS>
> >>> SSL 3.0 Handshake [length 002d], ClientHello
> 01 00 00 29 03 00 44 ab 8b 5e db df 4c 4d ff 08
> f9 2b 85 9c 1e 1b 49 04 00 db 92 59 53 17 7c a7
> 45 98 ca c6 33 48 00 00 02 00 08 01 00
> SSL_connect:SSLv3 write client hello A
> read from 0x80e6a10 [0x80ecf58] (5 bytes => 5 (0x5))
> 0000 - 15 03 00 00 02
> .....
> read from 0x80e6a10 [0x80ecf5d] (2 bytes => 2 (0x2))
> 0000 - 02 28
> .(
> <<< SSL 3.0 Alert [length 0002], fatal
> handshake_failure
> 02 28
> SSL3 alert read:fatal:handshake failure
> SSL_connect:failed in SSLv3 read server hello A
> 31545:error:14094410:SSL
> routines:SSL3_READ_BYTES:sslv3 alert handshake
> failure:s3_pkt.c:1057:SSL alert number 40
> 31545:error:1409E0E5:SSL
> routines:SSL3_WRITE_BYTES:ssl handshake
> failure:s3_pkt.c:534:
> ================
>
> By looking at earlier successful connection (with
> different cipher) and
> comparing the information, I see that the data sent
> by server as ServerHello
> is causing the trouble. The length of payload is
> reported as 2. I am not
> sure what is causing this.
> Could someone help.
>
> Thanks,
> ~ Urjit
>
>
> DISCLAIMER
> ==========
> This e-mail may contain privileged and confidential
> information which is the property of Persistent
> Systems Pvt. Ltd. It is intended only for the use of
> the individual or entity to which it is addressed.
> If you are not the intended recipient, you are not
> authorized to read, retain, copy, print, distribute
> or use this message. If you have received this
> communication in error, please notify the sender and
> delete all copies of this message. Persistent
> Systems Pvt. Ltd. does not accept any liability for
> virus infected mails.
>
______________________________________________________________________
> OpenSSL Project
> http://www.openssl.org
> User Support Mailing List
> openssl-users@openssl.org
> Automated List Manager
> [EMAIL PROTECTED]
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.
