"Ok, may be you are ahead of me on this one, but setEnabledProtocols(), to my understanding does the same as the system property "jdk.tls.client.protocols". It gives the JSSE a pool of protocols to choose from but it will be up to JSSE to select the ClientHello version. I might have missed something but I spent quite a bit of time in the Handshaker and related classes in the JDK and couldn't see anything that can change that..."
Sorry, but I believe that no. To understand, you need to look to the old Ref Guide ( https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization ) which in "Annex A" says that you context.getInstance() takes one argument called "protocol" while sslsocket.setEnabledProtocols() takes a list of protocols including the SSLv2Hello. If you are about to write a TLS client using a SSLv2Hello, you will call getInstance("TLS") and setEnabledProtocols("SSLv2"). I hope things are more understandable :) 2015-10-13 23:12 GMT+02:00 George Stanchev <gstanc...@serena.com>: > Ok, may be you are ahead of me on this one, but setEnabledProtocols(), to > my understanding does the same as the system property > "jdk.tls.client.protocols". It gives the JSSE a pool of protocols to choose > from but it will be up to JSSE to select the ClientHello version. I might > have missed something but I spent quite a bit of time in the Handshaker and > related classes in the JDK and couldn't see anything that can change that... > > George > > -----Original Message----- > From: Aurélien Terrestris [mailto:aterrest...@gmail.com] > Sent: Tuesday, October 13, 2015 2:55 PM > To: Tomcat Users List > Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, > description = bad_record_mac > > "How do you force Java 8 to use SSLv2Hello?" > > You can do this when writing your own Java client : calling the > SSLSocketFactory to create an SSLSocket and configure with > setEnabledProtocols ( > > https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#setEnabledProtocols-java.lang.String:A- > ) > > If you have some IIS server on internet which reproduces the problem, I'll > try with JTouch ( jtouch.sourceforge.net ) or write a small client. > > > > > 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris <aterrest...@gmail.com>: > > > George, > > > > do you have any network capture that we can see ? > > > > 2015-10-13 22:10 GMT+02:00 George Stanchev <gstanc...@serena.com>: > > > >> >> It might be doable with OpenSSL s_client or something. Tough to > >> replicate Java's behavior with a non-Java tool, though. > >> > >> I tried hard with the s_client but it can limit the protocols to one > >> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0) > >> like Java > >> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which > >> is also on top of openssl. > >> > >> Today, I spent 2.5 hours with a lemming from MS getting basically > >> nowhere. I really need an engineer, but they give me those clueless > >> support people that is wasting mine and their time. If someone knows > >> how to escalate or a forum where MS developers hang out, I would > appreciate it. > >> The support person I got today was clueless, went over a script and > >> any attempt to explain a little more technical details led to total > >> confusion and rebooting the script to beginning. Totally frustrating. > >> At least with Oracle I got to talk with an actual engineer... > >> > >> George > >> > >> > >> -----Original Message----- > >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > >> Sent: Tuesday, October 13, 2015 2:03 PM > >> To: Tomcat Users List > >> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, > >> description = bad_record_mac > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> George, > >> > >> On 10/13/15 12:35 PM, George Stanchev wrote: > >> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only. > >> > (Will not send, but will accept SSLv2Hellos)" > >> > >> Interesting. This absolutely makes sense, though, since SSL should > >> just die. :) > >> > >> > I've opened support case both MS and already there is a bug filed > >> > with Oracle on this and really, to be absolutely certain if the > >> > issue is in Java or SChannel, one would have to write a non-Java > >> > client that that mimics the handshake messages send from Java with > >> > something like OpenSSL or NSS or whatever and see if the bug > replicates. > >> > >> It might be doable with OpenSSL s_client or something. Tough to > >> replicate Java's behavior with a non-Java tool, though. > >> > >> > Writing a Java/Java server client could still leave some doubts as > >> > one can argue the code reuse could mask the problem - it works but > >> > the bug on the client side is hidden by the server containing > >> > similar/same bug so the MACs check out... > >> > > >> > Unfortunately I don't have the time to invest in this more than I > >> > already had. And if MS support engineers can pass it on to someone > >> > from the windows core team may be we can have some movement forward. > >> > >> Okay. Thanks for your work so far. > >> > >> - -chris > >> -----BEGIN PGP SIGNATURE----- > >> Comment: GPGTools - http://gpgtools.org > >> > >> iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0 > >> 7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5 > >> t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ > >> XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1 > >> E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ > >> +r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57Pwrp4ZVZ6d7RM+CIqt28SfxT > >> EtTamDZ8aPYsCKqMWIYRPyLrWaouEuLJEmzweF8B+NxY0svK8vEOiro/vR4LycOZ > >> PG5zxuS/QMJR2oEgkeUz9+NhB8nP/qJxMhc40pKGmvZxC7ljM/tP7jTvE1MwmMHE > >> P8rX5b3yF8DfMdGZdIlrHJ8wXYSzJdTMJvA5ffXVKaObGMYtAFFDlfupud1iO9ML > >> Hh4exxX+/NU7fXt+ot6BLEFAfDD9+z6uOeq+vK6bxaITubFVGIavhowjAgQIBNt3 > >> O//p9dJQVKan0db9kqyLpLMrrFYd/cmA8DZDxoY/iaVuoKhJ6blbDMQKi2DlsvgF > >> WGDHUsSBZIYTFq5mc7VO > >> =eyUN > >> -----END PGP SIGNATURE----- > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
