title: SSL handshake issue while java client talking to SSLv3 ONLY server
body: <p>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.</p>
  
  <p>"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.</p>
  
  <p>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.</p>
  
  <p>: Received fatal alert: protocol_version javax.net.ssl.SSLException: Received fatal alert: protocol_version</p>
  
  <p>As per various documentations, I saw two options I have</p>
  
  <ol>
  <li><p>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]</p></li>
  <li><p>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).</p></li>
  </ol>
  
  <p>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?</p>
  
  <p>I did go through this <a href="http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/SSLSocketImpl.java" rel="nofollow">http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/SSLSocketImpl.java</a> and was not able to find any part for this negotiation during handshake.</p>
  
  <p>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?</p>
  
  <p>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.</p>