Hi Aurelien, https://www.dropbox.com/sh/az1r3agxx4w8r7e/AACRGedBG3G5oh4-qE9652WNa?dl=0
It's not a pcap but rather javax.debug logger capture which is similar. I can do pcap but since java dumps the stream along with handshake messages description, I haven't bothered to capture it. This folder also contains the test Java client and an SSPI echo server that emulates the problem and has the SSPI calls to demonstrate the issue. "cood capture.txt" is when you run with TLSv1-only. "bad capture.txt" is when you run with defaults...If you run the java client you need to update final String targetURL = "https://rm9485:443/gsoap/gsoap_ssl.dll?sbminternalservices72";; to point to the correct machine. Uncommenting //System.setProperty("jdk.tls.client.protocols", "TLSv1"); makes the call succeed. The SSLServer on the native side will return SEC_E_DECRYPT_FAILURE from AcceptSecurityContext() when the TLS connection is upgraded to 2way ssl after ClientCertVerify's changing of cipher specs. I spent time in the Java handshaker and while I don't understand it enough, I saw the failure right after it flushes the running MAC down the stream onto the server. At this point SSPI fails the call with bad_mac_record which is behind the code SEC_E_DECRYPT_FAILURE... George -----Original Message----- From: Aurélien Terrestris [mailto:aterrest...@gmail.com] Sent: Tuesday, October 13, 2015 2:23 PM To: Tomcat Users List Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac 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 > >
