Urjit,
I got it working once I replaced
"EXP-DES-CBC-SHA" with
"DES-CBC-SHA"
I think you might have to do something special to
enable export quality ciphers.
regards,
Girish
--- Urjit Gokhale <[EMAIL PROTECTED]>
wrote:
> 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.
>
__________________________________________________
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]
