Karthik Krishnamoorthy wrote:In this case the server seems to only support SSL 3.0 and 2.0, it does not seem to support TLS, the client seems to support the same as well.
We are using JSS 3.2 and we are getting the following error
SSL_ERROR_HANDSHAKE_FAILURE_ALERT -12227 "SSL peer was unable to negotiate an acceptable set of security parameters."
This happens when we are connecting so sites that are running Java Web Server.
The same problem does not happen when we connect to those sites using mozilla. Any ideas under circumstances the above error is thrown ?
In general, with any server, this problem is caused by one of the following:
1. no mutually enabled protocol version. For example, the server might support only SSL 3.1 (a.k.a. TLS) and the client might only support SSL 3.0.
I don't see this error the error I see is handshake failure ..
2. no mutually enabled ciphersuites. Although this usually causes a different
error, SSL_ERROR_NO_CYPHER_OVERLAP.
SSL trace below ..
Version: $Revision: 1.1 $ ($Date: 2000/03/31 20:12:54 $) $Author: relyea%netscape.com $
Connection #1 [Thu May 22 11:57:17 2003]
Connected to regis.central.sun.com:7070
--> [
alloclen = 72 bytes
(72 bytes of 72)
[Thu May 22 11:57:17 2003] [ssl2] ClientHelloV2 {
version = {0x03, 0x01}
cipher-specs-length = 45 (0x2d)
sid-length = 0 (0x00)
challenge-length = 16 (0x10)
cipher-suites = {
(0x010080) SSL2/RSA/RC4-128/MD5
(0x0700c0) SSL2/RSA/3DES192EDE-CBC/MD5
(0x030080) SSL2/RSA/RC2CBC128/MD5
(0x060040) SSL2/RSA/DES56-CBC/MD5
(0x020080) SSL2/RSA/RC4-40/MD5
(0x040080) SSL2/RSA/RC2CBC40/MD5
(0x000004) SSL3/RSA/RC4-128/MD5
(0x00feff) ??????????????????
(0x00000a) SSL3/RSA/3DES192EDE-CBC/SHA
(0x00fefe) ??????????????????
(0x000009) SSL3/RSA/DES56-CBC/SHA
(0x000064) TLS/RSA_EXPORT1024/RC4-56/SHA
(0x000062) TLS/RSA_EXPORT1024/DES56_CBC/SHA
(0x000003) SSL3/RSA/RC4-40/MD5
(0x000006) SSL3/RSA/RC2CBC40/MD5
}
session-id = { }
challenge = { 0x6129 0xfea9 0x025d 0x7b90 0x506d 0x5027 0xea62 0xa6a6 }
}
]
<-- [
(912 bytes of 907)
SSLRecord { [Thu May 22 11:57:19 2003]
0: 16 03 00 03 8b |.....
type = 22 (handshake)
version = { 3,0 }
length = 907 (0x38b)
handshake {
0: 02 00 00 46 |...F
type = 2 (server_hello)
length = 70 (0x000046)
ServerHello {
server_version = {3, 0}
random = {...}
0: 3e cc 6d f7 a4 eb cd 40 f3 b1 83 0a db dc 82 da | >[EMAIL PROTECTED]
10: 2c 27 da 5c 86 02 be 08 7d 7b af 4f f0 d5 9d 53 | ,'.\....}{.O�..S
session ID = {
length = 32
contents = {..}
0: 3e cc 6d f7 3c 8a 96 1f 4f 31 42 7c 04 80 5a 62 | >.m.<...O1B|..Zb
10: e5 3a e8 d7 de ac 6e 80 95 d0 f2 b7 cc c8 e0 be | .:....n...�.....
}
cipher_suite = (0x0003) SSL3/RSA/RC4-40/MD5
}
0: 0b 00 02 6c |...l
type = 11 (certificate)
length = 620 (0x00026c)
CertificateChain {
chainlength = 617 (0x0269)
Certificate {
size = 614 (0x0266)
data = { saved in file 'cert.001' }
}
}
0: 0c 00 00 c9 |....
type = 12 (server_key_exchange)
length = 201 (0x0000c9)
0: 0e 00 00 00 |....
type = 14 (server_hello_done)
length = 0 (0x000000)
}
}
]
--> [
(140 bytes of 68, with 67 left over)
SSLRecord { [Thu May 22 11:57:19 2003]
0: 16 03 00 00 44 |....D
type = 22 (handshake)
version = { 3,0 }
length = 68 (0x44)
handshake {
0: 10 00 00 40 |...@
type = 16 (client_key_exchange)
length = 64 (0x000040)
ClientKeyExchange {
message = {...}
}
}
}
(140 bytes of 1, with 61 left over)
SSLRecord { [Thu May 22 11:57:19 2003]
0: 14 03 00 00 01 |.....
type = 20 (change_cipher_spec)
version = { 3,0 }
length = 1 (0x1)
0: 01 |.
}
(140 bytes of 56)
SSLRecord { [Thu May 22 11:57:19 2003]
0: 16 03 00 00 38 |....8
type = 22 (handshake)
version = { 3,0 }
length = 56 (0x38)
< encrypted >
}
]
<-- [
(7 bytes of 2)
SSLRecord { [Thu May 22 11:57:19 2003]
0: 15 03 00 00 02 |.....
type = 21 (alert)
version = { 3,0 }
length = 2 (0x2)
fatal: handshake failure
0: 02 28 |.(
}
]
Read EOF on Server socket. [Thu May 22 11:57:19 2003]
Error -5961: TCP connection reset by peer.: Client socket read failed.
3. negotiation of a ciphersuite that is flawed in one or both implementations.
NSS now supports some of the most newly defined SSL and TLS ciphersuites.
There are some server products that have flawed and hence non-interoperable
implementations of those ciphersuites.
The problem seems to happen with a particular server irrespective of the cipher used. The server JWS ( Java Web Server 1.1x) and the cipher suites used for two different running servers were 40 bit SSL 3 RSA RC4 with MD5MAC and 128 SSL3 RSA RC4 with SHA. The above trace is for interaction with a server using 40 bit cert.
The exchange seems to be fine till a request comes in to change the cipher spec and subsequently the server is closing the connection. Is that a correct understanding of the problem ?
I believe it maybe an TLS-intolerant server but this particular server was written way back in 1998 or earlier and I am not sure if TLS existed at that time.
4. the server might be a so-called TLS-intolerant server, meaning that it is a
flawed SSL 3.0 server that does not correctly negotiate an SSL 3.0 session
with a client that supports both SSL 3.0 and TLS.
I tried this and it seemed to work only with SSL 3 with the different servers only working with the cipher's indicated above.
Try changing the set of enabled protocol versions. I'd recommend trying with
all 3 versions of SSL enabled first (SSL 2, SSL 3.0 and SSL 3.1), and then
trying with just SSL 2 and SSL 3.0 (no TLS). If that doesn't resolve it,
try disabling all the ciphersuites and then enabling each of them, one at a
time, until you find which ciphersuites work and which do not.
cheers Karthik
Please let us know what you find.
-- Nelson B
