> From: owner-openssl-us...@openssl.org On Behalf Of Mr.Rout > Sent: Friday, 11 May, 2012 03:50
> Please help me out in debugging this cipher negotiation issue. > > My client supports OpensslV1.0 and my server supports > Openssl0.9.7. I used > self-signed RSA type certificate on both server & client. But > my Handshake is failing. > A Snippet from SSLdump: > 3 1 0.0100 (0.0100) C>SV3.1(101) Handshake > ClientHello > Version 3.1 > random[32]= > 4f ac c2 65 e1 fc 67 9b c3 06 9b 2a 74 34 4d a8 > 5b a0 2b 85 8a bd d8 06 99 c8 48 31 37 46 9b d4 > resume [32]= > 96 a6 be fa ec ac 21 f4 c9 ec 9b 5c c5 e9 5c bf > 38 71 1c ef 87 ce f3 b6 b0 6d 11 f2 72 71 11 d7 > cipher suites > TLS_RSA_WITH_RC4_128_MD5 > TLS_RSA_WITH_RC4_128_SHA > Unknown value 0x2f > Unknown value 0x35 > Unknown value 0x34 > Unknown value 0x3a > Unknown value 0x33 > Unknown value 0x39 > TLS_RSA_WITH_3DES_EDE_CBC_SHA > Unknown value 0xff > compression methods > NULL > 3 2 0.0106 (0.0006) S>CV3.1(2) Alert > level fatal > value handshake_failure > 3 0.0107 (0.0001) S>C TCP FIN > > > > The question are: > 1) Why TLS handshake is failing on both client & server support the > cipher=DHE-RSA-AES128-SHA All we can see on the wire is the server doesn't like something. Does the server have any log, or debug options, you can look at? 0.9.7a is very old. I think it did implement extensions, but not all, although it can/should negotiate away unknown ones. I don't recall what other features it doesn't have, and it definitely doesn't have a lot of recent fixes. > 2) Why i am seeing unknown as my ciphers in client hello > message ( on ssldump) ? Your ssldump is apparently also very old. It doesn't know the AES suites, or the fake suite (SCSV) for secure-renegotiation. It isn't showing any ClientHello extensions, but for 1.0.0 client there should be some. I don't know if ssldump is being maintained; if so get a current version. Or get www.wireshark.org (on Windows or MacX) instead; it functionally replaces ssldump and is definitely up to date. I'm also concerned it shows data in 'resume', which from the position I believe means sess-id for resumption. If this client hasn't been able to complete a handshake with this server, it shouldn't have a sess-id to resume; if it has, why did the previous one work and this one fail? > 3) Is it has anything to do with RSA self-signed-certificate ? > Almost certainly not. That might cause your client to refuse to trust the server, depending on your client's configuration (and code), but it wouldn't cause the server to give an error. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
