Maybe writing too fast.. "How do you force Java 8 to use SSLv2Hello?"
As suggested before, by writing your own client OR by trying this hack. >From the JSSE Ref Guide 5, we know how to the customize the protocol ( https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization ) by setting a system property (https.protocol). Although they are no more talking about this in the Ref Guide 8 ( https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider ) I would give it a try as I know that the documentation is poorly written. I suggested 10 years ago a change in the API doc about the enabled protocols, and they didn't change anything although they said they would. "[1] states: " JDK 7-9 enables SSLv2Hello on the server side only. (Will not send, but will accept SSLv2Hellos)"" I believe they mean "by default" as for the client side. Poorly written, probably. 2015-10-13 22:55 GMT+02:00 Aurélien Terrestris <aterrest...@gmail.com>: > "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 >>> >>> >> >
