Hi, I have attached the sample server and client programs for your consideration. As these are minimal sample codes that reproduce my problem, error handling is not done. To run the server, you need to provide the port on the command line To run the client, you need to provide host and port where server is listening for ssl connections on the command line.
> > >For me this seems that server do not want to accept this
> > >proposition because:
> > > - do not have RSA support (maybe)
> > > - do not have SHA support (maybe)
> > > - do not have DES support (maybe) or DES40 is too
> > weak.
As you would see in the server code, there are no explicit restrictions
except for the fact that both server and client set the ssl method as SSLv3
and ssl cipher list as "EXP-DES-CBC-SHA". So I am not sure if the support
for RSA / SHA / DES is disabled.
> > Well ... as per my understanding, the cipher support is
> > property of the crypto library. And my client and server both
> > use the same crypto library. So I wonder why would the server
> > reject the clients request.
> Yes, but you have control what ciphers should be used.
If you are suggesting the use of SSL_set_cipher_list(), I have already used
it. If you are talking about some other approach, could you please elaborate
more?
>
> But after some testing I think that incompatible SSL3/TLS1
> method may cause problem (as suggested by girish1729).
>
> For example, running server with command:
> $ openssl s_server -key key.pem -cert cert.pem -tls1
I am not sure if what you are trying here represents the same scenario that
I am talking about. Here you are explicitly using tls1 method for server and
hence the connection attempt will surely fail. But this is not the case with
my application. I am setting ssl method as SSLv3 in both server and client
and still the server refuses the connection :-(
> And on server side we see:
> 8064:error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version
> number:s3_srvr.c:685:
> My suggestion is to display errors after bad SSL_accept()
> in server code, for example:
> char buf[256];
> u_long err;
>
> while ((err = ERR_get_error()) != 0) {
> ERR_error_string_n(err, buf, sizeof(buf));
> fprintf(stderr, "%s", buf);
> }
I did try this and all I get is
"error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher"
Googling for this error message did not return any helful information.
> other methods may be callback function at state or msg layer.
I will have to try this. Any pointer in this direction will be helpful
Kyle,
in your response you mentioned something about export ciphers. Could you
take a look at the code and comment on "whether server really requires
non-export cipher suits"? Because my understanding is that the server
doesn't having any such restriction :-(
I am reiterating here that all the 4 binaries, sample_server, sample_client,
s_server and s_client are using the same ssl library. I confirmed that with
ldd. So the question still remains ...
Why sample_server reject connection request from s_client, whereas s_server
works just fine?
Thanks a lot for your responses,
~ 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.
sample_client.c
Description: Binary data
sample_server.c
Description: Binary data
