tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aurélien Terrestris <aterrest...@gmail.com>
Subject Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
Date Tue, 13 Oct 2015 21:13:29 GMT
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 <aterrestris@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 <aterrestris@gmail.com>:
>
>> George,
>>
>> do you have any network capture that we can see ?
>>
>> 2015-10-13 22:10 GMT+02:00 George Stanchev <Gstanchev@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:chris@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message