I think this may also have been the root cause for 4435711,
but the problem inadvertantly went away with the
setEnabledProtocols API addition.

I think the underlying problem in 4435711 is still there.

Customer sees problems when doing client authentication
in JSSE 1.0.2. Problem seen on a SSL v3 server talking
to JSSE.

The analysis by Andreas follows:

=====begin======
The short answer is: this a SSL/TLS versioning problem. It happens only
if you have SSL 3.0 and TLS 1.0 enabled (the server only support SSL
3.0). It does not happen if you have only SSL 3.0 enabled (via
socket.setEnabledProtocols(new String[]{"SSLv3"}); ). This only works
with 1.4. JSSE 1.0.2 did not have this API and I believe there is no
other workaround for 1.0.2.

The server hosting the content identifies itself as
Netscape-Enterprise/4.1, although from the description of the
configuration I am not sure this is the server running the SSL code. In
any case, upgrading the SSL server to a later version may also fix the
problem.

The long answer is: actually, this is a spec compliance bug in JSSE. We
send a 3.0/3.1 hello, the server selects 3.0. Later, when we send the
RSA client key exchange message, we set the version in the premaster
secret to the current protocol version (3.0) although per spec it should
be the highest supported by the client (3.1) (see RFC2246, section
7.4.7.1). The server detects the mismatch and assumes this is an invalid
premaster secret. However, due to the Bleichenbacher attack it does not
complain immediately but instead generates a random premaster secret and
continues the handshake. When the finished messages are exchanged, the
handshake fails with a MAC error because different MAC keys are used.

The reason why we send 3.0 instead of 3.1 is that some early TLS
implementations (in particular SSLeay/OpenSSL) implemented this
incorrect behavior. In order to interoperate with them, you have no
choice but to implement it incorrectly as well. [That is what I assume
'we' did. At least that's what I did at IAIK] This problem will most
probably occur with all TLS implementations, unless they have TLS
disabled (IE default config) or do an automatic retry with a different
protocol version (Opera AFAIK). For example, I cannot connect with IE6
and TLS enabled either.

PS: it might be a good idea to add the setEnabledProcotols() to JSSE
1.0.3. Should be low risk.
=====end======

Jeff is wondering if the code should be fixed to properly
follow the spec. We're probably not seeing many instances
of this, as the servers may either be updated to fix this problem,
or they talk TLS in which case we'll never see this problem.

Anyway, it's not following the spec, and we should
at least consider fixing it in hopper/tiger.

One thing we could do with JSSE on the server side is to
calculate both values, and use the one that MAC's
correctly.

We should look at interop with other toolkits, and see
what they do, and if we feel there's low enough impact,
we might want to change the code to be spec-compliant.

###@###.### 2001-12-18

Note, if you try to connect to an openssl toolkit that's
been configured to use -no_tls1, things crash...

openssl s_server -debug -state -accept 4338 -cert ../serverkeys -CAfile ../ca.crt -Verify 5 -debug -state -no_tls1

SSL_accept:SSLv3 read client certificate A
write to 00174A30 [00173310] (7 bytes => 7 (0x7))
0000 - 15 03 00 00 02 02 28 ......(
SSL3 alert write:fatal:handshake failure
SSL_accept:error in SSLv3 read client key exchange B
SSL_accept:error in SSLv3 read client key exchange B
ERROR
12155:error:1408B074:SSL routines:SSL3_GET_CLIENT_KEY_EXCHANGE:bad protocol version number:s3_srvr.c:1346:
shutting down SSL
CONNECTION CLOSED
###@###.### 2001-12-18
=======================================================

Being spec compliant may not be that easy. For the client side, as long as we want to interoperate with servers that implement the 'wrong' behavior, we have to send wrong version number in the premaster secret. Otherwise, they will refuse to talk to us. The problem does not occur if the maximum supported version is also the version the server chooses. That means, as more and more servers are upgraded to TLS 1.0 from SSL 3.0, this problem may go away. However, it may resurface when server implementations are upgraded to a later TLS version, if they still implement the incorrect behavior.

On the other hand, what we should definitely do is change the handling on the server side. We should allow both the current behavior for interoperability but also permit spec compliant version numbers in the premaster secret. That is trivial and should be done for Hopper.

###@###.### 2001-12-19

Agreed on the second paragraph.

We may want to check to see how many of the
existing servers do still indeed exhibit this behaviour,
as if it's a rarity these days, we may want to go back.
Mr. Maurus did run into this problem. Or maybe
adding a system property which controls this behaviour...
the default being false if we find that it's not uncommon
to be broken.

One of SQE's tasks was to do some interoperability testing,
so this would be a good task for them to respond with.

###@###.### 2001-12-19