Yeah it's in my msg below. Java logs it sequentially and I was looking at where the payload was created, not wher it was serialized [1]. I realized my mistake when I took a pcap and then had a closer look at the logs. I also know how this is handled in the JSSE code - the hello wrapper is handled by I/O layer, not by the handshaker...
I don't think https://www.ietf.org/rfc/rfc5246.txt 's Appendices E.1 and E.2 refer to my situation. They talk about initial handshakes, which in my case go just fine. Regarding the last remark, about 2 handshakes without data inbetween - it's not like I am handling raw sockets. In one case the clinet is HttpsUrlConnection, the other is the Apache HttpClient 3. Also, since I have put together an SChannel server I can see the data in between the handshakes making it through... George [1] *** ClientHello, TLSv1 <********************* I was looking here RandomCookie: <snip> Session ID: {} Cipher Suites: [TLS_RSA_WITH_AES_256_CBC_SHA] Compression Methods: { 0 } Extension renegotiation_info, renegotiated_connection: <empty> *** [write] MD5 and SHA1 hashes: len = 52 ... main, WRITE: TLSv1 Handshake, length = 52 [write] MD5 and SHA1 hashes: len = 47 ... main, WRITE: SSLv2 client hello message, length = 47 <********************* But it went out here where it got serialized [Raw write]: length = 49 ... [Raw read]: length = 5 0000: 16 03 01 02 E7 ..... [Raw read]: length = 743 ...main, READ: TLSv1 Handshake, length = 743 *** ServerHello, TLSv1 -----Original Message----- From: Aurélien Terrestris [mailto:aterrest...@gmail.com] Sent: Wednesday, October 14, 2015 3:59 PM To: Tomcat Users List Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac Still no solutions, I suppose.. Did you enable the SSLv2 Hello as suggested by Chris, and what's the result ? I tested a small client with Java 8, by adding -Djdk.tls.client.protocols="SSLv2Hello,TLSv1.2" at the command line, and I get my SSLv2 Hello. From the TLS 1.2 RFC ( https://www.ietf.org/rfc/rfc5246.txt ) we know we must expect some problems like yours (Appendix E.1 & E.2). I'm not saying it's that kind of things for sure, but this is what they suggest : "Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client." And that's what HttpUrl class does, a retry. I am not sure that we can blindly trust the JSSE Ref Guide , but it's saying that the renegotiation (for your client cert) has to happen after some data was already been sent to each other. My question is : are you sure you are not doing 2 handshakes without sending data between them ? See : https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization *"Encrypted data* The client and the server communicate using the symmetric encryption algorithm and the cryptographic hash function negotiated during the client hello and server hello, and using the secret key that the client sent to the server during the client key exchange. The handshake can be renegotiated at this time. See the next section for details." 2015-10-14 4:56 GMT+02:00 George Stanchev <gstanc...@serena.com>: > So this time I spoke too soon. I was relying on Java to dump in its > debug trace. Running rawcap/wireshark does reveal that Java indeed > wraps the > TLSv1.2 hello payload in SSLv2Hello record envelope which that legacy > protocol enables. The Java piece of code that I quoted was for the > content of the ClientHello record, not how it is wrapped which happens > later when the record is being serialized to the socket... > > Anyways, thanks to all for the tip but it doesn't make a > difference...still bad mac record... > > George > > -----Original Message----- > From: George Stanchev [mailto:gstanc...@serena.com] > Sent: Tuesday, October 13, 2015 3:56 PM > To: Tomcat Users List > Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, > description = bad_record_mac > > May be I am mistaken. I will give jtouch a try, thanks for the > pointers...at this point I am grasping at straws :) > > Thanks Aurelien! > > -----Original Message----- > From: Aurélien Terrestris [mailto:aterrest...@gmail.com] > Sent: Tuesday, October 13, 2015 3:52 PM > To: Tomcat Users List > Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, > description = bad_record_mac > > "Another route to try the SSLv2Hello is to hack and recompile the JSSE. > It's on my agenda to learn to do that if possible without rebuilding > the whole JRE since for some obscure reason Oracle compiles JSSE with > no debug info (and it is not included in the srcs distributed with the > JRE) on it which makes debugging and inspecting local vars really hard..." > > No, it's not needed. I use jtouch.sourceforge.net and it's working > well for trying SSLv2 hello's. From the network captures, I see that > it's working. > Not making advertisement for my software here, but,.. ;) > > > > > > > > 2015-10-13 23:20 GMT+02:00 George Stanchev <gstanc...@serena.com>: > > > Just as a side note, https.protocols is read by HttpsUrlConnection > > which feeds it down through setEnabledProtocols() on the SSL socket. " > > jdk.tls.client.protocols" is read directly by JSSE and does the same > > thing... > > > > Another route to try the SSLv2Hello is to hack and recompile the JSSE. > > It's on my agenda to learn to do that if possible without rebuilding > > the whole JRE since for some obscure reason Oracle compiles JSSE > > with no debug info (and it is not included in the srcs distributed > > with the > > JRE) on it which makes debugging and inspecting local vars really hard... > > > > George > > > > -----Original Message----- > > From: Aurélien Terrestris [mailto:aterrest...@gmail.com] > > Sent: Tuesday, October 13, 2015 3:13 PM > > To: Tomcat Users List > > Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, > > description = bad_record_mac > > > > 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/JSSERe > > fG uide.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/SunP > > ro > > viders.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. > > > ht > > > ml > > > #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
