Handshake Exception with Firefox and Jetty Servlet Container

Question

We do have a strange problem with Firefox 2 and Jetty 6.1 (a Servlet Container) using HTTPS to communicate: At some stage Firefox (FF) sends a ClientHelloV2, to which Jetty responds with a ServerHelloV3. This leads to a handshake failure for this handshake and for any subsequent attempt.
To avoid the handshake failures there are 2 options:
1.) restart FF
2.) change the servername or port, by using ssltap [2] as a proxy.
[FF] --> [ssltap] --> [Jetty]
That way it is possible to change the port without restarting
FF and Jetty, and to debug the SSL traffic.
Both options make FF to start a SSL session, by sending a ClientHelloV3. Then everything works until we get to the same stage described above.
h2. Logs:
From what I can see in the logs of ssltap, Firefox is sending some data, which might be something like a partial handshake (?).
--> [
alloclen = 63 bytes
(63 bytes of 63)
[Wed Jan 09 12:18:41 2008] [ssl2] ClientHelloV2 {
version = {0x03, 0x00}
cipher-specs-length = 36 (0x24)
sid-length = 0 (0x00)
challenge-length = 16 (0x10)
cipher-suites = {
(0x000039) TLS/DHE-RSA/AES256-CBC/SHA
(0x000038) TLS/DHE-DSS/AES256-CBC/SHA
(0x000035) TLS/RSA/AES256-CBC/SHA
(0x000033) TLS/DHE-RSA/AES128-CBC/SHA
(0x000032) TLS/DHE-DSS/AES128-CBC/SHA
(0x000004) SSL3/RSA/RC4-128/MD5
(0x000005) SSL3/RSA/RC4-128/SHA
(0x00002f) TLS/RSA/AES128-CBC/SHA
(0x000016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
(0x000013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0x00feff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
(0x00000a) SSL3/RSA/3DES192EDE-CBC/SHA
session-id = { }
challenge = { 0xa954 0x2122 0x3e82 0xb993 0xd72f 0xea54 0x779f 0x958c }
The server responds with:
<-- [
(1161 bytes of 1156)
SSLRecord { [Wed Jan 09 12:18:41 2008]
0: 16 03 00 04 84 |....�
type = 22 (handshake)
version = { 3,0 }
length = 1156 (0x484)
handshake {
0: 02 00 00 46 |...F
type = 2 (server_hello)
length = 70 (0x000046)
ServerHello {
server_version = {3, 0}
random = {...}
0: 47 84 ad 91 a1 f6 cb e5 f8 e2 f0 46 60 4b dd 48 | G����.&#9574;.�.�F`K.H
10: 13 a8 93 96 d2 4f 2b d8 2d fe 49 2f 22 e5 29 5e | .����O+�-.I/".)^
session ID = {
length = 32
contents = {..}
0: 47 84 ad 91 84 b7 ef 62 92 fb 03 d7 8a 41 ae 82 | G������b��.�.A�.
10: d5 57 a3 e0 24 cc b5 2e b2 c7 29 3d 3a 37 a6 11 | &#305;W��$&#9568;�.&#9619;�)=:7�.
cipher_suite = (0x0032) TLS/DHE-DSS/AES128-CBC/SHA
0: 0b 00 02 f6 |....
type = 11 (certificate)
length = 758 (0x0002f6)
CertificateChain {
chainlength = 755 (0x02f3)
Certificate {
size = 752 (0x02f0)
data = { saved in file 'cert.001' }
0: 0c 00 01 38 |...8
type = 12 (server_key_exchange)
length = 312 (0x000138)
0: 0e 00 00 00 |....
type = 14 (server_hello_done)
length = 0 (0x000000)
+Then FF responds with a handshake failure:+
--> [
(7 bytes of 2)
SSLRecord { [Wed Jan 09 12:18:41 2008]
0: 15 03 00 00 02 |.....
type = 21 (alert)
version = { 3,0 }
length = 2 (0x2)
fatal: handshake failure
0: 02 28 |.(
I am pretty stuck. Do you have any idea? Or can you give me any advice, how to further investigate this problem?
Thanks,
-Stefan
[2] http://www.mozilla.org/projects/security/pki/nss/tools/ssltap.html

Answer 1

I did some more analysis:
When I replace the keystore by another keystore provided by the Jetty
distribution, Firefox will not complain about the handshake
exception. Nevertheless there are handshake exceptions, and the SSL
level switches from TLS to SSLv3.
Now I guess the question is: What is the difference between the two
keystores?
Answer: As far as I can see, the Keystore provided in the Jetty distro
has expired in 2001, while my keystore is still valid (although also
self-generated).
Could it be, that Firefox some is less strict regarding handshake
failures, after you have told it to accept an expired certificate?
I am not sure whether this is problem of JSSE, or not? What do you think?