Tomcat 8 APR/openSSL Issue
On my AMI (Amazon Linux) server, tomcat 8 was running happily but today, after an upgrade (Version is now 8.5.16.0), the server is failing to start with the following message: INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["https-openssl-nio-8443"] /usr/share/soengine/jdk/bin/java: symbol lookup error: /usr/lib64/libtcnative-1.so.0.2.10: undefined symbol: SSL_CTX_add0_chain_cert I can see that before these lines, OpenSSL is loaded: INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.0.1e-fips 11 Feb 2013] However, I don't know why this version of OpenSSL is being shown. On the OS terminal (Kernel: 4.9.51-10.52.amzn1.x86_64 #1 SMP), if I check, it is showing a different version. (I could not find any duplicate installation of OpenSSL on the server). openssl version -v OpenSSL 1.0.2k-fips 26 Jan 2017
Re: Performance settings for Multiple Hosts
On 05/10/17 21:36, Jerry Malcolm wrote: > I am running TC 8.0 on WinServer8 on a commercially hosted platform with > a WAMP environment. I am running around 10 virtual hosts. 2 hosts > are dedicated to JSPWiki. The other 8 are running variations of the > same custom application with around 10-15 individual webapps each. > > When I am running 7 of the 10 hosts, performance is great. I get JSP > response time under a second. But when I add just a couple of more of > the hosts, my page response time on all of the apps goes from an > acceptable under a second to horrible at around 15-20 seconds per page. > It doesn't seem to be a specific host causing the problem. Reducing > overall hosts in any order makes the problem go away. > > I've looked at the the processor utilization during the good times and > slow times, and don't see a significant difference. I have 16GB of > memory, and it consistently shows about 35% utilization. Is this the OS memory or what you have allocated to Java? > I also checked > mySQL response time, and the per-query SQL response does not vary. So > it doesn't appear to be a db problem. > > I suspect there is some TC configuration parameter such as heap, etc > that I need to tweak. (But I'm not getting OutOfMemory errors). But I > don't know which one, and I don't know a formula to use to figure out > what to set it to. So I just need a little education. What tools can I > use to help me figure out what is going south slowing everything to a > crawl when the extra hosts come online? And what parameters should I be > looking at (and how should I calculate the proper values based on number > of hosts)? > > Suggestions?> > Thanks. > > Jerry > > > - > 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
Performance settings for Multiple Hosts
I am running TC 8.0 on WinServer8 on a commercially hosted platform with a WAMP environment. I am running around 10 virtual hosts. 2 hosts are dedicated to JSPWiki. The other 8 are running variations of the same custom application with around 10-15 individual webapps each. When I am running 7 of the 10 hosts, performance is great. I get JSP response time under a second. But when I add just a couple of more of the hosts, my page response time on all of the apps goes from an acceptable under a second to horrible at around 15-20 seconds per page. It doesn't seem to be a specific host causing the problem. Reducing overall hosts in any order makes the problem go away. I've looked at the the processor utilization during the good times and slow times, and don't see a significant difference. I have 16GB of memory, and it consistently shows about 35% utilization. I also checked mySQL response time, and the per-query SQL response does not vary. So it doesn't appear to be a db problem. I suspect there is some TC configuration parameter such as heap, etc that I need to tweak. (But I'm not getting OutOfMemory errors). But I don't know which one, and I don't know a formula to use to figure out what to set it to. So I just need a little education. What tools can I use to help me figure out what is going south slowing everything to a crawl when the extra hosts come online? And what parameters should I be looking at (and how should I calculate the proper values based on number of hosts)? Suggestions? Thanks. Jerry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Severity of CVE-2016-6816
On 05/10/17 20:35, Justin wrote: > Hi all, > I'm curious about the severity of CVE-2016-6816 fixed last November. > http://svn.apache.org/viewvc?view=revision=1767653 > > I see that vendors backported this fix (over time). > http://www.securitytracker.com/id/1037332 > Severity is described as Important, Moderate, CVSS v2 Medium, and CVSS v3 > High. > "A remote user can exploit this to spoof content on the target server, > attempt to poison any intermediate web caches, or conduct cross-site > scripting attacks." > This sounds pretty serious. If my server is running a vulnerable version of > Tomcat, how easy is it to exploit? I'm not going to go into the details of exactly how to exploit this issue but the answer to your question is pretty difficult. 1. You need to be running Tomcat behind a reverse proxy of some form. 2. That reverse proxy needs to accept the same invalid requests as Tomcat (it should reject them with a 400 response). 3. The attacker needs to be able to either upload arbitrary static content which they can then request or formulate a request in such a way that arbitrary content is injected into the response. 1 is very common. 2 is possible but I haven't seen any evidence of it for these particular invalid requests. 3 is (very) unlikely. Overall, I'd judge the chances of all of these lining up on any given system as low to very low. It is one of those where the chances of it happening are low but the impact if it does happen is high. You could argue rating of Low, Moderate or High for this on Tomcat's scale. It is very much a judgement call. Where there is uncertainty over the likelihood then we tend to err on the side of caution. > Must webapps use cookies as some example exploits have shown? No. > "By manipulating the HTTP response the attacker could... obtain sensitive > information from requests other then their own." So if trusted users are > logging in, untrusted users could obtain passwords? Path or query parameters? Untrusted users could obtain anything from the response intended for a trusted user. Passwords are therefore unlikely, as is anything on the request side unless the application is echoing that data back to the client. Session cookies are probably the most likely target. HTH, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: ISAPI and IIS 10 Logging Issue
[External Email] -- On 05.10.2017 17:09, George Stanchev wrote: > > >> Note that also in the course of my investigations, somewhere I found a >> phrase to the effect that Mirosoft would be discouraging the future use of >> ISAPI modules in IIS, and recommends some other architecture instead now. > > Do you remember where you saw that? Can you provide a link? Oh my, I think that I wrote this... I do not remember exactly, but it might have been through a Google search for "IIS and ISAPI", which yelds this first result : https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_iis_configuration_system.webserver_isapifilters_=DwIC-g=Ff2GokX4A_6S-cy_JRNEiQ=qnRbnLRaPTyCnNugXfUwBahUZvJn-qGmC8Rh9wHr8D0=DbQ305KuTM2F_E2iBepldzdcGBtdlaOltNKMsXQJiPY=RhqitdWJrYFj4X-VbyU24zGMsHLG_rF_ZPbp8r7_AZk= (see the Note box) or here : https://urldefense.proofpoint.com/v2/url?u=https-3A__technet.microsoft.com_en-2Dus_library_cc733109-2528v-3Dws.10-2529.aspx=DwIC-g=Ff2GokX4A_6S-cy_JRNEiQ=qnRbnLRaPTyCnNugXfUwBahUZvJn-qGmC8Rh9wHr8D0=DbQ305KuTM2F_E2iBepldzdcGBtdlaOltNKMsXQJiPY=M-sMPmY0MIsn5kRfRQh585_T47nRBfnglZrF8SOey9s= "In IIS 7, modules replace ISAPI filters, but you can still add ISAPI filters if you require the functionality that they provide. " or here : https://urldefense.proofpoint.com/v2/url?u=https-3A__technet.microsoft.com_en-2Dus_library_cc753568-2528v-3Dws.11-2529.aspx=DwIC-g=Ff2GokX4A_6S-cy_JRNEiQ=qnRbnLRaPTyCnNugXfUwBahUZvJn-qGmC8Rh9wHr8D0=DbQ305KuTM2F_E2iBepldzdcGBtdlaOltNKMsXQJiPY=XKH-dyaNlgF0SZw__Fd1QToaxeEblm3xQMfH1Qc57Lk= Not really solid, but I am quite sure that I saw something more "forceful" elsewhere. Ah, here : https://urldefense.proofpoint.com/v2/url?u=https-3A__technet.microsoft.com_en-2Dus_library_hh831460-2528v-3Dws.11-2529.aspx=DwIC-g=Ff2GokX4A_6S-cy_JRNEiQ=qnRbnLRaPTyCnNugXfUwBahUZvJn-qGmC8Rh9wHr8D0=DbQ305KuTM2F_E2iBepldzdcGBtdlaOltNKMsXQJiPY=dCzIxTcvs4S2BUcLmkC9Nk3iAk985CuVxROdGRwfI8E= There (for IIS 8) it says "are replaced". All of this without any guarantee though, I am not an MS expert in any way. -- On 05.10.2017 17:09, Thomas, Michael wrote: Just want to drop a few questions: Are folks who develop and maintain the ISAPI redirector on this mailing list? Is the ISAPI redirector still in active development? It looks like it hasn't had an update since 2016. http://tomcat.apache.org/connectors-doc/news/20160901.html If so, have the folks who maintain it tested on Windows 2016 and IIS 10? The preceding message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2512, is intended only for the person or entity to which it is addressed, and may contain information that is confidential, protected by attorney-client or other privilege, or otherwise protected from disclosure by law. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error and destroy the original message and all copies. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Severity of CVE-2016-6816
Hi all, I'm curious about the severity of CVE-2016-6816 fixed last November. http://svn.apache.org/viewvc?view=revision=1767653 I see that vendors backported this fix (over time). http://www.securitytracker.com/id/1037332 Severity is described as Important, Moderate, CVSS v2 Medium, and CVSS v3 High. "A remote user can exploit this to spoof content on the target server, attempt to poison any intermediate web caches, or conduct cross-site scripting attacks." This sounds pretty serious. If my server is running a vulnerable version of Tomcat, how easy is it to exploit? Must webapps use cookies as some example exploits have shown? "By manipulating the HTTP response the attacker could... obtain sensitive information from requests other then their own." So if trusted users are logging in, untrusted users could obtain passwords? Path or query parameters? Thanks, Justin
Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.
This just keeps getting weirder. Late yesterday afternoon, I did a lengthy "stare-and-compare" between what SSLInfo returned for the two different Tomcat servers, and I couldn't find any differences. But then, I got called away from this on something that kept me in the office until after 7 PM. Finally getting back to it, I looked at the "connector ciphers" on the Tomcat 8 manager (there isn't one on the Tomcat 7 manager), and saw that only 16 of the 36 ciphers that SSLInfo starred as "default" are actually enabled in Tomcat. Then, using what Mr. Schultz told me about reading cipher names, I compared what actually *does* come up in the Tomcat 8 manager with the DSPSYSVAL on the AS/400. And I found that if *RSA_AES_256_CBC_SHA is the same as TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA then maybe we DO have a common cipher, at least in theory (unless "ECDHE" makes it otherwise). Unfortunately, I can't run the local box's Tomcat server through SSLLabs, because it's on a nonstandard port number, and Tomcat 7 doesn't have a "connector ciphers" button on the manager main page. The cloud box is a Google Compute Engine instance. Is it possible that Google is somehow vetoing the handshake? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ISAPI and IIS 10 Logging Issue
On 05.10.2017 17:09, George Stanchev wrote: Note that also in the course of my investigations, somewhere I found a phrase to the effect that Mirosoft would be discouraging the future use of ISAPI modules in IIS, and recommends some other architecture instead now. Do you remember where you saw that? Can you provide a link? Oh my, I think that I wrote this... I do not remember exactly, but it might have been through a Google search for "IIS and ISAPI", which yelds this first result : https://docs.microsoft.com/en-us/iis/configuration/system.webserver/isapifilters/ (see the Note box) or here : https://technet.microsoft.com/en-us/library/cc733109%28v=ws.10%29.aspx "In IIS 7, modules replace ISAPI filters, but you can still add ISAPI filters if you require the functionality that they provide. " or here : https://technet.microsoft.com/en-us/library/cc753568%28v=ws.11%29.aspx Not really solid, but I am quite sure that I saw something more "forceful" elsewhere. Ah, here : https://technet.microsoft.com/en-us/library/hh831460%28v=ws.11%29.aspx There (for IIS 8) it says "are replaced". All of this without any guarantee though, I am not an MS expert in any way. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.5.23 - Nio2 Connector - Error reading request, ignored
Dear All, We are running Tomcat 8.5.23 production server on a CentOS 6.9 machine, Oracle JVM 1.8.0_144, and OpenSSL 1.1.0f. The server hosts a web application where almost all the traffic is https. We used to have a Http11NioProtocol connector with Java SSL using HTTP 1.1 but we switched to Http2Protocol upgrade because of problems with Apple clients (KeepAlive timeout, server dropped the connection, etc..). We also switched to OpenSSL for ALPN. Since then we have had several problems with the different connectors, all of them tested with Tomcat 8.5.16, 8.5.20 and 8.5.23. - Http11NioProtocol has a memory leak, we experienced the same behaviour as this bug https://bz.apache.org/bugzilla/show_bug.cgi?id=57546 so we have to restart the server regularly. - Http11AprProtocol runs fine but the JVM crashes unexpectedly with a core dump from time to time. - Http11Nio2Protocol runs fine but some requests are not processed. We have not found a way to reproduce the problem but it happens once every 5 minutes. The server processes 1.13 million requests per day so it's one request failed every 4000 approximately. We can't reproduce the failed requests, but some crawling tools report them as if the server failed to respond (no status code) This is the exception we get: 05-Oct-2017 17:13:32.535 SEVERE [https-openssl-nio2-94.229.64.230-443-exec-19701] org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading request, ignored java.lang.IllegalStateException at org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2UpgradeHandler.java:1314) at org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2UpgradeHandler.java:1290) at org.apache.coyote.http2.Http2Parser.readConnectionPreface(Http2Parser.java:574) at org.apache.coyote.http2.Http2UpgradeHandler.init(Http2UpgradeHandler.java:243) at org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:310) at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1693) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at org.apache.tomcat.util.net.AbstractEndpoint.processSocket(AbstractEndpoint.java:946) at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteCompletionHandler.completed(SecureNio2Channel.java:115) at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteCompletionHandler.completed(SecureNio2Channel.java:108) at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736) at sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382) at sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399) at java.nio.channels.AsynchronousSocketChannel.write(AsynchronousSocketChannel.java:577) at org.apache.tomcat.util.net.SecureNio2Channel.handshakeInternal(SecureNio2Channel.java:273) at org.apache.tomcat.util.net.SecureNio2Channel.handshake(SecureNio2Channel.java:204) at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1671) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at org.apache.tomcat.util.net.AbstractEndpoint.processSocket(AbstractEndpoint.java:946) at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:98) at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:91) at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at sun.nio.ch.Invoker$2.run(Invoker.java:218) at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) This is our current Connector configuration: We have experimented with different parameters of the Http2Protocol connector to improve performance and control the leak with Http11NioProtocol connector but the exceptions are there with any of the values or removing the extra parameters. We also tried Tomcat/9.0.0.M26 and the
RE: [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection
Hello, I just realized that I didn’t provide the environment info & following are the details: Tomcat: apache-tomcat-7.0.75 IHS: HIS v8.5.5.x OS: RHEL We have IHS→mod_proxy(on IHS) → Tomcat. I know that IHS isn’t the suggested webserver to use with Tomcat but it’s in use. [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection When Tomcat is accessed through webserver url, it throws ‘500’ with the following stack on the IHS Error log: [Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2313): proxy: HTTPS: fam 2 socket created to connect to TOMCAT2 [Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2419): proxy: HTTPS: connection complete to TOMCAT-IP:PORT (TOMCAT2) [Thu Oct 00 09:20:20 2017] [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection. [Thu Oct 00 09:20:20 2017] [info] [client TOMCAT-IP] [7fa404014a60] [13789] SSL0240I: SSL Handshake Failed, Socket has been closed. Client sent fatal alert [level 2 (fatal), description 40 (handshake_failure)] [TOMCAT-IP:PORT -> IHS:PORT] [09:20:20.000967434] 0ms [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] [7fa404014a60] Handshake transcript: [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] client_version [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]gsksslDissector_8Bits [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]03 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]gsksslDissector_8Bits [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]03 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] TLSV12 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] random [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]gsksslDissector_32Bits [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]9xx [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]gsksslDissector_Opaque [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]Length: 28 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]1x 62 xx B3 1F 44 xx 8E D2 xx x7 17 xx 59 x9 x9 .b...D...)...Y.. [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]x1 91 19 08 25 xx DC xx E1 xx 20 xx %..o.9 x [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] session_id [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Length: 00 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] cipher_suites [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Length: 14 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] 0x Fx x6 00 00 xx 00 xx 00 xx 00 xx 00 xx ..V/.5 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] tls_ri_scsv,tls_fallback_scsv,tls_rsa_with_rc4_128_sha,tls_rsa_with_aes_128_cbc_sha,tls_rsa_with_aes_256_cbc_sha,tls_rsa_with_3des_ede_cbc_sha,tls_rsa_with_rc4_128_md5 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] compression_methods [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Length: 01 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] 00 . [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Extensions [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Length: 00 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Extension Count: 0 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] end handshake transcript [Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2442): proxy: HTTPS: pre_connection setup failed (500) [Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2022): proxy: HTTPS: has released connection for TOMCAT2 -- What’s done: IHS & Tomcat keystores contain required signers for proper communication. During the troubleshooting, I even added IHS server cert as a signer into Tomcat keystore and vice-versa but cannot get rid of this error. Also, tried restricting both IHS & Tomcat to use TLSv1 but no success. Has anyone ran into similar issues? Or ever tried Tomcat with IHS using mod_proxy module? Thank you, Vamsi Gali This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not
[error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection
Hello, We have IHS→mod_proxy(on IHS) → Tomcat. I know that IHS isn’t the suggested webserver to use with Tomcat but it’s in use. [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection When Tomcat is accessed through webserver url, it throws ‘500’ with the following stack on the IHS Error log: [Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2313): proxy: HTTPS: fam 2 socket created to connect to TOMCAT2 [Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2419): proxy: HTTPS: connection complete to TOMCAT-IP:PORT (TOMCAT2) [Thu Oct 00 09:20:20 2017] [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection. [Thu Oct 00 09:20:20 2017] [info] [client TOMCAT-IP] [7fa404014a60] [13789] SSL0240I: SSL Handshake Failed, Socket has been closed. Client sent fatal alert [level 2 (fatal), description 40 (handshake_failure)] [TOMCAT-IP:PORT -> IHS:PORT] [09:20:20.000967434] 0ms [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] [7fa404014a60] Handshake transcript: [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] client_version [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]gsksslDissector_8Bits [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]03 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]gsksslDissector_8Bits [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]03 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] TLSV12 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] random [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]gsksslDissector_32Bits [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]9xx [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]gsksslDissector_Opaque [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]Length: 28 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]1x 62 xx B3 1F 44 xx 8E D2 xx x7 17 xx 59 x9 x9 .b...D...)...Y.. [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP]x1 91 19 08 25 xx DC xx E1 xx 20 xx %..o.9 x [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] session_id [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Length: 00 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] cipher_suites [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Length: 14 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] 0x Fx x6 00 00 xx 00 xx 00 xx 00 xx 00 xx ..V/.5 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] tls_ri_scsv,tls_fallback_scsv,tls_rsa_with_rc4_128_sha,tls_rsa_with_aes_128_cbc_sha,tls_rsa_with_aes_256_cbc_sha,tls_rsa_with_3des_ede_cbc_sha,tls_rsa_with_rc4_128_md5 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] compression_methods [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Length: 01 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] 00 . [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Extensions [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Length: 00 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] Extension Count: 0 [Thu Oct 00 09:20:20 2017] [debug] [client TOMCAT-IP] end handshake transcript [Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2442): proxy: HTTPS: pre_connection setup failed (500) [Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2022): proxy: HTTPS: has released connection for TOMCAT2 -- What’s done: IHS & Tomcat keystores contain required signers for proper communication. During the troubleshooting, I even added IHS server cert as a signer into Tomcat keystore and vice-versa but cannot get rid of this error. Also, tried restricting both IHS & Tomcat to use TLSv1 but no success. Has anyone ran into similar issues? Or eve tried Tomcat with IHS using mod_proxy module? Thank you, Vamsi Gali Web Systems Services Ph: 214-416-3128 This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with
RE: ISAPI and IIS 10 Logging Issue
> Note that also in the course of my investigations, somewhere I found a phrase > to the effect that Mirosoft would be discouraging the future use of ISAPI > modules in IIS, and recommends some other architecture instead now. Do you remember where you saw that? Can you provide a link? - 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
Re: Tomcat unstable after updating apache http client
2017-10-05 14:12 GMT+03:00 Alex O'Ree: > I ran into a strange issue the other day. Running tomcat 7.0.81. I have a > war file with apache http client vs 4.3.3. I was having some issues with my > code in the war and experimented with updating the http client to 4.5.3. > The result was bizarre. > > Tomcat would start as normal but stop serving http requests after the first > request. > > When running in the terminal, I couldn't stop tomcat with ctrl c. I had to > force close it with task mgr. > > Is this expected? Such DoS triggered by a simple client request is a security concern, as the load is not proportional to the size of request. It'd be better to send specific details to security@, not a public list http://tomcat.apache.org/security.html 1. Take a thread dump (better: 3 of them in a sequence). What is really going on should be visible there, https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics#Common_Troubleshooting_Scenario 2. Tomcat 7.0.82 was released a few days ago. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Bug 45014 - Request and Response classes should have wrappers for use in Valves
https://bz.apache.org/bugzilla/show_bug.cgi?id=45014 Any plans/thoughts on merging Chris' mod in Tomcat 9.x branch? It is really a nice to have built in support for Valves to have wrapper classes for Request and Response. We also had a requirement to read the request payload at a valve level (to make it application independent) which essentially meant wrapping the request body to make it available to subsequent components. But, no built-in support meant we had to move the implementation at a filter level. Thanks, Amit
Re: Tomcat unstable after updating apache http client
Ill see if I can make a test war they'd reduces it to the minium. On Oct 5, 2017 8:04 AM, "Mark Thomas"wrote: On 05/10/17 12:12, Alex O'Ree wrote: > I ran into a strange issue the other day. Running tomcat 7.0.81. I have a > war file with apache http client vs 4.3.3. I was having some issues with my > code in the war and experimented with updating the http client to 4.5.3. > The result was bizarre. > > Tomcat would start as normal but stop serving http requests after the first > request. > > When running in the terminal, I couldn't stop tomcat with ctrl c. I had to > force close it with task mgr. > > Is this expected? No, not at all. Can you create a test war that demonstrates the issue? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: ISAPI and IIS 10 Logging Issue
-- On 06.09.2017 22:07, Thomas, Michael wrote: > > -- >> On 01.09.2017 22:21, Thomas, Michael wrote: >>> All, >>> >>> When using the ISAPI Handler Mapping in IIS 10 on Windows 2016, the IIS >>> logs are not identifying the URI Stem (cs-uri-stem) and URI Query >>> (cs-uri-query) as expected. For EVERY request that the handler processes >>> (e.g. .cfm), the cs-uri-stem records an entry as >>> "/jakarta/isapi_redirect.dll" and the cs-uri-query is always empty. >>> >>> Environment Details: >>> >>> * IIS 10 (Windows 2016) >>> >>> * Tomcat 8.5.11.0 >>> >>> * Java 1.8.0_131 >>> >>> * ISAPI Connector 1.2.41 >>> >>> * ColdFusion 2016 >>> >>> For comparison, we have a similar setup on another box (IIS 8.5 Windows >>> Server 2012 R2) and the logs are recording as expected. >>> >>> Any assistance would be great! >>> >> > > > > -- >> On 01.09.2017 22:37, Warnier, Andre wrote >>> Hi. >>> >>> If I understand this correctly, the difference between your two setups >>> above is at the Windows/IIS level, not at the tomcat/ISAPI-redirector level. >>> >>> This may be naive, but isn't this a question then for the Windows/IIS >>> people ? >> > > -- >> On 05.09.2017 22:42, Thomas, Michael wrote: >> Andre, you're right. Perhaps this is a good question for the Windows folks. >> I guess I was hoping that someone in this community has seen this issue >> before and had a recommended solution. >> >> It is really challenging to not know what traffic your IIS Web Server is >> actually seeing. There are of course other avenues (e.g. firewall logs, >> siem logs, etc) but the IIS logs are native to the boxes themselves and much >> easier to analyze. I was curious if the ISAPI Connector returned a specific >> URL back to IIS and it could be tweaked. Not sure if IIS is expecting a >> response in a certain format, etc. >> >> Is there documentation that I can look at for what the ISAPI module should >> return to IIS? Anyone have any insight into that pipeline? > > > > -- >> On 06.09.2017 00:41, Warnier, Andre wrote >> >> First, about your last question above : I don't know, and I guess that the >> right people for that on this list would be Rainer or Mladen. >> >> But second, I believe that the terminology you are using above is a bit >> confusing, from the point of view of the logic of the thing, particularly >> when you mention "what the ISAPI module should return to IIS". >> >> IIS is the front-end, and it gets the client HTTP request first (URL, >> headers and all). >> So it /has/ all the information needed to log whatever, should it choose to >> do so (*). >> >> In a second step, IIS examines the request URL and, maybe with the help of >> the isapi_redirector, it determines that to properly answer this request, it >> should not use its own internal machinery, but it should delegate this to >> the isapi_redirector module. >> What the isapi_redirector module does with the request, is none of IIS's >> business, so to speak. The only thing which IIS expects back from the >> isapi_redirector module, is either a HTTP succesful response, or some error >> code. >> So this is the only additional information for which IIS might be waiting, >> for logging the request (e.g. the size of the response, and/or the time >> needed to generate it). >> >> That the isapi_redirector module, to generate this HTTP response, uses a >> back-channel with a back-end tomcat, is unknown to IIS, and it does not >> care. From the IIS point of view, isapi_redirector might as well be using >> black magic to generate that response internally, without ever talking to >> anyone else. >> >> (*) but in your case, it doesn't do it, or does it differently than IIS 8.5 >> or whatever earlier version did, although all the rest of the machinery did >> not change. So /that's/ the mystery to solve. Maybe MS changed the rules of >> the game (the ISAPI interface) somehow for IIS 10, and an ISAPI module is >> now >supposed to do something additional, to get things properly logged, >> that the ISAPI-redirector module does not do (yet). >> But I think that you are still more likely to get that kind of information >> on an IIS-oriented forum, that on this tomcat forum. >> >> >> I would ask first for example, for any IIS-10 specific changes in the >> logging of requests, maybe in conjunction with the usage of ISAPI filters in >> general. >> (Maybe it is just your log formatting that does not invoke the right >> items of information ?) > > -- > Andre, thank you for the detailed explanation. That helps me
Re: Tomcat unstable after updating apache http client
On 05/10/17 12:12, Alex O'Ree wrote: > I ran into a strange issue the other day. Running tomcat 7.0.81. I have a > war file with apache http client vs 4.3.3. I was having some issues with my > code in the war and experimented with updating the http client to 4.5.3. > The result was bizarre. > > Tomcat would start as normal but stop serving http requests after the first > request. > > When running in the terminal, I couldn't stop tomcat with ctrl c. I had to > force close it with task mgr. > > Is this expected? No, not at all. Can you create a test war that demonstrates the issue? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat unstable after updating apache http client
I ran into a strange issue the other day. Running tomcat 7.0.81. I have a war file with apache http client vs 4.3.3. I was having some issues with my code in the war and experimented with updating the http client to 4.5.3. The result was bizarre. Tomcat would start as normal but stop serving http requests after the first request. When running in the terminal, I couldn't stop tomcat with ctrl c. I had to force close it with task mgr. Is this expected?
Re: encodeURL, jsessionid and mod_rewrite ?
On 4 October 2017 23:31:36 BST, Laurent Perezwrote: >Thanks for the replies. The jsessionid/cookie tracking mode is not >really >part of the problem, sorry about that. > >Obviously I'm thinking about renaming the war but the rewriting is >really >used, for example seo friendly urls like /bar/steps/1 internally >rewrite to >/foo/somesubmodule/steps.jsp?step=1 and the system really can't expose >/somesubmodule/steps.jsp?step=1 as public urls, it messes with google >analytics stats or bookmarked urls. Rewrites are not generally problematic. It is changing the context path that causes all the problems. Renaming foo.war to bar.war (or equivalent for you config) should be sufficient. Mark > >As last resort I could move the apache RewriteRules to tuckey >urlrewriter >under the war itself and just keep the ProxyPasses under apache. >Configuration & docs would be in a sole space. > >I know that just because I /can/ do nasty rewriting stuff at the >response >wrapper level I may not want to do it. The replies were useful ;) > >regards > > >On Wed, Oct 4, 2017 at 9:58 AM, André Warnier (tomcat) >wrote: > >> On 04.10.2017 07:40, Peter Kreuser wrote: >> >>> >>> Peter Kreuser >>> >>> Am 04.10.2017 um 02:44 schrieb Christopher Schultz < ch...@christopherschultz.net>: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Laurant, On 10/3/17 5:17 PM, Laurent Perez wrote: > I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A > "foo" war is deployed at /foo context path under tomcat. The /foo > path is not public, apache has a rewrite rule defined as : /bar/* > rewrites internally to /foo/*. > > I'm using jstl and its for every url in >my > jsps to gain the ;jsessionid from encodeURL whenever jsessionid > cookie is not yet set (1st requests) > > >>> adding to Christopher, accepting the jsessionid from the Url is a >bad >>> security risk (Session fixation). So you should disable that by >accepting >>> the session only via COOKIE via >>> >>> COOKIE > >>> then at least this rewriting problem is gone. >>> >>> Peter >>> >>> >> Well, a cookie can also be path-specific. Which is only *one* of >these >> issues which we are talking about, when we say "don't". >> >> >> >> >> - >> 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