(Superseding previous reply since this has more detail.)
> From: owner-openssl-us...@openssl.org
> Sent: Friday, 09 October, 2009 07:09
> 1) SO' informations
>
> Server
> ------
> CentOS release 5.2
> OpenSSL 0.9.8k 25 Mar 2009
> Apache 2.2
> JBoss-4.2.2
OK, this partly answers the question I was going to ask about
what application(s), but which is involved in the problem?
Below you imply Apache which does use OpenSSL (optionally),
but I'm pretty sure Jboss uses only JCE/JSSE.
> Client
> ------
> CentOS release 5.2
> OpenSSL 0.9.8b 04 May 2006 (Library: OpenSSL 0.9.8h 28 May 2008)
I don't understand this. Is 0.9.8h installed or not?
If you have one version (perhaps b) in the system locations
(/usr/bin etc.) and another version you've put in a private
location (something like $HOME/openssltest) and you want to
use the latter (for whatever reason), use *all parts* of it
-- libraries, includes, executable. If the system locations
are inconsistent, your installation or distro is broken.
> Both have certificate files.
If the server is Jboss, it doesn't use cert/pkey files as such.
(It has the same *information* but in a Java keystore.)
If the server is Apache, I do expect OpenSSL-ly files.
You (still) don't say what the (real) client is. Any SSL client
(including one using OpenSSL, or the OpenSSL utility s_client)
will actually need and use a pkey/cert only if the server
requests client-authentication, which for Jboss at least
is not the default, but for Apache mod_ssl apparently is.
That would make no difference to data cipher/MAC, though.
> 2) Problem and tests
> I have the system based in comunication between client and server,
> in this system is possible send commands from the server to the client,
> for example, send log files - And the files from the cliente are sending
> to the server.
This is not clear at all. Are you saying that some client (what?)
DOES communicate with a server (which?) using SSL (or TLS), or not?
> But, I have had some problems with the OpenSSL. I think that
> the problem is the OpenSSL, because before some errors, I tried to
> communicate the server with the client only with OpenSSL (the command
below) :
> openssl s_client -debug -msg -ssl3 -connect 192.168.13.57:60002
<snip: 3.0 ClientHello gets socket error 104>
> openssl s_client -debug -msg -ssl2 -connect 192.168.13.57:60002
<snip: 2.0 ditto>
Error 104 is ECONNRESET at least on the Linux I have to hand.
Are you sure you're talking to the right server and port?
I don't believe either OpenSSL (Apache+) or JCE (Jboss) will
TCP-abort during negotiation like that, especially on Unix.
Some other server/service that isn't expecting SSL/TLS might.
> openssl s_client -debug -msg -ssl3 -connect 192.168.13.57:443
> connect: Connection refused
> connect:errno=29
> openssl s_client -debug -msg -ssl2 -connect 192.168.13.57:443
<snip ditto>
Those definitely aren't the right server&port, or else
something in the network (such as a firewall) is blocking you.
(The errno= value is bogus, probably because the perror in
init_client_ip clobbered it, but the text is definitive.)
Also, if you did get into negotiation and the server requested
client-auth, s_client needs pkey&cert. But you're not that far.
> Error : Apache
> --------------
> [Thu Oct 08 17:12:39 2009] [debug] ssl_engine_kernel.c(1770):
> OpenSSL: Write: SSL negotiation finished successfully
> [Thu Oct 08 17:12:39 2009] [info] [client 192.168.13.57]
> SSL library error 1 reading data
> [Thu Oct 08 17:12:39 2009] [info] SSL Library Error: 336130329
> error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad
record mac
> [Thu Oct 08 17:12:39 2009] [debug] ssl_engine_kernel.c(1770):
> OpenSSL: Write: SSL negotiation finished successfully
> [Thu Oct 08 17:12:39 2009] [info] [client 192.168.13.57]
> Connection closed to child 0 with standard shutdown (server
sslejmtransfer.hst.br:443)
That CAN'T correspond to the s_client tests above. Those failed
before negotiation got started; this reports a problem that
happens (soon?) after negotiation completes successfully. They
must correspond to something else you aren't telling us about.
> There are a diference between the OpenSSL Client and Server,
> version and ciphers :
> - I tried changing the version of the OpenSSL on the server,
> but even changing it, the error didn't change.
> - My keys are 1024, and I saw that there are a diference between
> the ciphers on the server and client. Below, we can see that there are
> 5 ciphers disabled on the server (include/openssl/tls1.h), don't appear
> on the list (openssl ciphers -v).
> Server
<snip: normal list>
> Client
> ------
> TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
> TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
> TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
> TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA
> TLS_DHE_DSS_WITH_RC4_128_SHA
Do you mean these are the ONLY ciphersuites the client supports?
If so, it's clearly not OpenSSL. Or do you mean these are supported
in the client (perhaps built with ALLOW_EXPERIMENTAL as below)
but not in the server (built normally)? What/which server?
> tls1.h
> ------
> tls1.h:#define TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_MD5
0x03000060
<snip rest>
> I want to do the test with these ciphers. So, I NEED TO KNOW
> HOW I CAN ENABLE THESE CIPHERS?
See s3_lib.c as the comment right next to your quote says.
You need to set TLS1_ALLOW_EXPERIMENTAL_CIPHERSUITES
(actually set to 1 or other nonzero integer, not just
'define' as the comment says a bit too briefly.)
On the two (oldish) Linuxes accessible to me, the system copy
of OpenSSL apparently does have this option (patched?) on.
I would expect Apache to use the system copy unless you do
something odd. Are you sure which copy/version is used?
These ciphers won't be first in OpenSSL's default list,
so if both parties are OpenSSL and you want to use them,
at least one party must be configured to negotiate them.
For s_client just add -cipher EXP1024-RC4-SHA or similar.
For Apache it looks like SSLCipherSuite does this.
For other client you need say more or handle yourself.
And why do you want to use ciphersuites that apparently
weren't and won't be standardized? (RSA)DES-CBC-SHA and
EDH-DSS-DES-CBC-SHA work fine with 1024bit keys;
the only difference I see is that the auth/ka strength
limit would(?apparently?) be visible in the protocol,
and AFAIK OpenSSL doesn't enforce those anyway.
The RC4 cases aren't standard that I can see,
but RC4 has a pretty bad reputation nowadays.
And of course single-DES isn't secure now either;
I assume from the fact that you're asking for known
unsafe algorithms that you are under some legal
restriction -- or think you are; are you sure?
(There have been serious outbreaks of partial sanity
among governments in the past few years.)
If you do manage to actually use RC4-56, it wouldn't
astonish me if there is a bug there. I'd bet that
case is tested and used very little if at all.
But it isn't the cause of the symptom you're seeing
if you're not even getting through negotiation yet.
And on the one Linux I can test, which has 0.9.7a*,
(conn using) (RSA)EXP1024-RC4(56)-SHA does work OK.
(* I know; I'm not involved with system versions.
And I don't have time to do a test build right now.)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
