Re: Tomcat won't use TLSv1.2
Am 05.03.20 um 23:10 schrieb rugman66 .: > On Thu, Mar 5, 2020 at 10:44 AM i...@flyingfischer.ch > wrote: >> Try SSLProtocol="TLSv1.2" (mind the case) instead of sslProtocol="-all >> +TLSv1.2". >> >> Had this issue too. The connector parameters for SSL are a huge mess and >> have been changed constantly. >> >> Best >> Markus >> >> Am 05.03.20 um 19:30 schrieb rugman66 .: >>> Hello, >>> >>> >>> >>> I have both Apache and Tomcat running on the same RHEL. I have successfully >>> configured Apache to use OpenSSL TLSv1.2, but I cannot get Tomcat to use >>> TLSv1.2. Tomcat for some reason >>> >>> will only use TLV 1.0, and that is no good. No matter what parameter I set >>> in the server.xml sslProtocol directive it won’t change. Seems like it’s >>> getting that directive somewhere else but I can't locate. >>> >>> >>> >>> >> >>> port="8443" >>> >>> scheme="https" >>> >>> secure="true" >>> >>> protocol="org.apache.coyote.http11.Http11AprProtocol" >>> >>> SSLEnabled="true" >>> >>> SSLCertificateFile="/auto/englearn-web/ssl_certificate/server.cer" >>> >>> >>> SSLCertificateChainFile="/auto/englearn-web/ssl_certificate/chain.cer" >>> >>> >>> SSLCertificateKeyFile="/auto/englearn-web/ssl_certificate/server.key" >>> >>> SSLCipherSuite="RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW" >>> >>> SSLHonorCipherOrder="true" >>> >>> maxThreads="150" >>> >>> clientAuth="false" >>> >>> sslProtocol="-all +TLSv1.2" >>> >>> /> >>> >>> >>> >>> OpenSSL 1.0.2d >>> >>> Tomcat 7.0.39 (I know it’s old, but it's what I have to work with at this >>> time) >>> >>> >>> Thank you for any insight. >>> >>> -John >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > Sorry, that last reply sent before I was done for some reason. > > Thanks Markus, > > One final issue. One version of the URL is still using TLS 1.0, and I > need to disable or force it to TLS v1.2 and can't find where to do > that. > > https://server.domain.com (TLSv 1.2) > https://server.domain.com/foo (Apache proxy TLSv1.2 > https://server.domain.com:8443 (TLS 1.0) > > Thanks > -John > These three URLs do use two different connectors: on Port 443 and on Port 8443. Make sure you have configured both connectors accordingly. Best Markus - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.100 AJP connector with mod_jk on another host
Hello, > If you don't set secretRequired="false" properly then at start time Tomcat > will complain if there is no specified "secret" attribute. > If it doesn't complain then most probably you are testing again with the > wrong server.xml or old version of Tomcat. the issue seems to be that mod_jk no longer works without a password with tomcat7. So you need to set a password on both sites, and than everything works again. server.xml: workers.properties of mod_jk worker.tomcat-06.secret=verysecure If I do _not_ set a password I'm getting a 403 no matter what I do. Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Aw: Re: Fix for the Ghostcat vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jürgen, On 3/5/20 01:59, "Jürgen Göres" wrote: > > Hi, > >>> If it is, what is the recommended mitigation? We consider using >>> the "secret" feature (the filtering by request attributes is >>> infeasible for us), but that would be a bit of effort and we >>> are in a hurry. >>> >> >> We're in the same position as you. External web servers talking >> to Tomcat servers on other boxes via AJP. >> >> We've looked at a few options, none of which seemed great: >> >> * The current stable version of Apache doesn't support the >> 'secret' attribute for AJP connectors in mod_proxy. > > we will use the "secret" approach. Since we use mod_jk which > supports it, this will offer the least trouble when deploying in > customer environments. We will generate a random secret for each > tomcat instance. Uhh. That will be a serious management headache. > Since our apps already register in our service registry,we can > just add the secret there. Our Apache HTTPD resp. a little tooling > we wrote for it that generates the Apache config from information > in the registry and can pick up the secret from there as well. Interesting. So less of a headache. Still. I would highly recommend that the entire world migrate away from AJP. It's just a magic protocol which nobody understands and does not need to exist anymore. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5hlowACgkQHPApP6U8 pFhf1A/9HxCzPy1J8oxwC2au3VJowVbt6xU5A4Z4gEbnXjQDh2D6hYLMwuM2pE7x iYBiOCLuCa/6Iw2VI8LntFUmSK0TAVussLigylMFNivdvYtXEIe+fVt3ODWIOfxb fddCQI2ey3fUKUtIAeyd6lHhJqJ8tXdiVfzOz0sy1XgvV/NTDF3m9EaZE5ftnAz8 KQrmeLPe6JVjj2tenCANfzymz5mMnwqtH7KrjCBSR3rLciyae4i/j/T1kq1tFdBp dHzxXAYpQVH1AmNR7bpmHpe/FKnaFFlfG1Ri0zG9rJXywbxvyW/DcCmlIWfa0Gfp 2P5a/CaDr4MKR5hOtVshHP49cbnoKmNijEqA4XtkINsSDeZv0oIZDnfrGX02pGAU 3Ijv90lNT+5P3UEY02jurxb4uF3ejlnjc4aoSjDvnTZ2IaHHqaZ0kwov4FwEtLCX BCo2cl/DIN0ywbvKQ2rHj4mgnDCRS++WlL2bXoRImdUHMiljAV5Ji2xqPRNZol0R fFpmJBPLjswxUtUClcXM9PzUdNDwqhI0GNJsykpxEDepnMoLfXzQsC0dif1F/IHb doFqNBHvHHQg4z8EET+GYT5LyQghojq5zjRA9CDuBQ96Y6x8pCtwyJo4hycE1/xg fdvgzat70W7GO1PoxpZscx4FSWToQeoGVmTQXx+poEpOtFAIb7A= =dQB6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fix for the Ghostcat vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dave, On 3/5/20 06:21, Dave Ford wrote: > On Wed, 2020-03-04 at 13:19 -0500, Christopher Schultz wrote: >> >>> We're in the same position as you. External web servers >>> talking to Tomcat servers on other boxes via AJP. >> >> Are those connections properly secured? > > That's not a tremendously helpful question. Which connections are > you talking about? How do you propose 'securing' an AJP > connection? There are many ways, the most obvious being mutually-authenticated TLS using something like stunnel. Or do you usually just allow plain-text protocol communication over open networks? >> If your connections are properly-secured, simply set >> secretRequired="false" and move on. If they aren't >> properly-secured, then you need to fix that (and you had to fix >> that before this recent announcement). > > Can you point the ill-informed amongst us to any helpful resources > you may have that describe what you mean by 'properly secured'? Imagine that you are using HTTP as a proxying protocol and that the origin server takes special HTTP headers and converts those into e.g. client connection information, authentication details (e.g. username + "yep they are authenticated! trust me!), and request attributes and just goes ahead and trusts them. Now, how are you going to secure that connection to make sure that an adversary doesn't inject Bad Stuff into your origin server? There is nothing special about AJP that makes it any different in terms of securing, except that there is no ajps:// protocol. If you want ajps:// you have to tunnel ajp:// through something else, which is why I recommend stunnel. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5hliAACgkQHPApP6U8 pFibMw//X4OdYQFSeh+BM9F+1tuErCHYW4TJmhL+Q1TrxZQfSWVS/IOHm0zjK/Pj shP4RfCSlbEsvo/Ia82l4nqm2dHqHiVkty2OwLlbtoyr7B50uh5siZkRpuQ8tonY WCrq5N37R9ean3mP9kNnm3gw7UJPudy2iSS7Qv37k4QaGLNqekUGXEALSX0TubE8 wGMfNwcAKftibfEYfbJbgdKPdaHH0qnB4m051tK0LoJzdbf/zNLJsYglySD2fO+q lO9eKpvnav/OhJoQtWmIiJxWPnC4WqvtcbYWBSXGjxDDO+36vpV5pyCgaL54XmbO 7aVzWJBJ+k20y+61lL55abl39tNOg0bGJgW9WNx8dOsZezfsaBuVgsMIVrQx8wmm GVlZJsxttVFjUvBuVtSW3RW5pZ44tW1JiVg1gFMYCYVqZ/8K4vDtKAMTFGo4Kj+K O4+Y2PSUutV2o6c2ejYzwn22BdvPRpOWVjApqTdI3Sxt6tQELIhKxuo9QCuOA3w0 332hj37LSX7EeT9D1lknHELrHToiOttr+Rj+4uYtmqqI1JPTJZFKyZIxh5C/pVAn vfySiyK9c5U7mSrJsKKYnyaZY1L3CXv4vUkSPiJTlwPOSD8qHblV6rvj/BQ9+U3t 1FI/TqA8/rukHGxZ7ncnoonQEZmScMWpTTOPcmgunBCGHBJJnnE= =qFiH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat won't use TLSv1.2
On Thu, Mar 5, 2020 at 10:44 AM i...@flyingfischer.ch wrote: > > Try SSLProtocol="TLSv1.2" (mind the case) instead of sslProtocol="-all > +TLSv1.2". > > Had this issue too. The connector parameters for SSL are a huge mess and > have been changed constantly. > > Best > Markus > > Am 05.03.20 um 19:30 schrieb rugman66 .: > > Hello, > > > > > > > > I have both Apache and Tomcat running on the same RHEL. I have successfully > > configured Apache to use OpenSSL TLSv1.2, but I cannot get Tomcat to use > > TLSv1.2. Tomcat for some reason > > > > will only use TLV 1.0, and that is no good. No matter what parameter I set > > in the server.xml sslProtocol directive it won’t change. Seems like it’s > > getting that directive somewhere else but I can't locate. > > > > > > > > > > > port="8443" > > > > scheme="https" > > > > secure="true" > > > > protocol="org.apache.coyote.http11.Http11AprProtocol" > > > > SSLEnabled="true" > > > > SSLCertificateFile="/auto/englearn-web/ssl_certificate/server.cer" > > > > > > SSLCertificateChainFile="/auto/englearn-web/ssl_certificate/chain.cer" > > > > > > SSLCertificateKeyFile="/auto/englearn-web/ssl_certificate/server.key" > > > > SSLCipherSuite="RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW" > > > > SSLHonorCipherOrder="true" > > > > maxThreads="150" > > > > clientAuth="false" > > > > sslProtocol="-all +TLSv1.2" > > > > /> > > > > > > > > OpenSSL 1.0.2d > > > > Tomcat 7.0.39 (I know it’s old, but it's what I have to work with at this > > time) > > > > > > Thank you for any insight. > > > > -John > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > Sorry, that last reply sent before I was done for some reason. Thanks Markus, One final issue. One version of the URL is still using TLS 1.0, and I need to disable or force it to TLS v1.2 and can't find where to do that. https://server.domain.com (TLSv 1.2) https://server.domain.com/foo (Apache proxy TLSv1.2 https://server.domain.com:8443 (TLS 1.0) Thanks -John - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat won't use TLSv1.2
Thanks Markus. Now a different issue is occurring. One specific version of the URL is using TLS 1.0. https://server.domain.com On Thu, Mar 5, 2020 at 10:44 AM i...@flyingfischer.ch wrote: > Try SSLProtocol="TLSv1.2" (mind the case) instead of sslProtocol="-all > +TLSv1.2". > > Had this issue too. The connector parameters for SSL are a huge mess and > have been changed constantly. > > Best > Markus > > Am 05.03.20 um 19:30 schrieb rugman66 .: > > Hello, > > > > > > > > I have both Apache and Tomcat running on the same RHEL. I have > successfully > > configured Apache to use OpenSSL TLSv1.2, but I cannot get Tomcat to use > > TLSv1.2. Tomcat for some reason > > > > will only use TLV 1.0, and that is no good. No matter what parameter I > set > > in the server.xml sslProtocol directive it won’t change. Seems like it’s > > getting that directive somewhere else but I can't locate. > > > > > > > > > > > port="8443" > > > > scheme="https" > > > > secure="true" > > > > protocol="org.apache.coyote.http11.Http11AprProtocol" > > > > SSLEnabled="true" > > > > > SSLCertificateFile="/auto/englearn-web/ssl_certificate/server.cer" > > > > > > SSLCertificateChainFile="/auto/englearn-web/ssl_certificate/chain.cer" > > > > > > SSLCertificateKeyFile="/auto/englearn-web/ssl_certificate/server.key" > > > > SSLCipherSuite="RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW" > > > > SSLHonorCipherOrder="true" > > > > maxThreads="150" > > > > clientAuth="false" > > > > sslProtocol="-all +TLSv1.2" > > > > /> > > > > > > > > OpenSSL 1.0.2d > > > > Tomcat 7.0.39 (I know it’s old, but it's what I have to work with at this > > time) > > > > > > Thank you for any insight. > > > > -John > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31
Thanks Mark, Two connector configs works. Any ideas, on why the behavior if different for ISAPI and mod_jk modules? -Original Message- From: Mark H. Wood Sent: Thursday, March 5, 2020 10:28 PM To: users@tomcat.apache.org Subject: Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31 On Thu, Mar 05, 2020 at 01:52:57PM +, Piyush Kumar Nayak wrote: > Is there a way to get Tomcat's AJP connector to bind to both IPv4 and IPv6 > loopback addresses. > > By default, it seems that Tomcat binds to IPv4 loopback Default > connector config : > packetSize="65535" secret="xxx" tomcatAuthentication="false"/> > > netstat -ano | findstr 8014 > TCP 127.0.0.1:8014 0.0.0.0:0 LISTENING 8616 TCP 127.0.0.1:8014 > 127.0.0.1:57510 ESTABLISHED 8616 TCP 127.0.0.1:57510 127.0.0.1:8014 > ESTABLISHED 11800 > > Introducing the address attribute like so : > redirectPort="8447" packetSize="65535" secret="xxx" > tomcatAuthentication="false"/> binds it to IPv6 loopback TCP > [::1]:8014 [::]:0 LISTENING 8616 TCP [::1]:8014 [::1]:57522 > ESTABLISHED 8616 TCP [::1]:57522 [::1]:8014 ESTABLISHED 6564 > > Is there a way to make it bind to both the loopbacks. The problem we are > facing is our Tomcat installations can have connector configured with IIS or > Apache HTTPD. > Apache connector, by default seems to make a socket connection using the > address ::1 (IPv6 loop back address), whereas IIS connector tries to bind to > the IPv4 loopback. Two things I would try: 1. Two connectors, one with address='::1' and the other with address='127.0.0.1', both with port='8014'. 2. Configure the other end explicitly: tell HTTPD and IIS which address to use, and then configure your AJP Connector to match. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat won't use TLSv1.2
Try SSLProtocol="TLSv1.2" (mind the case) instead of sslProtocol="-all +TLSv1.2". Had this issue too. The connector parameters for SSL are a huge mess and have been changed constantly. Best Markus Am 05.03.20 um 19:30 schrieb rugman66 .: > Hello, > > > > I have both Apache and Tomcat running on the same RHEL. I have successfully > configured Apache to use OpenSSL TLSv1.2, but I cannot get Tomcat to use > TLSv1.2. Tomcat for some reason > > will only use TLV 1.0, and that is no good. No matter what parameter I set > in the server.xml sslProtocol directive it won’t change. Seems like it’s > getting that directive somewhere else but I can't locate. > > > > > port="8443" > > scheme="https" > > secure="true" > > protocol="org.apache.coyote.http11.Http11AprProtocol" > > SSLEnabled="true" > > SSLCertificateFile="/auto/englearn-web/ssl_certificate/server.cer" > > > SSLCertificateChainFile="/auto/englearn-web/ssl_certificate/chain.cer" > > > SSLCertificateKeyFile="/auto/englearn-web/ssl_certificate/server.key" > > SSLCipherSuite="RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW" > > SSLHonorCipherOrder="true" > > maxThreads="150" > > clientAuth="false" > > sslProtocol="-all +TLSv1.2" > > /> > > > > OpenSSL 1.0.2d > > Tomcat 7.0.39 (I know it’s old, but it's what I have to work with at this > time) > > > Thank you for any insight. > > -John > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat won't use TLSv1.2
Hello, I have both Apache and Tomcat running on the same RHEL. I have successfully configured Apache to use OpenSSL TLSv1.2, but I cannot get Tomcat to use TLSv1.2. Tomcat for some reason will only use TLV 1.0, and that is no good. No matter what parameter I set in the server.xml sslProtocol directive it won’t change. Seems like it’s getting that directive somewhere else but I can't locate. OpenSSL 1.0.2d Tomcat 7.0.39 (I know it’s old, but it's what I have to work with at this time) Thank you for any insight. -John
Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31
On Thu, Mar 05, 2020 at 01:52:57PM +, Piyush Kumar Nayak wrote: > Is there a way to get Tomcat's AJP connector to bind to both IPv4 and IPv6 > loopback addresses. > > By default, it seems that Tomcat binds to IPv4 loopback > Default connector config : > packetSize="65535" secret="xxx" tomcatAuthentication="false"/> > > netstat -ano | findstr 8014 > TCP 127.0.0.1:8014 0.0.0.0:0 LISTENING 8616 > TCP 127.0.0.1:8014 127.0.0.1:57510 ESTABLISHED 8616 > TCP 127.0.0.1:57510 127.0.0.1:8014 ESTABLISHED 11800 > > Introducing the address attribute like so : > packetSize="65535" secret="xxx" tomcatAuthentication="false"/> > binds it to IPv6 loopback > TCP [::1]:8014 [::]:0 LISTENING 8616 > TCP [::1]:8014 [::1]:57522 ESTABLISHED 8616 > TCP [::1]:57522 [::1]:8014 ESTABLISHED 6564 > > Is there a way to make it bind to both the loopbacks. The problem we are > facing is our Tomcat installations can have connector configured with IIS or > Apache HTTPD. > Apache connector, by default seems to make a socket connection using the > address ::1 (IPv6 loop back address), whereas IIS connector tries to bind to > the IPv4 loopback. Two things I would try: 1. Two connectors, one with address='::1' and the other with address='127.0.0.1', both with port='8014'. 2. Configure the other end explicitly: tell HTTPD and IIS which address to use, and then configure your AJP Connector to match. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: g! shell 255 character limit
It's a development environment. I used a modified WAR file which allows access to the gogo (g!) shell. I have since decided to use a different method that doesn't require g!. On Thu, Mar 5, 2020 at 12:26 AM Martin Grigorov wrote: > Hi, > > On Wed, Mar 4, 2020 at 5:58 PM Iowa Research > wrote: > > > I am encountering a 255 character limit in the g! shell when running > Tomcat > > 9.0.31. I do not see the issue in Tomcat 7. I have searched for solutions > > to this issue but have been unsuccessful. Any help is greatly > appreciated. > > > > Could you please provide more information ? > I have no idea what is g! shell and how it uses Tomcat. >
Re: Tomcat 9 : relaxedQueryChars
On Wed, Mar 4, 2020 at 4:46 PM Mark Thomas wrote:
> On 04/03/2020 20:20, Robert Hicks wrote:
> > We are getting the following over and over in our catalina.out file:
> >
> > java.lang.IllegalArgumentException: Invalid character found in the
> request
> > target. The valid characters are defined in RFC 7230 and RFC 3986
>
> Do you know what URIs are triggering those?
>
> We recently improved the HTTP header logging to report invalid
> characters in %nn form. We could add that to this exception message so
> you have some chance of figuring out what the issue is.
>
> > Our server.xml has the following copied from an online search I think:
> >
> > relaxedQueryChars="[]|{}^"
>
> That is all of the allowed characters.
>
> It is an attribute value so you'll need to encode at least " and <. Wjat
> you have above is fine.
>
> > I found something else that said the following might also help in
> > catalina.properties:
> >
> > org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true
>
> I'd be very careful using that.
>
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Thanks Mark, we are going to figure out when we can up the logging level to
capture it and move from there.
--
Bob
Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31
Hi, Check this thread: https://lists.apache.org/thread.html/r1f83f0c731a8737fdf4dad13ae402acd2fdc1ab1a86605af5b496a5f%40%3Cusers.tomcat.apache.org%3E On Thu, Mar 5, 2020 at 3:53 PM Piyush Kumar Nayak wrote: > > Is there a way to get Tomcat's AJP connector to bind to both IPv4 and IPv6 > loopback addresses. > > By default, it seems that Tomcat binds to IPv4 loopback > Default connector config : > packetSize="65535" secret="xxx" tomcatAuthentication="false"/> > > netstat -ano | findstr 8014 > TCP 127.0.0.1:8014 0.0.0.0:0 LISTENING 8616 > TCP 127.0.0.1:8014 127.0.0.1:57510 ESTABLISHED 8616 > TCP 127.0.0.1:57510 127.0.0.1:8014 ESTABLISHED 11800 > > Introducing the address attribute like so : > redirectPort="8447" packetSize="65535" secret="xxx" > tomcatAuthentication="false"/> > binds it to IPv6 loopback > TCP [::1]:8014 [::]:0 LISTENING 8616 > TCP [::1]:8014 [::1]:57522 ESTABLISHED 8616 > TCP [::1]:57522 [::1]:8014 ESTABLISHED 6564 > > Is there a way to make it bind to both the loopbacks. The problem we are > facing is our Tomcat installations can have connector configured with IIS > or Apache HTTPD. > Apache connector, by default seems to make a socket connection using the > address ::1 (IPv6 loop back address), whereas IIS connector tries to bind > to the IPv4 loopback. > > Thanks, > Piyush. >
bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31
Is there a way to get Tomcat's AJP connector to bind to both IPv4 and IPv6 loopback addresses. By default, it seems that Tomcat binds to IPv4 loopback Default connector config : netstat -ano | findstr 8014 TCP 127.0.0.1:8014 0.0.0.0:0 LISTENING 8616 TCP 127.0.0.1:8014 127.0.0.1:57510 ESTABLISHED 8616 TCP 127.0.0.1:57510 127.0.0.1:8014 ESTABLISHED 11800 Introducing the address attribute like so : binds it to IPv6 loopback TCP [::1]:8014 [::]:0 LISTENING 8616 TCP [::1]:8014 [::1]:57522 ESTABLISHED 8616 TCP [::1]:57522 [::1]:8014 ESTABLISHED 6564 Is there a way to make it bind to both the loopbacks. The problem we are facing is our Tomcat installations can have connector configured with IIS or Apache HTTPD. Apache connector, by default seems to make a socket connection using the address ::1 (IPv6 loop back address), whereas IIS connector tries to bind to the IPv4 loopback. Thanks, Piyush.
Re: Fix for the Ghostcat vulnerability
Hi Dave, On Thu, Mar 5, 2020 at 1:22 PM Dave Ford wrote: > On Wed, 2020-03-04 at 13:19 -0500, Christopher Schultz wrote: > > > > > We're in the same position as you. External web servers talking > > > to Tomcat servers on other boxes via AJP. > > > > Are those connections properly secured? > > That's not a tremendously helpful question. Which connections are you > talking about? How do you propose 'securing' an AJP connection? > > > If your connections are properly-secured, simply set > > secretRequired="false" and move on. If they aren't properly-secured, > > then you need to fix that (and you had to fix that before this recent > > announcement). > > Can you point the ill-informed amongst us to any helpful resources you > may have that describe what you mean by 'properly secured'? > Properly secured would mean that AJP port is visible and usable only by its supposed users, i.e. the proxy in front of it. You should apply standard network security policies as: 1) bind AJP port only to the network interfaces where it is supposed to be found If the proxy is running on the same host then bind AJP only on localhost. If the proxy is on a different machine then bind AJP only on a network interface used for the internal network 1.1) you can create an internal sub-network just for the proxy and Tomcat/AJP 2) apply firewall rules so that only the proxy machine can reach and use the AJP port 3) use the "secret" configuration setting so that only the proxy could communicate with AJP > > Regards > Dave > >
Re: Fix for the Ghostcat vulnerability
On Wed, 2020-03-04 at 13:19 -0500, Christopher Schultz wrote: > > > We're in the same position as you. External web servers talking > > to Tomcat servers on other boxes via AJP. > > Are those connections properly secured? That's not a tremendously helpful question. Which connections are you talking about? How do you propose 'securing' an AJP connection? > If your connections are properly-secured, simply set > secretRequired="false" and move on. If they aren't properly-secured, > then you need to fix that (and you had to fix that before this recent > announcement). Can you point the ill-informed amongst us to any helpful resources you may have that describe what you mean by 'properly secured'? Regards Dave
Re: Aw: Re: Fix for CVE-2020-1938
On 05/03/2020 07:12, "Jürgen Göres" wrote: >>> My first question is: what value do I need to set in the "address" >>> attribute to indicate that I want the connector to listen on ALL interfaces >>> (for IPv4 AND IPv6)? Maybe that should be documented. :-) >> >> It will vary by system. Some systems can't listen on both IPv4 and IPv6 >> with a single socker. Usually either "::" or "0.0.0.0" will have the >> desired result. > > That is a bit of a problem for us. In the environments we support (Win and > Linux), from my observation the connectors would successfully bind to both > IPv4 and IPv6 addresses. Since we have customers that use either IPv4, IPv6, > or both and often have multiple interfaces on their machines, we cannot know > which address/interface (or even which IP version) to bind to. And up to now, > we didn't have to worry about it. > Now our installation routine would somehow need to find out whether it should > put a "::" or a "0.0.0.0" in the "address" attribute. What was "zero conf" > for us so far now suddently becomes a new source for problems (=customer > calls). > Is there no way to optionally configure the old binding behaviour for the AJP > connector? Let me re-phrase. Usually, for the NIO and NIO2 Connectors, specifying "::" or "0.0.0.0" will result in the server socket binding to all IPv4 and IPv6 addresses. For APR/Native, "0.0.0.0" will be IPv4 only. "::" will be IPv4 and IPv6. If the underlying OS does not support "dual stack" networking (most do), "0.0.0.0" will result in listing on all IPv4 addresses and "::" will result in listening on all IPv6 addresses. For your use case "::" looks like the best default. Most of this is in the docs for the HTTP Connector. I'll add the same text to the AJP Connector. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: g! shell 255 character limit
Hi, On Wed, Mar 4, 2020 at 5:58 PM Iowa Research wrote: > I am encountering a 255 character limit in the g! shell when running Tomcat > 9.0.31. I do not see the issue in Tomcat 7. I have searched for solutions > to this issue but have been unsuccessful. Any help is greatly appreciated. > Could you please provide more information ? I have no idea what is g! shell and how it uses Tomcat.
Re: Aw: Re: Fix for CVE-2020-1938
Am 05.03.2020 08:12, schrieb Jürgen Göres: Ghostcat is the name of a malware strain that has been around since at least October last year. When referencing vulnerabilities it is best to stick to the CVE reference since they should be unique (and if something goes wrong and they aren't there are procedures to get them re-issued so they are). we are using Tomcat 9.0.x and 8.5.x in our stack. We make use of the AJP protocol since we use Apache HTTPD as reverse proxy and found it to be mostly hazzle-free over the last few years, so we would like to continue using it. Since the HTTPD and the Tomcats are in general not on the same nodes, the AJP connector has to listen on all interfaces. My first question is: what value do I need to set in the "address" attribute to indicate that I want the connector to listen on ALL interfaces (for IPv4 AND IPv6)? Maybe that should be documented. :-) It will vary by system. Some systems can't listen on both IPv4 and IPv6 with a single socker. Usually either "::" or "0.0.0.0" will have the desired result. That is a bit of a problem for us. In the environments we support (Win and Linux), from my observation the connectors would successfully bind to both IPv4 and IPv6 addresses. Since we have customers that use either IPv4, IPv6, or both and often have multiple interfaces on their machines, we cannot know which address/interface (or even which IP version) to bind to. And up to now, we didn't have to worry about it. Now our installation routine would somehow need to find out whether it should put a "::" or a "0.0.0.0" in the "address" attribute. What was "zero conf" for us so far now suddently becomes a new source for problems (=customer calls). Is there no way to optionally configure the old binding behaviour for the AJP connector? Have you tried using either of the given configurations on your system? I believe Thomas wanted to point out, that there are systems, that can't bind to both, but that depends on your system, so we can't tell you, if it works for you. In my experience both of the configs will work and bind to both types IPv4 and IPv6. Felix So the question is: is the root cause actually fixed? Yes. Great, thx. :-) The very nature of the AJP protocol is such that clients have to be trusted. Tomcat trusts the "real" client IP address provided. That could be used for access control. Tomcat may be configured to trust the authenticated user name provided. That almost certainly will then be used for access control. So far, we had instructions for our customers to not expose the AJP ports (or any other internal ports of other components in our stack). However, I am pretty sure that there are installations out there where these ports are exposed (hopefully only on the intranet). In any case, we will update to the latest Tomcat version (but need to find a way to solve the "to which interface should we bind" problem without too much hazzle for customers), and in addition will also try to use the "secret" approach to secure access to the AJP connectors, so that even those customers that ignored the security guidelines will not be affected by other possible attacks over the AJP protocol. If it is, what is the recommended mitigation? We consider using the "secret" feature (the filtering by request attributes is infeasible for us), but that would be a bit of effort and we are in a hurry. It would be unusual for an application to be using request attributes directly. These have to be explicitly set in the reverse proxy and are normally used for the reverse proxy to pass information to Tomcat about the client etc. I was under the naive assumptions that "request attributes" meant "HTTP request attributes". ;-) If I understand you right here we are talking about attributes used in the AJP protocol to convey info between reverse proxy and Tomcat. Like info about the true client IP address (i.e., an AJP equivalent to HTTP's X-Forwarded-For header). - setting up a dedicated subnet for reverse proxy to Tomcat communication; - configuring a firewall on the Tomcat box to only accept connections to the AJP port from specific hosts That is what we advise our customers to do. For any network configuration you can configure a shared secret for the reverse proxy workers and the AJP connector. And since this is closest to "zero config" we can get, this is what we will do on perspective. Regards JG - 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 7.0.100 AJP connector with mod_jk on another host
On Thu, Mar 5, 2020 at 10:05 AM Thomas Glanzmann wrote: > Hello Martin, > > > > This should be: secretRequired="false". > > > This attribute has been renamed recently. > > I just looked at my notes, and I tried that already yesterday night. > Still facing the same problem with 403. Might it be possible that I need > to use a secret in order to access ajp from mod_jk? > If you don't set secretRequired="false" properly then at start time Tomcat will complain if there is no specified "secret" attribute. If it doesn't complain then most probably you are testing again with the wrong server.xml or old version of Tomcat. > > Cheers, > Thomas > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat 9.0.31 Invalid character found in the request target
Hi,
On Wed, Mar 4, 2020 at 11:53 PM Bhavesh Mistry
wrote:
> Hi Tomcat Team,
>
> When there is invalid characters, it return error message with
> stacktrace as shown below. 1) is there any way to costmize error
> message ? if yes, please let me know.
>
> 2) Is there any way to spress stack-trace being shown on 400 bad request ?
>
> 3) Based on Accept header (application/json), can JSON error be
> constructed instead of html since client request application/json ?
>
This error is reported by ErrorReportValve.
You can disable it and/or replace it with one that reports the way you need
it.
Martin
> Thank you for help in advance.
>
> Thanks,
>
> Bhavesh
>
> Request :
> ===
> GET
> /API/?where=type*!*%3d1%20UNION%20SELECT%20version(),null,null,null=true=0=10
> HTTP/1.1
> Host: 10.192.58.135
> Connection: close*Accept: application/json*
> Sec-Fetch-Dest: empty
> X-Requested-With: XMLHttpRequest
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122
> Safari/537.36
> Sec-Fetch-Site: same-origin
> Sec-Fetch-Mode: cors
> Accept-Encoding: gzip, deflate
> Accept-Language: en-US,en;q=0.9
>
>
>
>
>
>
>
> Response :
> =
> HTTP/1.1 400
> Content-Type: text/html;charset=utf-8
> Content-Language: en
> Content-Length: 1988
> Date: Sun, 01 Mar 2020 06:09:41 GMT
> Connection: close
>
> HTTP Status 400 – Bad
> Requestbody
> {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
> {color:white;background-color:#525D76;} h1 {font-size:22px;} h2
> {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
> {color:black;} .line
>
> {height:1px;background-color:#525D76;border:none;}HTTP
> Status 400 – Bad RequestType
> Exception ReportMessage Invalid character found in the
> request target. The valid characters are defined in RFC 7230 and RFC
> 3986Description The server cannot or will not process
> the request due to something that is perceived to be a client error
> (e.g., malformed request syntax, invalid request message framing, or
> deceptive request
>
> routing).Exceptionjava.lang.IllegalArgumentException:
> Invalid character found in the request target. The valid characters
> are defined in RFC 7230 and RFC 3986
>
> org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:469)
>
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260)
>
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
>
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
> org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1639)
> org.apache.tomcat.util.net
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
>
> java.basejava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>
> java.basejava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> java.basejava.lang.Thread.run(Thread.java:834)
> Note The full stack trace of the root cause is
> available in the server logs.Apache Tomcat
> Version X
>
Re: tomcat 7.0.100 AJP connector with mod_jk on another host
Hello Martin, > > This should be: secretRequired="false". > > This attribute has been renamed recently. I just looked at my notes, and I tried that already yesterday night. Still facing the same problem with 403. Might it be possible that I need to use a secret in order to access ajp from mod_jk? Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.100 AJP connector with mod_jk on another host
Hello Martin, > This should be: secretRequired="false". > This attribute has been renamed recently. thanks. I'll test later and let you know how it went. Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.100 AJP connector with mod_jk on another host
Hi Thomas, On Thu, Mar 5, 2020 at 3:53 AM Thomas Glanzmann wrote: > Hello, > the problem was that I edited the wrong server.xml. The one that was not > used. So now that I figured that out, settings these two settings help. > > > > > className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> > className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> > className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> > > type="org.apache.catalina.UserDatabase" > description="User database that can be updated and > saved" > > factory="org.apache.catalina.users.MemoryUserDatabaseFactory" > pathname="conf/tomcat-users.xml" /> > > > connectionTimeout="3000" > URIEncoding="UTF-8" > redirectPort="8443" > maxHttpHeaderSize="8192" > maxThreads="400" > processorCache="400" > minSpareThreads="40" > enableLookups="false" > acceptCount="100" > disableUploadTimeout="true" > /> > address="0.0.0.0" > requiredSecret="false" > This should be: secretRequired="false". This attribute has been renamed recently. Martin > redirectPort="8443" > URIEncoding="UTF-8" > connectionTimeout="3000" > maxThreads="400" > processorCache="400" > minSpareThreads="40" > maxConnections="400" > enableLookups="false" > acceptCount="100" > /> > jvmRoute="tomcat-06" > > className="org.apache.catalina.realm.LockOutRealm"> > className="org.apache.catalina.realm.UserDatabaseRealm" > resourceName="UserDatabase"/> > > unpackWARs="true" autoDeploy="true"> > className="org.apache.catalina.valves.AccessLogValve" > directory="logs" > prefix="localhost_access_log." > suffix=".txt" > pattern="%h %l %u %t %r %s %b" > /> > > > > > > However when I try to access this using mod_jk, I get a 403. I used a > sniffer > and it is coming from the AJP connector. So I tried to set > allowedRequestAttributesPattern=".*" but that did not solve my problems, > any > ideas? > > Setup is: > > apache with mod_jk 1.2.46 load balances over 4 tomcats on seperate hosts. > > Cheers, > Thomas > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
