Re: encodeURL, jsessionid and mod_rewrite ?

[Peter Kreuser]

Peter Kreuser

> Am 04.10.2017 um 02:44 schrieb Christopher Schultz 
> :
> 
> -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

>> Now my question is : the  results in a
>> "/foo/page.jsp;jsessionid=..." I want the result instead as
>> /bar/pages.jsp;jsessionid=
>> 
>> Should I go straight for a HttpServletResponseWrapper replacing
>> every /foo/ with /bar/ or is there a more elegant way ? If the
>> apache rewrite rule is modified - say, to /barv2/, is it ok to use 
>> mod_headers to pass the original path instead of hardcoding /bar/
>> ?
> 
> You are going down a path that will produce endless problems, hacks,
> and ugly solutions to those problems. It will be much easier for you
> to simply re-name your application from "foo" to "bar" and not worry
> about any of this rewriting foolishness.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULvMdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjrIw//fPYMRXFyX4Ad4Qcl
> f6H2XjoFU7zOH9sQXjj5KgDL+DWS2nMH20RWes74ehYNv3BGDLIsv4CHClessOhW
> f7euy0y18IAhnTGjUaP3WjbN6xt2M6UgWsIv2jxS30DdI6irZ8/9IWdZ4xy8PNWV
> OujeuQBWniQH6jPVUwQ17qapiBDbAzB58HXb72KYFDj+Z6C0gacK/MT9yTkiNEX/
> bFNucLH2oTMomRcNeGZsmWCmQ+jShx0bMjmaKX5JndtckRCWSG8bAZYBhq5JA+bd
> GlFk/jZl+PT0cO1q6ViHvv9r3DDIUAMXvfvQnf6RciQ86GB+GrJn/GnRtPo7R5RH
> MoNRr7H16XBXER1SlzjXHLd2HOKf5pFduG1lgwY1z4OWKdqHY39/bSJynfCjyiNC
> VAvlZZQ2tCudwa+7Pit85FryW4HWECvw10vwYNLHDfFD63juI6YexaN+Fd5RGu8R
> jGqN3GqR1iboveGTv8O2kSvTgJjGa0nxsd6CTZLMJXt1GPlZ4r9MRdZWO/dobvGt
> QV18dvwHYHo1Jsgo1+pR6Hw34hw0dPfD5IYiHV9k+9yIeWj3l4/tYu+k1VA9j/Yp
> /LJ6otvJ+zBaa2swroy+EnnbMP6JR04GnXrezglXxbndaP1l7POCFngH34veM4+S
> j/5ZMvfJiUZdDAdQxoFH6B9ochU=
> =0zb2
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

RE: [SECURITY] CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP upload

[Caldarale, Charles R]

> From: Baron Fujimoto [mailto:ba...@hawaii.edu] 
> Subject: Re: [SECURITY] CVE-2017-12617 Apache Tomcat Remote Code Execution
via JSP upload

> I haven't seen an announcement for 8.0.47, nor does the Apache Tomcat
> website seem to reference it yet, but it appears to be available in the
> distribution archive(s). E.g.:

> 

> Is this 8.0.47 blessed for use?

Pretty much - the voting process completed over the weekend (it passed), but
the announcement isn't made until the mirrors all catch up.  Should be fine
to use from the archive.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.



smime.p7s
Description: S/MIME cryptographic signature

Re: [SECURITY] CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP upload

[Baron Fujimoto]

On Tue, Oct 03, 2017 at 10:55:26AM +, Mark Thomas wrote:
>CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP Upload
>
>Severity: Important
>
>Vendor: The Apache Software Foundation
>
>Versions Affected:
>[...]
>Apache Tomcat 8.0.0.RC1 to 8.0.46
>[...]
>
>Description:
>When running with HTTP PUTs enabled (e.g. via setting the readonly
>initialisation parameter of the Default servlet to false) it was
>possible to upload a JSP file to the server via a specially crafted
>request. This JSP could then be requested and any code it contained
>would be executed by the server.
>
>Mitigation:
>Users of the affected versions should apply one of the following
>mitigations:
>[...]
>- Upgrade to Apache Tomcat 8.0.47 or later
>[...]

I haven't seen an announcement for 8.0.47, nor does the Apache Tomcat
website seem to reference it yet, but it appears to be available in the
distribution archive(s). E.g.:



Is this 8.0.47 blessed for use?

Aloha,
-baron
-- 
Baron Fujimoto  :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

[James H. H. Lampert]

I wrote:

I mean, I know that I need to get HTTPAPI and Tomcat speaking the
same language, but where do I begin?


Christopher Schultz (Tomcat List) wrote:

First, I would check to see what Tomcat is actually advertising.
There are several ways to do that. One of them is to use Qualys's
SSLLabs server test:

https://www.ssllabs.com/ssltest/


Thanks, Mr. Schultz. That gives me a start.

Ok, here's what I got back.

Protocols
TLS 1.3 No
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3   No
SSL 2   No



Cipher Suites
# TLS 1.2 (server has no preference)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS   128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS   256
# TLS 1.1 (server has no preference)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  256
# TLS 1.0 (server has no preference)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  256


I may have known how to determine what HTTPAPI supports, but if so, I've 
forgotten. Ditto for adding protocols to Tomcat.


As to the client end, it's using HTTPAPI 1.24, running on an AS/400 
that's at V6R1.


--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: VS: Tomcat accesslogs / Geoserver

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jussila,

On 10/3/17 1:40 AM, Jussila Ville wrote:
> Thanks for your fast answer.
> 
> I'm quite new with Tomcat and HTTP. But as you said, Geoserver is 
> taking care of the authentication itself. So this is the problem
> and we are not able to log the username in the access logs. I think
> we have to focus then on the Geoserver own logging.

I have an idea for you, and it will only work because of the use of
HTTP Basic authentication.

With HTTP Basic, the username and password are present in every HTTP
request. Just because Tomcat is ignoring them doesn't mean you have to
ignore them.

You can log the incoming HTTP header WWW-Authenticate and you'll
capture the user's username. Unfortunately, you'll also capture their
password, which is a REALLY BAD THING TO DO in a log file like that.
But that might be the beginning of a solution.

Tomcat's access log component is a Valve, which means it runs before
any Filters. If you wrote a Valve to parse the WWW-Authenticate header
and place the user's username in a request parameter, you could log
that using the AccessLogValve.

The Valve will be relatively simple to write, but it does require that
you compile it against the Tomcat API itself, and then deploy the
Valve at the server level instead of in your application.

Hope that helps,
- -chris

> -Alkuperäinen viesti- Lähettäjä: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Lähetetty: 2. lokakuuta 2017
> 17:31 Vastaanottaja: users@tomcat.apache.org Aihe: Re: Tomcat
> accesslogs / Geoserver
> 
> Jussila,
> 
> On 10/2/17 9:18 AM, Jussila Ville wrote:
>> We are running Geoserver 2.11.1 with Java 1.8.0_131 on Tomcat
>> 8.0.44.
> 
>> I have tried before Geoserver's own mailing list without any
>> help, so now I try this one. Geoserver is a map engine to publish
>> raster and vector data in the Internet. More information can be
>> found here http://geoserver.org/
> 
>> We are not able to record the username in the Tomcat Accesslog. 
>> Geoserver has it's monitor plugin and Auditlogs, which we have 
>> installed and logs are running nicely with recorded username. In
>> the Tomcat's accesslog they don't show up no matter what I try.
>> We prefer more using Tomcat's access logs, as we are not
>> satisfied Geoservers format.
> 
>> Here are parameters for the AccessLogValve in Tomcat 
>> 8.0\conf\server.xml file
> 
>> > directory="D:\Data\GeoServer\Tomcat_logs" 
>> prefix="localhost_access_log" suffix=".txt" pattern="%a 
>> %{X-Forwarded-FOR}i %u %t %r %s %b" />
> 
>> I have tried to replace "%u" parameter with different kinds of 
>> syntaxes example "%{username}s", "%{userName}s",
>> "%{remoteUser}s", "%{remoteuser}s", but none of them had solved
>> the problem. Not even replacing "s" with "i". With
>> {Authorization}i, I was able to record that Geoserver is using
>> Basic authentication as it is set in UI.
> 
>> Can you help me?
> 
> Is it possible that Geoserver is using its own built-in HTTP Basic
> authentication instead of having Tomcat handle authentication? If
> so, Tomcat knows nothing about the user, etc. and can't log
> anything about them in the access log.
> 
> -chris
> 
> -
>
> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnUMTEdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgscw//QvrrDfjsMloHqhhV
d5svOMHqTwwKiD0sTNsJu8PscT19a2rtYVcf2C0Y9WG7uKYeeQkns0Mvg9KFxH+j
iSbwLVpLXgPuAa8pmPd9CxUOo5GvT1gkcrGiuB97J7q2m6n2lxhgjP2Wvc1/tln6
uhDjhuQjm9MsHE7SdEkN2zo6QDeog+AXEezNVUWsQulvXXVaAqwSMApmw9zFFKC0
KzGjEC26zSNM3qI8lTMpzo5oY9s52COtDPdc48yCEvss+ilM1nVO3FBc3PhU0gvg
EIT69r1vLPCwyaF5TGwJ44n1t3q0IU6/GZ5JKr2DbB5jg0ey5H7FhyX/eMIR0vqS
YtXA81Zi9xQ0ghmEuAp154ewxr1yL5XYC87JAbsT6kClTYTJVLvAeuDsXiqtfDw1
8vJy0+Q1KA1bq5UOZmHpzz8aP/B19EPMYXX62bUyeGxfRBs9tRZTrUta26gurzAW
jrYTJZb4KsGiqYgWGmjIOcXjvVhsaQFuoNGFDuHqW2wEYAVC4pVlKxI2fcpVAp6Z
GMm7cl+gmwWjoW1zknm8WMjXXE+pTQirz3sMC2spybm6sRMPc2oObnxrk1DNTli/
JxoKD/8KPm5U0JR28bYBb512YVB+cKFU2Y5ktcOzbdqNl0zERoAjlMuS8vA+zUAY
vaGdKTibeVNBsCtkgNiqXs+R37U=
=zLFb
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 10/3/17 5:52 PM, James H. H. Lampert wrote:
> Dear Mr. Klement, and members of the Tomcat List:
> 
> I have a series of AS/400 programs using HTTPAPI to access
> services hosted by a webapp running under Tomcat.
> 
> Up until now, I've only tested this configuration with Tomcat 7,
> running on a local Linux (CentOS) box, and the last time I tested
> it, it worked fine.
> 
> Today, for the first time, I tried changing the HTTPAPI calls to
> access essentially the same webapp, only running in Tomcat 8 on a
> cloud server, in order to find any places where the calls need to
> be updated to keep up with changes in the services.
> 
> And I didn't even get that far. Instead, the SSL handshake failed
> with
>> (GSKit) No compatible cipher suite available between SSL end
>> points.
> 
> Now what?
> 
> I mean, I know that I need to get HTTPAPI and Tomcat speaking the
> same language, but where do I begin?

First, I would check to see what Tomcat is actually advertising. There
are several ways to do that. One of them is to use Qualys's SSLLabs
server test:

https://www.ssllabs.com/ssltest/

Note that this tool only works for publicly-accessible servers.

If you have a private server, you'll need to resort to something a
little more complicated. I wrote a Java program to do just this. You
are welcome to use it:

https://wiki.apache.org/tomcat/tools/SSLTest.java
and
https://wiki.apache.org/tomcat/tools/SSLUtils.java

Once you know what cipher suites are actually supported by the server,
you can have a look at the ones supported by the HTTPAPI client to
make sure you have some overlap.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnUMAIdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFi7Rw//ZUb3T3GPjJ6yHjOs
bv09fY33iei8NXJYleHbzHs1XNVDRL8MMEtzc64g2DX9K5ducUqZEOpb5tSj7XiK
2uOsp5qaMplwFAgeY6kaAptaajuiz+WFDZXDOTRvcFTgwCEN2shsQDsJUd3EaXHj
NpduLueXpAY8B1V8GOAKQx2ZJxWO+puLDd8h0Ao/ojRmcxksFonBL8/Be6ZYTC4b
n5swZc9Hj8gs50ZkIrCfvNhOE+t7DJ2OH8WFJFdaNfHB/bWv1A3FyZ9bI9sgG+Ym
/EFH1khaWzH9AoB2Zv2dFD/D2ZDw2P30FJW1TZytcAQ6AhZo5fmMWNnKLMuu42Gw
EHGssKqohCIhQ7Cy5s3knigIwHURoXPo9shlDFJB/GQcTKcX8VCtTvDw23Ka0qQB
bjgmnrhb00dycBzFTiacG9RXrs7cMsYpgqzUFBTTYhDh0BhuQiwBQiTKo+dpoYab
XTuEPEeuUmV9HTW5+kPL1YXw8RSNxCgUvTA6w9jK4QE4CKp4WMi2ESAW/toB0XcR
yx9ZGqiDlYv732/8ID17P9/HN3GFskBGc90jjURmUtaLmPsidR9Ja7zU3zGHl2EQ
MyNTKrdpaXgwQMiFSNwbKqTXqY1Q6e4PfYjzsyPidah/FlhQd+nPXgievNLYp973
ifcIoyO9cd60yYnwW7y6TL3foXA=
=aRsw
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: encodeURL, jsessionid and mod_rewrite ?

[Christopher Schultz]

-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)
> 
> Now my question is : the  results in a
> "/foo/page.jsp;jsessionid=..." I want the result instead as
> /bar/pages.jsp;jsessionid=
> 
> Should I go straight for a HttpServletResponseWrapper replacing
> every /foo/ with /bar/ or is there a more elegant way ? If the
> apache rewrite rule is modified - say, to /barv2/, is it ok to use 
> mod_headers to pass the original path instead of hardcoding /bar/
> ?

You are going down a path that will produce endless problems, hacks,
and ugly solutions to those problems. It will be much easier for you
to simply re-name your application from "foo" to "bar" and not worry
about any of this rewriting foolishness.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULvMdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjrIw//fPYMRXFyX4Ad4Qcl
f6H2XjoFU7zOH9sQXjj5KgDL+DWS2nMH20RWes74ehYNv3BGDLIsv4CHClessOhW
f7euy0y18IAhnTGjUaP3WjbN6xt2M6UgWsIv2jxS30DdI6irZ8/9IWdZ4xy8PNWV
OujeuQBWniQH6jPVUwQ17qapiBDbAzB58HXb72KYFDj+Z6C0gacK/MT9yTkiNEX/
bFNucLH2oTMomRcNeGZsmWCmQ+jShx0bMjmaKX5JndtckRCWSG8bAZYBhq5JA+bd
GlFk/jZl+PT0cO1q6ViHvv9r3DDIUAMXvfvQnf6RciQ86GB+GrJn/GnRtPo7R5RH
MoNRr7H16XBXER1SlzjXHLd2HOKf5pFduG1lgwY1z4OWKdqHY39/bSJynfCjyiNC
VAvlZZQ2tCudwa+7Pit85FryW4HWECvw10vwYNLHDfFD63juI6YexaN+Fd5RGu8R
jGqN3GqR1iboveGTv8O2kSvTgJjGa0nxsd6CTZLMJXt1GPlZ4r9MRdZWO/dobvGt
QV18dvwHYHo1Jsgo1+pR6Hw34hw0dPfD5IYiHV9k+9yIeWj3l4/tYu+k1VA9j/Yp
/LJ6otvJ+zBaa2swroy+EnnbMP6JR04GnXrezglXxbndaP1l7POCFngH34veM4+S
j/5ZMvfJiUZdDAdQxoFH6B9ochU=
=0zb2
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Can i use tomcat 9.0.x version in production

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Murthy,

On 10/3/17 7:38 AM, s v n trimurthulu wrote:
> At present we are using 7.0.x in our production environment. As we
> have received few CVE alerts we wanted to migrate it to latest
> version 9.0.x. But when i see the status of the 9.0.x release it is
> showing "Stable = No". So i request you to suggest me whether i
> can use the latest version(9.0.1) of tomcat in production or not.
> Thanks in advance.

I'd recommend moving towards Tomcat 8.5 (after extensive testing in an
appropriate environment). There are very few differences between 8.5
and 9.0 (other than Servlet Spec changes) and so moving from 8.5 ->
9.0 in the future should be fairly easy.

Tomcat 8.5 *is* currently considered production-ready.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULoIdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhEWw//bpMgdIQCx11yDxUZ
a1TxW8C3jqzKrTJdF1qbWmlZRIVt0kL8gryU8YGtPEP2Ge0c7uf6uqIIwsSJAPKO
VoJhHwXe9lQWjZL4EUxzK9w+uU77Kl/C4kroojz2PiNS2CTeYOcrw6dfTmFdAMhY
KAHMnl6oxp/mwf2s5DW9E7XZ/E+6Y+Ovr1gNIZ5u0qZHSRDJhimsfiTQfaQ2JnuS
hORk/M1toaatDX0YiMXdyXIsWjDN4i+GpUvmIZheOP2SZauvyBCcCsL+OEEfWWSL
lFvJHCLBkGxGzjN9lIIISi/EYnhZa2xhPpGpr9UjbDLIip898nB/5JBPEgVaBfvu
lcCIzYJhfQpAwj2R0huY0P5NS0z1fUwnrhHntJpN0B/wXkkaBBuBc011MGl+1V0w
5GGGrPUhgHKxumWxR+VUn4ZUWL4jvg6V3lGx5i/GY0M4wjjlpZCIGBP+6Cg+CFD4
zhYQOre3IAFnb+CmJZhTXpp2kjjjgrDUcHLyjLWvcdl8JFLsBmWIqOvPBZvAbjN3
zWYg/GOis/obJ7quBlL/z0E2E2RI0yacuQ5sxO1z6HPbMFaQ9OIAjY0yEFZG+qlo
MuMVnckGpdiDdE+StUZcUHExpX+PXONL6VmT55m8lOrMjvQK5w/qtb5NPkgWM+ZO
Ys4yaxBShFtkVdAOlOAzYKGtmAs=
=7W8F
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Problem: (GSKit) No compatible cipher suite available between SSL end points.

[James H. H. Lampert]

Dear Mr. Klement, and members of the Tomcat List:

I have a series of AS/400 programs using HTTPAPI to access services 
hosted by a webapp running under Tomcat.


Up until now, I've only tested this configuration with Tomcat 7, running 
on a local Linux (CentOS) box, and the last time I tested it, it worked 
fine.


Today, for the first time, I tried changing the HTTPAPI calls to access 
essentially the same webapp, only running in Tomcat 8 on a cloud server, 
in order to find any places where the calls need to be updated to keep 
up with changes in the services.


And I didn't even get that far. Instead, the SSL handshake failed with

(GSKit) No compatible cipher suite available between SSL end points.


Now what?

I mean, I know that I need to get HTTPAPI and Tomcat speaking the same 
language, but where do I begin?


--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

encodeURL, jsessionid and mod_rewrite ?

[Laurent Perez]

Hi

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)

Now my question is : the  results in a "/foo/page.jsp;jsessionid=..."
I want the result instead as /bar/pages.jsp;jsessionid=

Should I go straight for a HttpServletResponseWrapper replacing every /foo/
with /bar/ or is there a more elegant way ?
If the apache rewrite rule is modified - say, to /barv2/, is it ok to use
mod_headers to pass the original path instead of hardcoding /bar/ ?

thanks

-- 
http://laurentperez.fr
J2EE, HTML5, JS, CSS3

Re: Mapping role names to groups

[Mark Thomas]

On 03/10/17 14:01, Sebastian Trost wrote:
> Hi!
> 
> I was looking for a way to map security role names from tomcat to LDAP 
> groups. I found an old thread from August 2009 with the exact problem in 
> which Christopher Schultz recommended to write a servlet filter or valve to 
> do that. 
> 
> Original mail: 
> http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3C1249556542.8225.6.camel@habanero%3E
> Response from Christopher Schulz: 
> http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3c4a7af405.7090...@christopherschultz.net%3E
> 
> It has now been eight years and I'm wondering if there is still no other 
> solution than this?

security-role-ref ?

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Mapping role names to groups

[Sebastian Trost]

Hi!

I was looking for a way to map security role names from tomcat to LDAP groups. 
I found an old thread from August 2009 with the exact problem in which 
Christopher Schultz recommended to write a servlet filter or valve to do that. 

Original mail: 
http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3C1249556542.8225.6.camel@habanero%3E
Response from Christopher Schulz: 
http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3c4a7af405.7090...@christopherschultz.net%3E

It has now been eight years and I'm wondering if there is still no other 
solution than this? 

Regards
Sebastian Trost

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Can i use tomcat 9.0.x version in production

[Mark Thomas]

On 03/10/17 12:38, s v n trimurthulu wrote:
> Hello There,
> 
> At present we are using 7.0.x in our production environment. As we have
> received few CVE alerts we wanted to migrate it to latest version 9.0.x.

I'm not sure if you look at the vulnerability data for the last 12
months that the evidence is there to support that conclusion.

> But when i see the status of the 9.0.x release it is showing "Stable =
> No". So i request you to suggest me whether i  can use the latest
> version(9.0.1) of tomcat in production or not. Thanks in advance.

What you use in production is entirely up to you.

The Tomcat community isn't yet ready to recommend using 9.0.x in
production. How quickly the community is ready to make that
recommendation will depend on the feedback we get on the beta releases.

I'd suggest that you start testing 9.0.x, report and bugs you find and
plan to move to 9.0.x once those bugs have been fixed and the Tomcat
community has declared 9.0.x stable.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Can i use tomcat 9.0.x version in production

[s v n trimurthulu]

Hello There,

At present we are using 7.0.x in our production environment. As we have
received few CVE alerts we wanted to migrate it to latest version 9.0.x.
But when i see the status of the 9.0.x release it is showing "Stable = No".
So i request you to suggest me whether i  can use the latest version(9.0.1)
of tomcat in production or not. Thanks in advance.

[image: Inline image 1]



Regards,
Murthy

[ANN] Apache Tomcat 9.0.1 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.1 (beta).

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.1 is the first beta release of the 9.0.x branch. The
notable changes compared to 9.0.0.M26 include:

- Servlet 4.0 implementation is complete

- Fix CVE-2017-12617

- Add the ability to reconfigure TLS connectors at runtime without
  stopping the connector

- Stricter validation of the Host header

- Additional capabilities for the CGI Servlet. Based on patches provided
  by jm009.

- Added support for the OpenSSL SSL_CONF API. To support this the
  minimum required Tomcat Native version is 1.2.14.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 8.5.23 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.23.

Tomcat 8.x users should normally be using 8.5.x releases in preference
to 8.0.x releases.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and Java Authentication Service Provider Interface for
Containers technologies.

Apache Tomcat 8.5.x is intended to replace 8.0.x and includes new
features pulled forward from the 9.0.x branch. The notable changes since
8.5.20 include:

- Fix CVE-2017-12617

- Add ExtractingRoot, a new WebResourceRoot implementation that extracts
  JARs to the work directory for improved performance when deploying
  packed WAR files.

- Additional capabilities for the CGI Servlet. Based on patches provided
  by jm009.

- Added support for the OpenSSL SSL_CONF API. To support this the
  minimum required Tomcat Native version is 1.2.14.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[SECURITY] CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP upload

[Mark Thomas]

CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP Upload

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.0
Apache Tomcat 8.5.0 to 8.5.22
Apache Tomcat 8.0.0.RC1 to 8.0.46
Apache Tomcat 7.0.0 to 7.0.81

Description:
When running with HTTP PUTs enabled (e.g. via setting the readonly
initialisation parameter of the Default servlet to false) it was
possible to upload a JSP file to the server via a specially crafted
request. This JSP could then be requested and any code it contained
would be executed by the server.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 9.0.1 or later
- Upgrade to Apache Tomcat 8.5.23 or later
- Upgrade to Apache Tomcat 8.0.47 or later
- Upgrade to Apache Tomcat 7.0.82 or later

Credit:
This issue was first reported publicly followed by multiple reports to
the Apache Tomcat Security Team.

History:
2017-10-03 Original advisory

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 9.0.1 - StandardJarScanner only scanning for HandlesTypes due to classloader issues

[Brian Toal]

In my embedded tomcat app, StandardJarScanner is doing a minimal Servlet
3.0 annotation scanning, specifically only HandlesTypes.  After digging in,
it appears that because the classloader that loaded StandardJarScanner is
the same that loaded StandardContext and ContextConfig
StandardJarScanner.isWebappClassLoader always returns false.   Then
StandardJarScanner.scan will set htOnly to true since fragment.getWebappJar
is false.


   // Only need to scan for @HandlesTypes matches if any of the
// following are true:
// - it has already been determined only @HandlesTypes is
required
//   (e.g. main web.xml has metadata-complete="true"
// - this fragment is for a container JAR (Servlet 3.1 section
8.1)
// - this fragment has metadata-complete="true"
boolean htOnly = handlesTypesOnly || !fragment.getWebappJar() ||
fragment.isMetadataComplete();

My embedded app looks as follows:


Tomcat tomcat = new Tomcat();

File docBase = new File(System.getProperty("java.io.tmpdir"));
tomcat.setBaseDir(docBase.getAbsolutePath());

tomcat.setSilent(false);
tomcat.setPort(8080);

// init http connector
tomcat.getConnector();

logger.info("Class loader = " +
Thread.currentThread().getContextClassLoader());

Context ctx = tomcat.addContext("", docBase.getAbsolutePath());
((StandardJarScanner) ctx.getJarScanner()).setScanClassPath(true);
((StandardJarScanner) ctx.getJarScanner()).setScanAllDirectories(true);
((StandardJarScanner) ctx.getJarScanner()).setScanAllFiles(true);

ContextConfig contextConfig = new ContextConfig();
ctx.addLifecycleListener(contextConfig);
contextConfig.setDefaultWebXml(Constants.NoDefaultWebXml);

tomcat.start();
tomcat.getServer().await();
} catch (LifecycleException e) {
throw new RuntimeException("Unable to launch tomcat ", e);
}

What do I need to do, in order to have StandardJarScanner loaded by a
seperate loader than the classes that are loaded when tomcat.start() so
that StandardJarScanner will honor searching for the remaining Servlet 3.0
annotations?