SSL handshake issue while java client talking to SSLv3 ONLY server

[Rajarajan Pudupatti Sundari Jeyakodi]

Hi,

We are facing a problem and I am sure this is the right place. We have a
load balancer (cisco's) and for various reasons the SSL configuration on
the load balancer (the server) side is set to use "SSLv3" protocol version.
Now after setting the same, when I access the load balancer in CHROME
browser, I am able to access the pages but I do see the below message when
I click on their security icon.



"*connection had to be retried using ssl 3.0*" - I looked at the packet
capture using wireshark and I see that browser tries *TLSv1* and receives a
"fatal alert" from the server saying "protocol_version" and *then
immediately browser tries SSLv3 version* and finishes the handshake. So
browser is able to negotiate this as a client.



However when I set up a stand alone java (tried using 1.6 as well as 1.7)
client from eclipse and try connecting to the server I am getting the below
exception.



: Received fatal alert: protocol_version javax.net.ssl.SSLException:
Received fatal alert: protocol_version


As per various documentations, I saw two options I have


1. to set https.protocol system property to SSLv3. [this works for us, but
the problem is it is affects the outbound SSL calls globally. I have
another outbound SSL call to another server which does not work with SSLv3]



2. setEnabledprotocols() - this works as well but sometimes, we dont have
access to the socket directly (sometime we generates stubs using third
party and the stub takes care of the low level connection stuff, so no
access to that socket).



*But my actual question is*, If by default TLSv1/SSLv3 and SSLv2Hello(just
the format I believe) are enabled in java, why is JSSE implementation not
able to negotiate like how chrome browser is able to negotiate. Is this
expected? If browser is doing it, I believe it should be part of some SSL
RFC and if that is the case, same functionality of this "negotiation"
should be provided by java itself right?



I did go through this
*http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/SSLSocketImpl.java
<http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/SSLSocketImpl.java>*and
was not able to find any part for this negotiation during handshake.



Is there a possibility of issue from the server side (load balancer)  that
i. I see that server sends fatal alert but that being cisco I believe the
ssl implementation should be perfect and that is expected. Am I wrong?



Issue happens both in java 1.6 and 1.7. Do let me know if more information
would be required to answer, will be happy to help.


Thanks

Rajarajan PSJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20131114/59bfba51/attachment.htm>