FW: Issue with Tomcat Version 7.0.64

Hi Christopher, Apologies for the formatting issue. Hope the below shared details helps clarify the issue. Our application has a customized valve called CiscoSSOValve.java which extends SingleSignOn.java of catalina.jar. SingleSignOn.java of catalina.jar has gone in some changes in 7.0.64.

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

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

Re: Monitoring Connections

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jamie, On 10/9/15 10:03 AM, Jamie Jackson wrote: > Here's the stack trace dump: > https://gist.github.com/jamiejackson/ca2a49d2c8afac496067 > > FWIW, I've been trying to come up with a reliable test case to > trigger the problem, but I haven't

Re: JDBC PoolExhaustedException

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nathan, On 10/9/15 4:11 PM, Nathan Boyce wrote: > Does the tomcat jdbc pool use its own executor or does it share > the executor that's calling it? A connection pool rarely has a thread pool associated with it: it's just a repository for

Tomcat 8 Rewrite Valve

Hello - I'm having issues implementing a HTTP 301 redirect via the Rewrite Valve module. Ref - https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html Tomcat v8.021 is running on Ubuntu 14.04 x64. The requirement is to run the rewrite config globally for all webapps, for this reason the valve

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/9/15 12:46 PM, George Stanchev wrote: > One more clarification: on point [6] below I stated that Java is > able to recover with a retry on a cached connection. Unfortunately > that is only valid for higher level classes like

Issue with Tomcat Version 7.0.64

Hi, We have recently upgraded Tomcat to 7.0.64 from 7.0.59. Our application extends SingleSignOn.java of catalina.jar to create a wrapper around it. Some methods in the SingleSignOn.java class has been deprecated because of which the compilation is failing. Details shared below.

Re: questions about tomcat 7 executor with rest services

Thanks > On Oct 12, 2015, at 5:01 PM, Mark Thomas wrote: > > On 12 October 2015 21:26:30 BST, Brian Millett wrote: >> I’m looking for some insight / info into using executor thread pool for >> a tomcat 7 server that handles many REST services. >>

Re: Unable to deploy app with Tomcat Manager Text interface using a Context Descriptor

On 13/10/2015 16:09, ptruche wrote: > My application context is defined as an XML file located in > `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`. > name='my_config_dir' value='/my/path/to/myApp' type='java.lang.String'/> > > `/my/path/to/myApp` contains the WAR file

Re: Unable to deploy app with Tomcat Manager Text interface using a Context Descriptor

Sorry about the formatting issue. Here is the corrected version.--- My application context is defined as an XML file located in `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`.           

Unable to deploy app with Tomcat Manager Text interface using a Context Descriptor

My application context is defined as an XML file located in `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`.                `/my/path/to/myApp` contains the WAR file myAppWarFile.war and a number of externalized properties that are read by Spring. Tomcat is configured with autoDeploy

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

Hi Chris, How do you force Java 8 to use SSLv2Hello? So far I am unable to force it to go down to use SSLv2Hello. It would've been nice to be able to control the first handshake message version (TLSv1 or TLSv1.2 or SSLv2Hello), but I have not been able to do that... George -Original

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

Hi Chris, [1] states: " JDK 7-9 enables SSLv2Hello on the server side only. (Will not send, but will accept SSLv2Hellos)" 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

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.

Re: Issue with Tomcat Version 7.0.64

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kasturi, On 10/13/15 9:59 AM, kasturi wrote: > We have recently upgraded Tomcat to 7.0.64 from 7.0.59. Our > application extends SingleSignOn.java of catalina.jar to create a > wrapper around it. Some methods in the SingleSignOn.java class has >

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 : > >> 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

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

>> 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

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

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

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

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George and Aurélien, On 10/13/15 5:06 PM, George Stanchev wrote: > Try the dropbox location in my prev messages. It contains a sample > echo server you can use to test. It is a Visual Studio 2013 > project. In case you don’t have that, I've

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

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 (

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

Aurlien, Try the dropbox location in my prev messages. It contains a sample echo server you can use to test. It is a Visual Studio 2013 project. In case you don’t have that, I've uploaded x64 executables under SSLServer_executbale.zip. It is pretty much self contained, it has the redist DLLs,

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 (

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 10/13/15 5:08 PM, Christopher Schultz wrote: > George and Aurélien, > > On 10/13/15 5:06 PM, George Stanchev wrote: >> Try the dropbox location in my prev messages. It contains a >> sample echo server you can use to test. It is a Visual

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

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

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

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

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

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: