Re: Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
Diarmuid, On 27.8.2015 22:31, dmccrthy wrote: * our non-production server with the same versions of all client software connects with no errors to a non-production instance of the same 3rd party service using the same cipher suite. So the tool we're using is our 3rd party client Web app (the Tomcat client). It shows the same negotiation from TLSv1.2 down to TLSv1. My reading of your comments is that the truststore/keystore has no bearing here because it's an outgoing client connection and there are no inbound connections at play. There are too many differences between working and non-working environments: client, firewall and server. Could you narrow that down? Could you connect from non-production client to production server, and vice versa? Could you move production client to non-production firewall, or non-production client to production firewall? -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8 Session Timeout
Hello - currently HTTP sessions are configured to timeout after 120 seconds, in $CATALINA_BASE/conf/web.xml session-config session-timeout2/session-timeout /session-config However this is not being honoured by the web services, where many session are lasting longer. From what I understand - the order for session timeouts is - HttpSession.setMaxInactiveInterval(int) $WebApplication/webapp/WEB-INF/web.xml $TOMCAT_BASE/conf/web.xml Is there something that I'm missing? Theo - The Mileage Company Limited is a limited company registered in England under company number 2260073 whose registered office address is at Astral Towers, Betts Way, London Road, Crawley, West Sussex, RH10 9XY. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by Mimecast for the presence of computer viruses. -
Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Diarmuid, I'm marking this as off-topic because it seems like Tomcat really has nothing to do with the situation. On 8/27/15 4:31 PM, dmccrthy wrote: Thanks for responding so quickly. My apologies, I should have been clearer on the topology. We have a Tomcat instance with a 3rd party web app deployed on it (the Tomcat client) running on Windows 2008 . This connects via HTTPS to a 3rd party service running behind IBM Http Server on Solaris 10. Okay, so, just to confirm: Tomcat (app) - HTTPS - 3rd party service Configurations and results: 0. prod Tomcat - prod 3rd-party service FAILS with TLS_RSA_WITH_AES_128_CBC_SHA (do other ciphers work? or are you completely dead in the water?) 2. prod Tomcat - prod 3rd-party service with lower version of Tomcat and/or Java WORKS with TLS_RSA_WITH_AES_128_CBC_SHA 1. test Tocmat - test 3rd-party service WORKS with TLS_RSA_WITH_AES_128_CBC_SHA 2. test client (command-line?) on production host - prod 3rd parts service WORKS with TLS_RSA_WITH_AES_128_CBC_SHA No changes are known/expected, other than Tomcat and Java version. So the tool we're using is our 3rd party client Web app (the Tomcat client). It shows the same negotiation from TLSv1.2 down to TLSv1. My reading of your comments is that the truststore/keystore has no bearing here because it's an outgoing client connection and there are no inbound connections at play. Exactly. Neither the keystore nor the truststore have any bearing, here. If the client library itself uses (or supports) a truststore/keystore, then you'll likely know about it because you'd have to make a call like client.setTruststore(3rdparty.jks) or whateve r. * I don't know what the highest supported cipher suite is on either client or server hosts. I do know that TLSv1 is the highest supported by the 3rd party server. Good to know, but not terribly relevant. The client and server should negotiate a common cipher suite based upon those available on either end. If they can't agree, the handshake fails. * we're not using JCE Unlimited Security because it hasn't been an issue and frankly I didn't think of it when we were doing the installations :) Okay. Two additional pieces of analysis that came out of our investigations today are: 1) we are using NextGen Cisco devices. These are application and protocol aware. This means that the firewall might allow allow our standalone Java client to connect using HTTPS, but interfere with the HTTPS SOAP requests from our Tomcat/3rd party app Tomcat client. How can the device be application aware? How does the applicaiton identify itself to the device? How is that authenticated? What is stopping EvilApp.exe from claiming to be InnocentApp.exe? 2) there are some anecdotes of Java 7 clients failing to downgrade from TLSv1.2 to TLSv1. For example http://stackoverflow.com/questions/31579587/java-tls-1-2-downgrade-to- tls-1-0-sometimes-error. This is not a piece of analysis. This is something you found online that might be related. But you haven't collected any information to support the idea that it's related. I note that the experience is different in that SO article: the user is getting a different error at a different part of the handshake. Some takeaway actions for me to explore are below. I'll welcome any other thoughts that you may have. 1) compare the firewall rules on our working non-production client with the rules governing the failing production client Firewalls are usually pretty dumb. I'd be surprised if the firewall is breaking anything, here. 2) use openssl from our client server and see what it shows Yes, please do that. Why wasn't that the first thing you tried? 3) consider forcing the Tomcat/3rd party Tomcat client to use TLSv1 This is a possibility, but you shouldn't have to hamper your own application because there are some servers out there that are so old they don't support TLSv1.2: you should always offer the best encryption you can, and only fall-back when necessary. 4) check other logs on the server side to see if other clients are failing TLS handshakes You didn't do this already? 5) investigate the supported ciphers on client and server There is code available in the archives of this mailing list to do that. Search for my name and ssl and poke-around. 6) consider upgrading Tomcat (as a last resort) I thought the initial problem was that an upgrade to Tomcat broke something. I think it's more likely to be the Java upgrade that did something, and not Tomcat itself. Are you sure that the standalone test client is using the exact same version of Java as the Tomcat server is? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV4KNUAAoJEBzwKT+lPKRYPVMQAILQm/n33Mxh7cbYF3u0VfNg eodcwvrXxWynhDX61ZjUGNTAPbEAsReLIuCzZjJpmB+LIaBsg8qsxpNL4zu+W4YA ZYB2wiORHpgqXVXG3JuX2tlzKGmAaF8YnlWnsjaw+taZNWOwVvFvJN4esdp8eYYw
Can filters be loaded more than once?
I'm using Tomcat 8.0.23, but wondered if a filter defined in the Tomcat conf/web.xml as well as defined in my app's WEB-INF/web.xml file causes the filter to be loaded twice or whether duplicate filters are ignored? If duplicates are ignored, what makes it a duplicate? Just the name, the filter-name and url-pattern combo? The filter-class? Is the filter-name field can sensitive? Noted that Tomcat uses a lowercase 's' for it's filter name. In Tomcat's conf/web.xml: filter filter-namesetCharacterEncodingFilter/filter-name filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param async-supportedtrue/async-supported /filter filter-mapping filter-namesetCharacterEncodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping In my webapp's WEB-INF/web.xml: filter filter-nameSetCharacterEncodingFilter/filter-name filter-class org.apache.catalina.filters.SetCharacterEncodingFilter /filter-class async-supportedtrue/async-supported !-- Enable if using Vaadin PUSH -- init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter-mapping filter-nameSetCharacterEncodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping When using Atmosphere with Vaadin PUSH, I occasionally get an exception that indicates an issue with async operations, and it shows my filter twice in the stack trace: *java.lang.IllegalStateException: A filter or servlet of the current chain does not support asynchronous operations.** *at org.apache.catalina.connector.Request.startAsync(Request.java:1610) at org.apache.catalina.connector.RequestFacade.startAsync(RequestFacade.java:1037) at javax.servlet.ServletRequestWrapper.startAsync(ServletRequestWrapper.java:392) at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:723) at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:93) at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:68) at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:2075) at com.vaadin.server.communication.PushRequestHandler.handleRequest(PushRequestHandler.java:226) at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1408) at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:351) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) *at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)* at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) *at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)* at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:614) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:617) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)
Re: Tomcat 8 Session Timeout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Theo, On 8/28/15 12:08 PM, theo.swe...@avios.com wrote: Hello - currently HTTP sessions are configured to timeout after 120 seconds, in $CATALINA_BASE/conf/web.xml session-config session-timeout2/session-timeout /session-config I'd highly recommend that you move that configuration from conf/web.xml to your own web application's web.xml. However this is not being honoured by the web services, where many session are lasting longer. From what I understand - the order for session timeouts is - HttpSession.setMaxInactiveInterval(int) $WebApplication/webapp/WEB-INF/web.xml $TOMCAT_BASE/conf/web.xml Is there something that I'm missing? That's pretty much it (except the path for the app's web.xml looks a little odd). Are the web services specifying their own session-timeout in the application-specific web.xml? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV4KO3AAoJEBzwKT+lPKRYh8cQALjjzZ4glyywX4HrTpfAOtEJ Ck1LC/S82MgNfCfS1dOx8fUpuER6ZSJ+fkALjAMjAr5MmQX+/Z2nODvj/XWDLkRj 6Hyp/F+rEnExt4bS6idWz32hPtzDqxA4Ffxy9oCROihXXdvA0qGn6xGfKwtUaBH2 rviw3au4uD2W3iPffszUj3VnGQnWhK3QFQpFCLkpVu1lF/EiqBCL3XHIY+6cDzBO fpGWiFrk+9RSuP/uN3LEGzdZNvuHNiNu5OrlvBq9P8Q1zwya6fcuPGu0NvFD7ESl o0pCmcie9NUFXN1R0/RtT8uw7ZVELWrPx5C6zLR1tbwodMnarlQMazAdQFDDtiVK DLPjpKF0bPqAP3ORUzRAu3IfSaXhtgE77byAB8DLnPJjpKeyWEp4tCDP1CmI6NI1 5dVQmt5CJAo5pP5YAMM38GsJyY5NoQ2NI61tPJ/NFTJkV0pyCGlufiRMp6ySMvBP zY8CjhNEjhfEV35RB1hYzawhZ3hgV3oq78HLGLZ15eaYiBTBHyHyKgdbitRfawIP ICdvpuElYDPNKFI2SfSb3qQc64sm+kqN6B1DNWMALAWISNENB0ahu6D4a9UJTr0R FgFRCdpkkV8/3FfpoSpu2kzzBubYMA7XpMyuk9HWlABJvT99AJCwPeA2C5falShv j5HCHDLxsn1LzK8hl9mK =3HRA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 Session Timeout
On 28/08/2015 12:08, theo.swe...@avios.com wrote: Hello - currently HTTP sessions are configured to timeout after 120 seconds, in $CATALINA_BASE/conf/web.xml session-config session-timeout2/session-timeout /session-config However this is not being honoured by the web services, where many session are lasting longer. From what I understand - the order for session timeouts is - HttpSession.setMaxInactiveInterval(int) $WebApplication/webapp/WEB-INF/web.xml $TOMCAT_BASE/conf/web.xml Is there something that I'm missing? Tomcat version? The usual causes are: - something unexpected accessing the session - the background processing thread is crashed / busy doing something else Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: WebSocket asynchronous reads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Steffen, On 8/26/15 12:50 PM, Steffen Heil (Mailinglisten) wrote: Is there a way to tell tomcat to stop receiving data for a certain websocket? (Not to close it, but not to read from inputstream for some time.) Sorry, no. The best you can do is a no-op branch in the message handler. Which means I have to either buffer all incoming messages until I am ready to process them (might occupy lots of memory) or I have to drop them. Both is not really ideal. I'm largely ignorant of the asynchronous world, but I do have a question about what you're asking. Are you really asking if Tomcat can buffer all that data for you (which might occupy lots of memory) until you are ready to accept it? It seems like if you aren't comfortable with dropping the data on the floor, then it's your responsibility to accept the data and deal with it yourself, right? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV4J86AAoJEBzwKT+lPKRYx8AQAIDpb0yUftV2BU9YKbCBntHQ zFPTXsp+CtTa7hBphOFFTe/OZ21sKYJDD+dOQiWv/YP3mUClc0OZ4ZOmqt25UJfm X7xhWg0qfaCceY8gC1VatJb738wTLErGsWDwugHvspFDyvEjxsPF/drNGpIPlBee G/qu1z02RqolPXA+GijKZPEnCJhh2xw8Utu9JO9g/MCGCWN4SFItcRaQZlD6Mx/S tp7zQMWL1OP7Uo5672cfqUZkXHbfoM5l8H8cW/K1pqCROCKsy9RCmYB1ne1yhiek 9uF8xLu1vWIsAiZp+yMPCyLtpea80J+iwUKDu612AisLVyTPJdzalk4sbYdmu1h7 kI1plbNi4oIp1nZ3RbjJFavzCs4ffepvXMjJKols15ggFgddKTXBw8zwQiJ1MJ60 MOQzWm9IDYpO7p/nBiinP66kt6IHIYJs7zu9SnNI9ELxydLUIRpkQFvds7wygee1 fVe2ha1vgxmCtMGcWlGAgYW2VINdLvAaD1cEcHOGc2i1M3vj4rppijffZBAXTnZ7 X1y+v/+cESmKXiKAUUUjerQxcmj4g7xMbBfcqEl+VzfnAcAe7gDWz8adRbonaDXa +3QIh6qCeP8dVNa834Fgd6mLcbHKnj26uEoFwsPm3buQEAUBFmDL/dOTR9Uw09VJ 5uN1OVnyJ5kqUyef1Bn5 =+e6t -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat can't find JDBC Driver listed under Maven
Okay I am trying to use connection pooling for my project which uses Maven as a build tool. Now the JDBC Driver is listed as a maven dependency. Tomcat however cant find it when I try to do ds.getConnection (ie. get a JDBC connection from a datasource). The error that I am getting is -: java.sql.SQLException: Cannot create JDBC driver of class '' for connect URL 'null' at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createConnectionFactory(BasicDataSource.java:2065) at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createDataSource(BasicDataSource.java:1939) at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1412) at test.Test.doGet(Test.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:618) at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:537) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1085) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1556) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1513) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) Caused by: java.sql.SQLException: No suitable driver at java.sql.DriverManager.getDriver(DriverManager.java:315) at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createConnectionFactory(BasicDataSource.java:2049) ... 27 more As you can see in the end it says that caused by No suitable driver My copy of context.xml is as follows-: Context Resource name=jdbc/TestDB auth=Container type=javax.sql.DataSource maxTotal=100 maxIdle=30 maxWaitMillis=1 removeAbandonedOnBorrow=true timeBetweenEvictionRunsMillis=1 minEvictableIdleTimeMillis=6000 removeAbandonedOnMaintenance=true logAbandoned=true username=sreyan password=sreyan driverClassName=com.mysql.jdbc.Driver url=jdbc:mysql://localhost:3306/practice/ Realm className=org.apache.catalina.realm.DataSourceRealm dataSourceName=jdbc/TestDB userTable=users userNameCol=user_id userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name CredentialHandler className = org.apache.catalina.realm.SecretKeyCredentialHandler algorithm = PBEWITHHMACSHA384ANDAES_256 iterations = 11 saltLength = 20 / /Realm /Context And my copy of web.xml is -: web-app display-nameArchetype Created Web Application/display-name servlet servlet-nameHibTest/servlet-name display-nameHibTest/display-name description/description servlet-classtest.HibTest/servlet-class /servlet servlet servlet-nameTest/servlet-name display-nameTest/display-name description/description servlet-classtest.Test/servlet-class /servlet servlet-mapping servlet-nameHibTest/servlet-name url-pattern/hib/url-pattern /servlet-mapping servlet-mapping servlet-nameTest/servlet-name url-pattern/Test/url-pattern /servlet-mapping resource-ref descriptionDB Connection/description res-ref-namejdbc/TestDB/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref security-constraint
Re: Tomcat can't find JDBC Driver listed under Maven
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sreyan, On 8/28/15 3:11 PM, Sreyan Chakravarty wrote: Okay I am trying to use connection pooling for my project which uses Maven as a build tool. Now the JDBC Driver is listed as a maven dependency. Tomcat however cant find it when I try to do ds.getConnection (ie. get a JDBC connection from a datasource). The error that I am getting is -: java.sql.SQLException: Cannot create JDBC driver of class '' for connect URL 'null' [snip] Caused by: java.sql.SQLException: No suitable driver at java.sql.DriverManager.getDriver(DriverManager.java:315) at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createConnectionFactory(B asicDataSource.java:2049) ... 27 more As you can see in the end it says that caused by No suitable driver Where is your mysql-*.jar file? Context Resource name=jdbc/TestDB auth=Container type=javax.sql.DataSource maxTotal=100 maxIdle=30 maxWaitMillis=1 removeAbandonedOnBorrow=true timeBetweenEvictionRunsMillis=1 minEvictableIdleTimeMillis=6000 removeAbandonedOnMaintenance=true logAbandoned=true username=sreyan password=sreyan driverClassName=com.mysql.jdbc.Driver url=jdbc:mysql://localhost:3306/practice/ Realm className=org.apache.catalina.realm.DataSourceRealm dataSourceName=jdbc/TestDB userTable=users userNameCol=user_id userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name CredentialHandler className = org.apache.catalina.realm.SecretKeyCredentialHandler algorithm = PBEWITHHMACSHA384ANDAES_256 iterations = 11 saltLength = 20 / /Realm /Context I'm glad you got the CredentialHandler stuff working (or did you?). NOTE: your Realm is going to need to have this attribute added to it in order to work: localDataSource=true I have used the Maven webapp archetype for creating the project. How do I get Tomcat to load the driver at start up. Also I have put the JDBC Driver at $Catalina_Home/lib. But even this has no help. All my other projects that don't use Maven can use connection pooling perfectly with the above configurations. Do you have the JDBC driver in both places (lib/ and webapps/[app]/WEB-INF/lib) or just in Tomcat's lib/ directory? Where am I going wrong ? Where do you keep the resource-ref declaration ? After the servlet mappings ? I've found that resource-ref is entirely unnecessary, but that may be because you have declared the Resource in your app's META-INF/context.xml file, so your application already knows it's local. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV4LdEAAoJEBzwKT+lPKRYHr4P/3Ewp4bFEOSU7SG17nzmMK9Q YpT8g+Zd8AFuF5uKH/IjogFMaZD5wgYalImjMxp1/KzgT3XULK0YWfd1NZcK276i kxXNEMB7ybjmbETASVGh/BDrCNn/v6GPv1TCI/mrjsrcP4iRHeUrLiMjfk9KxdaO n2kmn770bvBmYn/VvILu9KTLF1rWh/aY75mdUc2q5mtyqdC7dg+Ky0aeZCdQj5yM yxJCInN8ntk/UFIO2ycDoosgdQIvA9c0+4VluKJ7tGLSc0QRrEaLjNnAHn3J/evP jpUQTSnhgD9G9dzjVNEtNcwTFbPNemdItpSVFPHB3p6An5sE6uKY4hkTiCDAwTk5 4cp8fkpabVvSz0+FEYZ9FSOqeun2Bn61bJTqPM4Yk9Z9dfC92CcKkC8tnjnVyPaK DGgMxEFFZgBza9BZAtcGWn3CzOWBQvRJCiK/xm02dQKHYyszA33W/h9pGB1hIWJT hePUusot0w9p8IgDhFh4+0cTkTNAVUnIQWnPuHsdUn5Itc0qql1LDWRdhWlQMc6W tp3Oqt7noSnoZpIa2mLimXW/36QOkm1nxZl3urnbTlsxPuAmfrEt/ndfIoWPlhcN 1jbAF7Kh4k4wdBbu4SNptl1xqb2GVD3f+BcuSQr3s2OkYd8fXQqFzIDjS9JzWvD5 iX2CYicMQroQhgS/06MQ =oogU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Diarmuid, On 8/28/15 3:25 PM, dmccrthy wrote: Thanks again for replying. I agree it doesn't look like a Tomcat issue and would be happy to close the issue. I've included responses to your points below prefixed with [DMC] for my initials, but think I need to focus on the Java side of things and perhaps open an Oracle ticket. Feel free to continue the conversation here. I just marked it as off topic because it's not directly-related to Tomcat. This could have happened in any other application server, for instance. There's nothing wrong with having an off-topic discussion, here. I just wanted everyone to know that this wasn't directly-related to Tomcat . See below. On 8/27/15 4:31 PM, dmccrthy wrote: Thanks for responding so quickly. My apologies, I should have been clearer on the topology. We have a Tomcat instance with a 3rd party web app deployed on it (the Tomcat client) running on Windows 2008 . This connects via HTTPS to a 3rd party service running behind IBM Http Server on Solaris 10. Okay, so, just to confirm: Tomcat (app) - HTTPS - 3rd party service Configurations and results: 0. prod Tomcat - prod 3rd-party service FAILS with TLS_RSA_WITH_AES_128_CBC_SHA [DMC] Correct Ok. (do other ciphers work? or are you completely dead in the water?) [DMC] No, this is the next step. Our production environment is completely locked down and we have to exhaust all other avenues before making speculative changes. I suppose what I meant was: do 100% of your connections to this 3rd-party service fail because this one cipher suite seems to be broken, or do you have some connections that work and others that do not? If some work, do they have anything in common with each other? 2. prod Tomcat - prod 3rd-party service with lower version of Tomcat and/or Java WORKS with TLS_RSA_WITH_AES_128_CBC_SHA [DMC] Correct So, downgrading does in fact improve the situation. Can you try upgrading Java in one of your working production environments but leave Tomcat alone? That would definitely rule-out Tomcat as a problem. 1. test Tocmat - test 3rd-party service WORKS with TLS_RSA_WITH_AES_128_CBC_SHA [DMC] Correct Good. What version was this running again? Same Java/Tomcat versions as the production server which seems to fail? 2. test client (command-line?) on production host - prod 3rd parts service WORKS with TLS_RSA_WITH_AES_128_CBC_SHA [DMC] Correct. The command line test client is a simple Java class that just opens an InputStream to the 3rd party service So: same Java, same host, same client library: works. But within Tomcat on that host with that Java with that same client library: fails? :( No changes are known/expected, other than Tomcat and Java version. [DMC] It's a greenfield app and no changes are planned bar functional patches. The same version of operating system, java, tomcat, and the application is in our non-prod environment and works ok There is obviously a difference. We just have to figure out what it is. What are your JVM parameters to launch Tomcat? You can find those out using jinfo from the command-line if you have the process id (at least I *think* that works on Windows). Check the running production application as well as the CLI client running on the same machine. Quadruple-check the Java versions of those processes. Two additional pieces of analysis that came out of our investigations today are: 1) we are using NextGen Cisco devices. These are application and protocol aware. This means that the firewall might allow allow our standalone Java client to connect using HTTPS, but interfere with the HTTPS SOAP requests from our Tomcat/3rd party app Tomcat client. How can the device be application aware? How does the applicaiton identify itself to the device? How is that authenticated? What is stopping EvilApp.exe from claiming to be InnocentApp.exe? [DMC] the firewall devices check the tcp connections. I don't know how. I do know we had endless trouble from overzealous firewall guys putting restrictive rules in place. The impact of that was that, for example, we could telnet through the firewall but not establish a Sybase connection. In any case, we compared all the non-prod and prod firewall rules and they are configured the same way. We also had several debug sessions with the firewall guys and no traffic is being blocked. So at least we've ruled that out. Good. 2) there are some anecdotes of Java 7 clients failing to downgrade from TLSv1.2 to TLSv1. For example http://stackoverflow.com/questions/31579587/java-tls-1-2-downgrade- to- tls-1-0-sometimes-error. This is not a piece of analysis. This is something you found online that might be related. But you haven't collected any information to support the idea that it's related. I note that the experience is different in that SO article: the user is getting a different error at a different
Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
Hi Chris, Thanks again for replying. I agree it doesn't look like a Tomcat issue and would be happy to close the issue. I've included responses to your points below prefixed with [DMC] for my initials, but think I need to focus on the Java side of things and perhaps open an Oracle ticket. Best regards, Diarmuid On 28 Aug 2015 19:08, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Diarmuid, I'm marking this as off-topic because it seems like Tomcat really has nothing to do with the situation. On 8/27/15 4:31 PM, dmccrthy wrote: Thanks for responding so quickly. My apologies, I should have been clearer on the topology. We have a Tomcat instance with a 3rd party web app deployed on it (the Tomcat client) running on Windows 2008 . This connects via HTTPS to a 3rd party service running behind IBM Http Server on Solaris 10. Okay, so, just to confirm: Tomcat (app) - HTTPS - 3rd party service Configurations and results: 0. prod Tomcat - prod 3rd-party service FAILS with TLS_RSA_WITH_AES_128_CBC_SHA [DMC] Correct (do other ciphers work? or are you completely dead in the water?) [DMC] No, this is the next step. Our production environment is completely locked down and we have to exhaust all other avenues before making speculative changes. 2. prod Tomcat - prod 3rd-party service with lower version of Tomcat and/or Java WORKS with TLS_RSA_WITH_AES_128_CBC_SHA [DMC] Correct 1. test Tocmat - test 3rd-party service WORKS with TLS_RSA_WITH_AES_128_CBC_SHA [DMC] Correct 2. test client (command-line?) on production host - prod 3rd parts service WORKS with TLS_RSA_WITH_AES_128_CBC_SHA [DMC] Correct. The command line test client is a simple Java class that just opens an InputStream to the 3rd party service No changes are known/expected, other than Tomcat and Java version. [DMC] It's a greenfield app and no changes are planned bar functional patches. The same version of operating system, java, tomcat, and the application is in our non-prod environment and works ok So the tool we're using is our 3rd party client Web app (the Tomcat client). It shows the same negotiation from TLSv1.2 down to TLSv1. My reading of your comments is that the truststore/keystore has no bearing here because it's an outgoing client connection and there are no inbound connections at play. Exactly. Neither the keystore nor the truststore have any bearing, here. If the client library itself uses (or supports) a truststore/keystore, then you'll likely know about it because you'd have to make a call like client.setTruststore(3rdparty.jks) or whateve r. * I don't know what the highest supported cipher suite is on either client or server hosts. I do know that TLSv1 is the highest supported by the 3rd party server. Good to know, but not terribly relevant. The client and server should negotiate a common cipher suite based upon those available on either end. If they can't agree, the handshake fails. * we're not using JCE Unlimited Security because it hasn't been an issue and frankly I didn't think of it when we were doing the installations :) Okay. Two additional pieces of analysis that came out of our investigations today are: 1) we are using NextGen Cisco devices. These are application and protocol aware. This means that the firewall might allow allow our standalone Java client to connect using HTTPS, but interfere with the HTTPS SOAP requests from our Tomcat/3rd party app Tomcat client. How can the device be application aware? How does the applicaiton identify itself to the device? How is that authenticated? What is stopping EvilApp.exe from claiming to be InnocentApp.exe? [DMC] the firewall devices check the tcp connections. I don't know how. I do know we had endless trouble from overzealous firewall guys putting restrictive rules in place. The impact of that was that, for example, we could telnet through the firewall but not establish a Sybase connection. In any case, we compared all the non-prod and prod firewall rules and they are configured the same way. We also had several debug sessions with the firewall guys and no traffic is being blocked. So at least we've ruled that out 2) there are some anecdotes of Java 7 clients failing to downgrade from TLSv1.2 to TLSv1. For example http://stackoverflow.com/questions/31579587/java-tls-1-2-downgrade-to- tls-1-0-sometimes-error. This is not a piece of analysis. This is something you found online that might be related. But you haven't collected any information to support the idea that it's related. I note that the experience is different in that SO article: the user is getting a different error at a different part of the handshake. [DMC] I agree. But in the spirit of trying different cipher suites, this is something that may (or may not) be relevant Some takeaway actions for me to explore are below. I'll
Re: Can filters be loaded more than once?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 8/28/15 2:47 PM, David Wall wrote: I'm using Tomcat 8.0.23, but wondered if a filter defined in the Tomcat conf/web.xml as well as defined in my app's WEB-INF/web.xml file causes the filter to be loaded twice or whether duplicate filters are ignored? If duplicates are ignored, what makes it a duplicate? Just the name, the filter-name and url-pattern combo? The filter-class? I've never looked into this, but I would imagine that Tomcat does no checking for duplicate filter definitions. Otherwise, the above questions are raised :) Is the filter-name field can sensitive? Almost certainly. Noted that Tomcat uses a lowercase 's' for it's filter name. In Tomcat's conf/web.xml: filter filter-namesetCharacterEncodingFilter/filter-name filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/ filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param async-supportedtrue/async-supported /filter filter-mapping filter-namesetCharacterEncodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping Note that the above Filter is commented-out by default. In my webapp's WEB-INF/web.xml: filter filter-nameSetCharacterEncodingFilter/filter-name filter-class org.apache.catalina.filters.SetCharacterEncodingFilter /filter-class async-supportedtrue/async-supported !-- Enable if using Vaadin PUSH -- init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter-mapping filter-nameSetCharacterEncodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping When using Atmosphere with Vaadin PUSH, I occasionally get an exception that indicates an issue with async operations, and it shows my filter twice in the stack trace: *java.lang.IllegalStateException: A filter or servlet of the current chain does not support asynchronous operations.** * at org.apache.catalina.connector.Request.startAsync(Request.java:1610) Boy, it would be nice if Tomcat told you which Filter of or Servlet of the current change didn't support asynchronous operations. I don't immediately see a good way of getting that information from the Request object. :( - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV4LYQAAoJEBzwKT+lPKRYjMoQAJuw/bu4Efmw/Mc0tm6hXaaU fJBSSsfZJfPGzahCvMGRTciTEe/E7cjsSIHgkdZKy1UUYSx2mnLZNTkiMaQRu2Sg XmmN6nzKC7dtNPrYGgkN+RqbUJXjpeO0vV6RLJHdzGcQ9vQ4409t733QQuFbuzeS DfcCCnSiwK8i4APQyuQWpuT4Th/kyehZfp4mtlIQHN6BsmekRH6VUIHI9rRajPgF zUtPEXnqdlXOD5B2dtRDePQNBVIO5s8Es+GzD68L2m/XseIt6WxbHUYe8lGcKp6g 7O7LBfe+VhgCaIsoC/aPJ9hyA75z1p/O1h8Rcb8ft4G8BYdvVYQl6Dc76XzYdVYy RdSu5FaGBRsCAromAJ0/ThSa2oKPMcrINUkMDdoMGE12Rr5+d/QVO6jMlpq0MgqY PkXox+eB7pzcFFUkU4wWDOe3xqVHgMWW4E3dop+tfCHti9HDhfcgUNP6ch7MAEIm 8+3iZ8DKeyqmvp1TQn9HQcM/I+or0qE3GvQsYZR00Z4C7Rp4/QdmMMhZwNoqgnHw kCxrIgCA2KPeEBYVkTsx9LG0P8dzitDps3EFLTsETSygfd1JmrCPx+8PlrAgjkcM 7FnrJAHX1fZ28EoNMmdf8f0FJ3InmBB9APO3Kw+YbayJeZxuV4gg/dAPZT3PGI0p RYZ2Ubhc8zpwgOTjEHMC =DJRR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
