From the source of truth: sun.security.ssl.ClientHandshaker.java of the latest
JDK 8 update 60
this.enabledProtocols = [SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]
this. maxProtocolVersion = TLSv1.2
// Not a TLS1.2+ handshake
// For SSLv2Hello, HandshakeHash.reset() will be called, so we
// cannot call HandshakeHash.protocolDetermined() here. As it does
// not follow the spec that HandshakeHash.reset() can be only be
// called before protocolDetermined.
// if (maxProtocolVersion.v < ProtocolVersion.TLS12.v) {
// handshakeHash.protocolDetermined(maxProtocolVersion);
// }
// create the ClientHello message
ClientHello clientHelloMessage = new ClientHello(
sslContext.getSecureRandom(), maxProtocolVersion,
sessionId, cipherSuites);
I just stepped through the code, there is absolutely no way to override this
without hacking JSSE...
/sigh
George
-----Original Message-----
From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
Sent: Tuesday, October 13, 2015 3:41 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description
= bad_record_mac
"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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
