You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by dmccrthy <dm...@gmail.com> on 2015/01/08 14:51:24 UTC
Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Hi,
Is it possible to configure or hack Tomcat in some way to intercept
outbound HTTP URL requests from a deployed web application and convert them
to HTTPS with Mutual Authentication?
My scenario is:
* 3rd party web application that makes client invocations to a server that
requires HTTPS with Mutual Authentication
* I don’t know what framework the web application uses or how it creates
the HTTP client connections
* I can’t make changes to the 3rd party application
I have investigated the below but they don’t seem to offer a solution
* Adding Custom Resource Factories -
http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-
<http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html>
howto.html
<http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html>. This
requires changes to the client application
* HTTP connector - http://tomcat.apache.org/tomcat-7.0-doc/config/http.html.
This is for the Tomcat web server, not for outbound client connections
I have successfully configured the server and can make SoapUI calls to it
using HTTPS and Mutual Authentication. If I had control of the client code
I would use HttpClient and accomplish it that way.
For the Tomcat client application I have searched Google, Stackoverflow,
and the Tomcat wiki and mail archives but all HTTPS/Mutual Authentication
solutions I can find refer to Tomcat as the web server, not to web
applications making outbound connections from a Tomcat instance.
If there is no option to configure Tomcat then the only options I can think
of are below, but if anyone has any other insights it would be much
appreciated.
1) Write a between the Tomcat “client” instance and the HTTPS/MA endpoint
2) Find out the framework/socket factory/url connection factory the
3rdparty web app uses and override it with a Tomcat plugin
3) Raise a feature request with the 3rd party vendor to support HTTPS/MA
Many thanks,
Diarmuid McCarthy
Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Posted by dmccrthy <dm...@gmail.com>.
Hi André,
The endpoint is an internal service with published WSDL/XSDs. The 3rd party
client app used JAX-WS to invoke on it. Overriding client to use an
in-house URL protocol handler could be an option for solving the HTTPS/MA
issue. But if we introduce a WS policy to sign and encrypt the messages as
well then it becomes more complex again. My point here is that standing
back from the problem at hand and taking a broader architecture/security
perspective raises other challenges.
I think the right thing to do is a feature request on the 3rd party or
write a client library that does these things which the client app could
invoke on instead of using JAX-WS.
Well it was worth exploring this and I learned a huge amount, so my thanks
again for your continuing interest and advice.
Diarmuid
On 9 Jan 2015 16:44, "André Warnier" <aw...@ice-sa.com> wrote:
> Christopher Schultz wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Chuck,
>>
>> On 1/8/15 6:21 PM, Caldarale, Charles R wrote:
>>
>>> From: dmccrthy [mailto:dmccrthy@gmail.com] Subject: Re: Tomcat
>>>> 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS Mutual
>>>> Authentication connections
>>>> I found the link below from 2008. It looks like a minor change to
>>>> the Catalina WebAppLoader class might solve the problem and let
>>>> me provide a custom HTTPS URL protocol handler. Have I misread
>>>> this?
>>>> http://tomcat.10.x6.nabble.com/Custom-URL-handlers-in-
>>>> Tomcat-web-app-td2006418.html
>>>>
>>> This is for requests coming _into_ Tomcat, not any outbound
>>> requests your webapp is doing - which Tomcat is not involved in (or
>>> even aware of) at all. Again, you need some sort of proxy, if your
>>> webapp cannot be changed to do the right thing.
>>>
>>
>> No, this is for constructing URLs and using classes like URLConnection
>> to access them. If the underlying code (e.g. Apache httpclient) uses
>> URLConnection under the hood, then this technique will work.
>>
>> This is actually what my initial suggestion was in my first reply to
>> this thread: install a stream handler for a particular protocol.
>>
>> The thing is, I don't think you'd want to do this for *all* http://
>> URLs... only those that should be converted into secure ones. So you'd
>> have to be able to change the URL.
>>
>> Another thought: use stunnel. It's probably the simplest possible
>> thing to set up. Have stunnel listen on a nearby host (perhaps
>> localhost) for non-secure HTTP connections, and connect the other end
>> to the "real" server's HTTPS port. We do this at $work to deal with a
>> product that doesn't support HTTPS internally, just as the OP is doing.
>>
>>
> I think that the final answer is : "it depends".
> I've done a few of these "proxy hacks" in the past, for various purposes,
> including a couple of failed attempts too (but rich in lessons).
> If you know exactly what kind of requests the client (the webapp in this
> case) is sending to what server, and you know exactly what it gets in
> response, then you can usually do something of the "man in the middle" kind
> of thing.
> But by experience, some websites return really nightmarish stuff, full of
> re-directs, javascript modules making their own connections elsewhere,
> cookies containing information needed to access follow-up pages and
> whatnot, and that can quickly become unmanageable.
> (Think Akamai, ads and analytics sites, www.bbc.com and img.bbc.com,
> balancing proxies etc..)
>
> I have a couple of questions here, for my own edification but I believe
> also on-topic for the OP :
>
> We have this webapp making a HTTP connection on the side, to some
> third-party host.
> It is a fair bet that the creators of that webapp did not start from
> scratch, and that they used some existing library to do that (à la
> httpclient as Chris suggested).
>
> First question thus : even not having the source code of the webapp, can
> one easily find out what it uses in order to make that HTTP connection ?
>
> Assuming that the answer to the previous question is yes, second question :
> If a webapp "invokes" a given class to create such a connection, where
> does java look first for the corresponding class ? in the webapp's own
> WEB-INF/classes or WEB-INF/lib ?
>
> And if the answer to that is also yes, can one place a jar there, with
> classes having the same name as the one which the webapp would normally
> invoke, and which would be found first/override the usual ones it uses ?
>
> And could such a class examine the original request URL, and if it is not
> one that it should intercept and massage, just delegate the call to the
> similarly-named "normal" class ?
>
> Or is there something fundamentally uncouth/illegal/fattening in such a
> scheme ?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Chuck,
>
> On 1/8/15 6:21 PM, Caldarale, Charles R wrote:
>>> From: dmccrthy [mailto:dmccrthy@gmail.com] Subject: Re: Tomcat
>>> 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS Mutual
>>> Authentication connections
>>> I found the link below from 2008. It looks like a minor change to
>>> the Catalina WebAppLoader class might solve the problem and let
>>> me provide a custom HTTPS URL protocol handler. Have I misread
>>> this?
>>> http://tomcat.10.x6.nabble.com/Custom-URL-handlers-in-Tomcat-web-app-td2006418.html
>> This is for requests coming _into_ Tomcat, not any outbound
>> requests your webapp is doing - which Tomcat is not involved in (or
>> even aware of) at all. Again, you need some sort of proxy, if your
>> webapp cannot be changed to do the right thing.
>
> No, this is for constructing URLs and using classes like URLConnection
> to access them. If the underlying code (e.g. Apache httpclient) uses
> URLConnection under the hood, then this technique will work.
>
> This is actually what my initial suggestion was in my first reply to
> this thread: install a stream handler for a particular protocol.
>
> The thing is, I don't think you'd want to do this for *all* http://
> URLs... only those that should be converted into secure ones. So you'd
> have to be able to change the URL.
>
> Another thought: use stunnel. It's probably the simplest possible
> thing to set up. Have stunnel listen on a nearby host (perhaps
> localhost) for non-secure HTTP connections, and connect the other end
> to the "real" server's HTTPS port. We do this at $work to deal with a
> product that doesn't support HTTPS internally, just as the OP is doing.
>
I think that the final answer is : "it depends".
I've done a few of these "proxy hacks" in the past, for various purposes, including a
couple of failed attempts too (but rich in lessons).
If you know exactly what kind of requests the client (the webapp in this case) is sending
to what server, and you know exactly what it gets in response, then you can usually do
something of the "man in the middle" kind of thing.
But by experience, some websites return really nightmarish stuff, full of re-directs,
javascript modules making their own connections elsewhere, cookies containing information
needed to access follow-up pages and whatnot, and that can quickly become unmanageable.
(Think Akamai, ads and analytics sites, www.bbc.com and img.bbc.com, balancing proxies etc..)
I have a couple of questions here, for my own edification but I believe also on-topic for
the OP :
We have this webapp making a HTTP connection on the side, to some third-party host.
It is a fair bet that the creators of that webapp did not start from scratch, and that
they used some existing library to do that (à la httpclient as Chris suggested).
First question thus : even not having the source code of the webapp, can one easily find
out what it uses in order to make that HTTP connection ?
Assuming that the answer to the previous question is yes, second question :
If a webapp "invokes" a given class to create such a connection, where does java look
first for the corresponding class ? in the webapp's own WEB-INF/classes or WEB-INF/lib ?
And if the answer to that is also yes, can one place a jar there, with classes having the
same name as the one which the webapp would normally invoke, and which would be found
first/override the usual ones it uses ?
And could such a class examine the original request URL, and if it is not one that it
should intercept and massage, just delegate the call to the similarly-named "normal" class ?
Or is there something fundamentally uncouth/illegal/fattening in such a scheme ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Chuck,
On 1/8/15 6:21 PM, Caldarale, Charles R wrote:
>> From: dmccrthy [mailto:dmccrthy@gmail.com] Subject: Re: Tomcat
>> 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS Mutual
>> Authentication connections
>
>> I found the link below from 2008. It looks like a minor change to
>> the Catalina WebAppLoader class might solve the problem and let
>> me provide a custom HTTPS URL protocol handler. Have I misread
>> this?
>
>> http://tomcat.10.x6.nabble.com/Custom-URL-handlers-in-Tomcat-web-app-td2006418.html
>
>>
> This is for requests coming _into_ Tomcat, not any outbound
> requests your webapp is doing - which Tomcat is not involved in (or
> even aware of) at all. Again, you need some sort of proxy, if your
> webapp cannot be changed to do the right thing.
No, this is for constructing URLs and using classes like URLConnection
to access them. If the underlying code (e.g. Apache httpclient) uses
URLConnection under the hood, then this technique will work.
This is actually what my initial suggestion was in my first reply to
this thread: install a stream handler for a particular protocol.
The thing is, I don't think you'd want to do this for *all* http://
URLs... only those that should be converted into secure ones. So you'd
have to be able to change the URL.
Another thought: use stunnel. It's probably the simplest possible
thing to set up. Have stunnel listen on a nearby host (perhaps
localhost) for non-secure HTTP connections, and connect the other end
to the "real" server's HTTPS port. We do this at $work to deal with a
product that doesn't support HTTPS internally, just as the OP is doing.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUr+ivAAoJEBzwKT+lPKRYGyAQALIalsmLuFWjgu2bGbqC1VyE
1LmOEaotCgxTzf6Y1ZYcOSFh9x1lzEp4iipbNN/qKQQsixtBVAv5f8OOvg28Y7TM
syu+Kh1WAzja1e8MJAvhQoIv/ORYPLl9UFcc9+QyNuBZqh0QwLLEBx/RrepQM3IV
XixHeLGt+rXL51NtH+xYSHmyJIHHI+bBaJwUSWnhxn214s0xssbOEaXMmggXmDwu
Qz0bgHVWwbKBo3IDEHI2vOxNDkujmon274kg8681rywt+yqHNZXjv0WXK53pElTL
W43RGQ7slhMoQd5Yf6Rt+2RqVbZeMK0jhTCFTGUJiznjYrMlZSJayEmRAGTvdX9Q
ZcOLynCUxwh2iLKZj7rPwYUd4VjiSjpbFHIXjsz3M0kVtMXSfB2jemHiiBN2pAhW
6DdTG1sAET0Qb2DHrck3gqLYreHiF+CB8bn8uUPzATP3E9mUAyvWlpcyxF2N4Zj/
BPtS4fd+vXASTKuDZXOKbGEnv0Mlr1/06AHG4e3MMnaIWoaw1waH/jUHwXUYHmHQ
bX5yJx8dyzx5lE8nfnvKosvro2Zh0l14Ds4ZRpfh9fDvy/hVuYEwb7vOe1GlRj7z
oqLeACIEO0UDiJIdGOxKLanJ4v+jbH2e3bKK5taaqOKicUppQUN0XrDa9nwsrqV7
Q9ENacRORksscFncx/Ch
=V0lH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Posted by dmccrthy <dm...@gmail.com>.
(sigh) Ok, there's do the right thing or brave the proxy approach.
Thanks all, I am immensely grateful and impressed with all the advice,
warnings, and offers of contacts. Hopefully I can give something back in
due course.
Diarmuid
On 8 Jan 2015 23:25, "Caldarale, Charles R" <Ch...@unisys.com>
wrote:
> > From: dmccrthy [mailto:dmccrthy@gmail.com]
> > Subject: Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client
> HTTPS Mutual
> > Authentication connections
>
> > I found the link below from 2008.
> > It looks like a minor change to the Catalina WebAppLoader class might
> solve
> > the problem and let me provide a custom HTTPS URL protocol handler. Have
> I
> > misread this?
>
> >
> http://tomcat.10.x6.nabble.com/Custom-URL-handlers-in-Tomcat-web-app-td2006418.html
>
> This is for requests coming _into_ Tomcat, not any outbound requests your
> webapp is doing - which Tomcat is not involved in (or even aware of) at
> all. Again, you need some sort of proxy, if your webapp cannot be changed
> to do the right thing.
>
> - 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
RE: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client
HTTPS Mutual Authentication connections
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: dmccrthy [mailto:dmccrthy@gmail.com]
> Subject: Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS Mutual
> Authentication connections
> I found the link below from 2008.
> It looks like a minor change to the Catalina WebAppLoader class might solve
> the problem and let me provide a custom HTTPS URL protocol handler. Have I
> misread this?
> http://tomcat.10.x6.nabble.com/Custom-URL-handlers-in-Tomcat-web-app-td2006418.html
This is for requests coming _into_ Tomcat, not any outbound requests your webapp is doing - which Tomcat is not involved in (or even aware of) at all. Again, you need some sort of proxy, if your webapp cannot be changed to do the right thing.
- 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Posted by dmccrthy <dm...@gmail.com>.
Hi André, Chris,
Just to park the proxy idea for a moment, I found the link below from 2008.
It looks like a minor change to the Catalina WebAppLoader class might solve
the problem and let me provide a custom HTTPS URL protocol handler. Have I
misread this?
http://tomcat.10.x6.nabble.com/Custom-URL-handlers-in-Tomcat-web-app-td2006418.html
Thanks,
Diarmuid
On 8 Jan 2015 22:08, "André Warnier" <aw...@ice-sa.com> wrote:
> dmccrthy wrote:
>
>> Chris, André,
>>
>> Many thanks. I hadn't considered either the MITM or Apache HTTPD angles.
>> The proxy idea occurred to me (sorry, I had a typo in my original mail and
>> that may not have been clear) but I agree it's messy.
>>
>> Many thanks again, I just couldn't find anything that said yes it can be
>> done, or no it can't. A 3rd party feature request is a last resort so I
>> had
>> to find out if there was some under-the-bonnet way. I really appreciate
>> your insights into this.
>>
>>
> No problem.
>
> For the sake of completeness, the only thing which made me cautious about
> using an already-made proxy server such as Apache httpd, is the question of
> the DNS lookups (or rather the "resolver" in the machine itself), if you
> play with the fake entry in the hosts file.
> Consider the following scenario :
> - the webapp in question wants to connect to "server.company.com:8000"
> - to divert this to your own local proxy, you define "server.company.com"
> in the local hosts file as 127.0.0.1 (the localhost), and you set up a
> local httpd to listen on 127.0.0.1:8000, to do the proxying.
> - thus when the webapp builds its TCP connection to "
> server.company.com:8000" - presumably by looking up "server.company.com"
> first - it gets back (from the local OS's resolver) the IP address
> 127.0.0.1, and builds a TCP connection to 127.0.0.1.
> Then over that connection, it sends a HTTP 1.1 request including a "Host:
> server.company.com" header.
> So far so good.
> - your httpd proxy catches this connection and the request.
> - now the proxy has itself to build a connection to the "real"
> server.company.com.
> So it does a lookup (using the local OS's TCP stack) for the IP address of
> "server.company.com", to build its own connection to it.
> And.. it gets back 127.0.0.1 as an IP address (because of course that
> lookup also looks in the local hosts file first).
>
> That would be kind of a self-inflicted DOS attack, and it would be
> interesting to see how quickly the proxy would blow up.
>
> I am not quite sure how you would "corrupt" the httpd proxy code not to do
> that (*).
> If you tell it to connect to the IP address of that remote host instead,
> it may not work as expected, if that remote host happens to be configured
> with Virtual Hosts itself (which work by name).
>
> You may be able to configure your webapp to connect to another fake
> hostname, rather than the real destination one. In that case, there is a
> workaround : define that fake hostname as 127.0.0.1, instead of the real
> destination one.
> But otherwise, you may be in trouble.
>
>
> (*) well, actually I do have an idea, but it involves an Apache httpd with
> perl/mod_perl on it, and some devious perl coding to mess around with the
> proxy request before mod_proxy sends it out. If it is really important to
> you, and you find no other solution, I could point you to a good consultant
> for this kind of thing.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 1/8/15 5:07 PM, André Warnier wrote:
> dmccrthy wrote:
>> Chris, André,
>>
>> Many thanks. I hadn't considered either the MITM or Apache HTTPD
>> angles. The proxy idea occurred to me (sorry, I had a typo in my
>> original mail and that may not have been clear) but I agree it's
>> messy.
>>
>> Many thanks again, I just couldn't find anything that said yes it
>> can be done, or no it can't. A 3rd party feature request is a
>> last resort so I had to find out if there was some
>> under-the-bonnet way. I really appreciate your insights into
>> this.
>>
>
> No problem.
>
> For the sake of completeness, the only thing which made me
> cautious about using an already-made proxy server such as Apache
> httpd, is the question of the DNS lookups (or rather the "resolver"
> in the machine itself), if you play with the fake entry in the
> hosts file. Consider the following scenario : - the webapp in
> question wants to connect to "server.company.com:8000" - to divert
> this to your own local proxy, you define "server.company.com" in
> the local hosts file as 127.0.0.1 (the localhost), and you set up a
> local httpd to listen on 127.0.0.1:8000, to do the proxying. - thus
> when the webapp builds its TCP connection to
> "server.company.com:8000" - presumably by looking up
> "server.company.com" first - it gets back (from the local OS's
> resolver) the IP address 127.0.0.1, and builds a TCP connection to
> 127.0.0.1. Then over that connection, it sends a HTTP 1.1 request
> including a "Host: server.company.com" header. So far so good. -
> your httpd proxy catches this connection and the request. - now the
> proxy has itself to build a connection to the "real"
> server.company.com. So it does a lookup (using the local OS's TCP
> stack) for the IP address of "server.company.com", to build its own
> connection to it. And.. it gets back 127.0.0.1 as an IP address
> (because of course that lookup also looks in the local hosts file
> first).
>
> That would be kind of a self-inflicted DOS attack, and it would be
> interesting to see how quickly the proxy would blow up.
An easy solution would be to put the proxy on a different machine. I
hadn't thought of hosts+localhost = boom. Good catch.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUr+egAAoJEBzwKT+lPKRYawQQAKb14/7+pwOePtzOxSqVOAUN
J33Vejmc0D1g1fWsondGenw+T5h7lEBfCNyWh6mL02JL2N5bPptHL3wScsdtiA+4
u+hrbhSrv/iO1LHGXNZxjVot0GeCCPLnKN8DLMqAquJqADOU+bcCjnqGrO3eTK/M
Aw0rs83I7T+KIfEsIDYTagChdzNNqKbsqh28HJNQ4dNaSswnq15ecCgakUAVKbCI
4mGXXT/pC3v/lOKsI8m/vvo15cUv0Si/ptF1jr/4smQ+nbnNkg/ICmE/sdkPtVZj
kU/T2V3jKXesv72U4g1m2nBHtLpYxUaHmupkaaY9ix3kgSfFq0vtHLw09qsKBlxG
8N/aW1QH/5korYRtze6vjNFZz+mKyiqrpbytvwbBH3rQbJz4ci71cqOm9cDByvEz
pszb5wIzFwgB3IhJ2u7ZROH+30UYp4nfghEBWDPJ9Uxq5fmUwfmLR8PHX4AaQ9wO
KA2XTcUVkE1WTNFQ4QbWYGXnr6Moaeuhxq3MhMkJ7awch57DPS0su4ViFtxNq7+Q
LBG+S4sG5pWQRfBEg331XK7nnslHkUmn7YS7FojaCZMaY/b/ABwBGjlHCDTmfqAp
6WO/jjb2CHsBgOHDVrYeJkrtl2FflSo15IDMsNX8YX0MYQJQz9FB0sGAzXd6rZM/
z1dFLaN59dNMYYnill1G
=rbNy
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Posted by André Warnier <aw...@ice-sa.com>.
dmccrthy wrote:
> Chris, André,
>
> Many thanks. I hadn't considered either the MITM or Apache HTTPD angles.
> The proxy idea occurred to me (sorry, I had a typo in my original mail and
> that may not have been clear) but I agree it's messy.
>
> Many thanks again, I just couldn't find anything that said yes it can be
> done, or no it can't. A 3rd party feature request is a last resort so I had
> to find out if there was some under-the-bonnet way. I really appreciate
> your insights into this.
>
No problem.
For the sake of completeness, the only thing which made me cautious about using an
already-made proxy server such as Apache httpd, is the question of the DNS lookups (or
rather the "resolver" in the machine itself), if you play with the fake entry in the hosts
file.
Consider the following scenario :
- the webapp in question wants to connect to "server.company.com:8000"
- to divert this to your own local proxy, you define "server.company.com" in the local
hosts file as 127.0.0.1 (the localhost), and you set up a local httpd to listen on
127.0.0.1:8000, to do the proxying.
- thus when the webapp builds its TCP connection to "server.company.com:8000" - presumably
by looking up "server.company.com" first - it gets back (from the local OS's resolver) the
IP address 127.0.0.1, and builds a TCP connection to 127.0.0.1.
Then over that connection, it sends a HTTP 1.1 request including a "Host:
server.company.com" header.
So far so good.
- your httpd proxy catches this connection and the request.
- now the proxy has itself to build a connection to the "real" server.company.com.
So it does a lookup (using the local OS's TCP stack) for the IP address of
"server.company.com", to build its own connection to it.
And.. it gets back 127.0.0.1 as an IP address (because of course that lookup also looks in
the local hosts file first).
That would be kind of a self-inflicted DOS attack, and it would be interesting to see how
quickly the proxy would blow up.
I am not quite sure how you would "corrupt" the httpd proxy code not to do that (*).
If you tell it to connect to the IP address of that remote host instead, it may not work
as expected, if that remote host happens to be configured with Virtual Hosts itself (which
work by name).
You may be able to configure your webapp to connect to another fake hostname, rather than
the real destination one. In that case, there is a workaround : define that fake hostname
as 127.0.0.1, instead of the real destination one.
But otherwise, you may be in trouble.
(*) well, actually I do have an idea, but it involves an Apache httpd with perl/mod_perl
on it, and some devious perl coding to mess around with the proxy request before mod_proxy
sends it out. If it is really important to you, and you find no other solution, I could
point you to a good consultant for this kind of thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Posted by dmccrthy <dm...@gmail.com>.
Chris, André,
Many thanks. I hadn't considered either the MITM or Apache HTTPD angles.
The proxy idea occurred to me (sorry, I had a typo in my original mail and
that may not have been clear) but I agree it's messy.
Many thanks again, I just couldn't find anything that said yes it can be
done, or no it can't. A 3rd party feature request is a last resort so I had
to find out if there was some under-the-bonnet way. I really appreciate
your insights into this.
Best regards,
Diarmuid
On 8 Jan 2015 16:16, "Christopher Schultz" <ch...@christopherschultz.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> André,
>
> On 1/8/15 9:52 AM, André Warnier wrote:
> > dmccrthy wrote:
> >> Hi,
> >>
> >> Is it possible to configure or hack Tomcat in some way to
> >> intercept outbound HTTP URL requests from a deployed web
> >> application and convert them to HTTPS with Mutual
> >> Authentication?
> >>
> >> My scenario is:
> >>
> >> * 3rd party web application that makes client invocations to a
> >> server that requires HTTPS with Mutual Authentication * I don’t
> >> know what framework the web application uses or how it creates
> >> the HTTP client connections * I can’t make changes to the 3rd
> >> party application
> >>
> >> I have investigated the below but they don’t seem to offer a
> >> solution
> >>
> >> * Adding Custom Resource Factories -
> >> http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-
> >> <http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html>
> >>
> >>
> howto.html
> >> <http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html>.
> >> This requires changes to the client application * HTTP connector
> >> - http://tomcat.apache.org/tomcat-7.0-doc/config/http.html.. This
> >> is for the Tomcat web server, not for outbound client
> >> connections
> >>
> >> I have successfully configured the server and can make SoapUI
> >> calls to it using HTTPS and Mutual Authentication. If I had
> >> control of the client code I would use HttpClient and accomplish
> >> it that way.
> >>
> >> For the Tomcat client application I have searched Google,
> >> Stackoverflow, and the Tomcat wiki and mail archives but all
> >> HTTPS/Mutual Authentication solutions I can find refer to Tomcat
> >> as the web server, not to web applications making outbound
> >> connections from a Tomcat instance.
> >>
> >> If there is no option to configure Tomcat then the only options I
> >> can think of are below, but if anyone has any other insights it
> >> would be much appreciated.
> >>
> >> 1) Write a between the Tomcat “client” instance and the HTTPS/MA
> >> endpoint 2) Find out the framework/socket factory/url connection
> >> factory the 3rdparty web app uses and override it with a Tomcat
> >> plugin 3) Raise a feature request with the 3rd party vendor to
> >> support HTTPS/MA
> >>
> >
> > I don't know really about the "hacking Tomcat" option (but I
> > believe that is not possible in this case, because Tomcat is not
> > involved at all in those connections which the webapp is making "on
> > the side").
> >
> > This is what you could do outside of Tomcat (but it is some work)
> > :
> >
> > 1) find out to what hostname:port that application is making a
> > call. Say for now that it is "server.company.com:8000".
> >
> > 2) in the "hosts" file of the Tomcat server, add an entry for that
> > hostname, with IP address 127.0.0.1, like 127.0.0.1
> > server.company.com (alternatively, you could use another valid IP
> > of your Tomcat server)
>
> Yup: MITM.
>
> > 3) on the Tomcat server, create a separate "proxy" process which
> > listens on that IP and port 8000 for such HTTP requests, and
> > forwards them via HTTPS to the real external host/port (while being
> > careful not to create a loop via the hosts file - iow, if possible,
> > it should not do a DNS lookup for the external hostname
> > "server.company.com", because it would get 127.0.0.1 as the IP
> > address, and that would be self-defeating)
> >
> > Of course then, the burden of the HTTPS/MA dialog falls on that
> > process which you create.
>
> Any web server capable of proxying would work here, probably better
> than Tomcat. Proxying connections from HTTP to HTTPS using Apache
> httpd would be fairly simple: no code required, just configuration.
>
> > Note that this approach is somewhat simplistic and flaky, and will
> > only work if these external HTTP requests/responses are really
> > simple, and the responses returned by the external server don't do
> > things like re-directs elsewhere etc..
>
> Apache httpd would probably handle these appropriately. Writing one's
> one code would be a mistake, here.
>
> > It would indeed be a lot better to ask the webapp provider to fix
> > their code.
>
> +1
>
> > But also note that to simplify your life you may be able, for this
> > separate "proxy" process, to use an already-existing piece of
> > software such as an Apache httpd webserver (listening on
> > localhost:8000) (*), or some utility that creates "tunnels".
>
> +1
>
> > (*) or even a dedicated Tomcat instance, provided you find a webapp
> > able to act as a HTTPS/MA proxy
>
> I'm not sure if there's a Java-based proxy web application out there;
> I've never looked for one. The use of httpd, nginx, or squid seems
> like a much better choice. The nice thing is that you don't have to
> deploy it wide-scale: you can just make it listen to localhost
> connections and not expand the attack surface of your server. So, even
> though you might be introducing more complexity, etc. into your
> network setup, you are not exposing that service to the world and only
> have "trusted" clients connecting to it (the service you are trying to
> MITM).
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJUrq0cAAoJEBzwKT+lPKRY/B4QAKB+9GhfOGH49duuMDpKo9Y5
> yPBcyM5S0BAaTeDnePYr+62fLqOLc3LlENUprM01wPKqTgMuIgeFd9q6yOGeDzwb
> +p8DF+zpvNFO+3n1KG+UAtZdNOdmFoZoMJZ76ZEngw67yYODSD1EKs1e9ckyTvGc
> 28hG3lle+9ApmVDocREPb3vs6ZhE5CjjrtSzz8ZYyKJPif8U+VwrDg3AjfaDTSVk
> 3JFC0ow2/smjDJ/er287114g+yXOR4ABojE45gJ/hr2IUrO/GWiwmO3Bhk/EGeck
> 24FOJ8ntBt5OqOXUX1LpcjpsoZujf3kQEyx3HC+Y7USijS02OZoVmvjTvlIdW4yE
> Fvl08wxOcjRo8GkdYoBMBwLQd56O11h2qOBHMa++ij09GLpbzHAj5z0Aac5ppLjl
> C2pgnAob1wRsfsaym726dOvtipRhXJyaIHxzjd7TqvCUG+47ypyWkxGpHyN9WzXE
> YEGI3UI7qpkBBNl43KRHyo5slz9YDgcDRQYFjh0MufXBFuE5s2q9AO4y1eIWO7G2
> q/P5MgKuUPjlFmBNAeh7C5FFtiKPx7LXkchfvfjD7J5c+tTOKokXJC7uU7W6mZkt
> joGjO6oxh7LnVy4hPDtqS5TbwX9pzYbCdidFJpptH0LgMR6/4T8a00Aj81KLzy50
> x4vaYzEKdFHYQwmHhdqf
> =Zyum
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 1/8/15 9:52 AM, André Warnier wrote:
> dmccrthy wrote:
>> Hi,
>>
>> Is it possible to configure or hack Tomcat in some way to
>> intercept outbound HTTP URL requests from a deployed web
>> application and convert them to HTTPS with Mutual
>> Authentication?
>>
>> My scenario is:
>>
>> * 3rd party web application that makes client invocations to a
>> server that requires HTTPS with Mutual Authentication * I don’t
>> know what framework the web application uses or how it creates
>> the HTTP client connections * I can’t make changes to the 3rd
>> party application
>>
>> I have investigated the below but they don’t seem to offer a
>> solution
>>
>> * Adding Custom Resource Factories -
>> http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-
>> <http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html>
>>
>>
howto.html
>> <http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html>.
>> This requires changes to the client application * HTTP connector
>> - http://tomcat.apache.org/tomcat-7.0-doc/config/http.html.. This
>> is for the Tomcat web server, not for outbound client
>> connections
>>
>> I have successfully configured the server and can make SoapUI
>> calls to it using HTTPS and Mutual Authentication. If I had
>> control of the client code I would use HttpClient and accomplish
>> it that way.
>>
>> For the Tomcat client application I have searched Google,
>> Stackoverflow, and the Tomcat wiki and mail archives but all
>> HTTPS/Mutual Authentication solutions I can find refer to Tomcat
>> as the web server, not to web applications making outbound
>> connections from a Tomcat instance.
>>
>> If there is no option to configure Tomcat then the only options I
>> can think of are below, but if anyone has any other insights it
>> would be much appreciated.
>>
>> 1) Write a between the Tomcat “client” instance and the HTTPS/MA
>> endpoint 2) Find out the framework/socket factory/url connection
>> factory the 3rdparty web app uses and override it with a Tomcat
>> plugin 3) Raise a feature request with the 3rd party vendor to
>> support HTTPS/MA
>>
>
> I don't know really about the "hacking Tomcat" option (but I
> believe that is not possible in this case, because Tomcat is not
> involved at all in those connections which the webapp is making "on
> the side").
>
> This is what you could do outside of Tomcat (but it is some work)
> :
>
> 1) find out to what hostname:port that application is making a
> call. Say for now that it is "server.company.com:8000".
>
> 2) in the "hosts" file of the Tomcat server, add an entry for that
> hostname, with IP address 127.0.0.1, like 127.0.0.1
> server.company.com (alternatively, you could use another valid IP
> of your Tomcat server)
Yup: MITM.
> 3) on the Tomcat server, create a separate "proxy" process which
> listens on that IP and port 8000 for such HTTP requests, and
> forwards them via HTTPS to the real external host/port (while being
> careful not to create a loop via the hosts file - iow, if possible,
> it should not do a DNS lookup for the external hostname
> "server.company.com", because it would get 127.0.0.1 as the IP
> address, and that would be self-defeating)
>
> Of course then, the burden of the HTTPS/MA dialog falls on that
> process which you create.
Any web server capable of proxying would work here, probably better
than Tomcat. Proxying connections from HTTP to HTTPS using Apache
httpd would be fairly simple: no code required, just configuration.
> Note that this approach is somewhat simplistic and flaky, and will
> only work if these external HTTP requests/responses are really
> simple, and the responses returned by the external server don't do
> things like re-directs elsewhere etc..
Apache httpd would probably handle these appropriately. Writing one's
one code would be a mistake, here.
> It would indeed be a lot better to ask the webapp provider to fix
> their code.
+1
> But also note that to simplify your life you may be able, for this
> separate "proxy" process, to use an already-existing piece of
> software such as an Apache httpd webserver (listening on
> localhost:8000) (*), or some utility that creates "tunnels".
+1
> (*) or even a dedicated Tomcat instance, provided you find a webapp
> able to act as a HTTPS/MA proxy
I'm not sure if there's a Java-based proxy web application out there;
I've never looked for one. The use of httpd, nginx, or squid seems
like a much better choice. The nice thing is that you don't have to
deploy it wide-scale: you can just make it listen to localhost
connections and not expand the attack surface of your server. So, even
though you might be introducing more complexity, etc. into your
network setup, you are not exposing that service to the world and only
have "trusted" clients connecting to it (the service you are trying to
MITM).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUrq0cAAoJEBzwKT+lPKRY/B4QAKB+9GhfOGH49duuMDpKo9Y5
yPBcyM5S0BAaTeDnePYr+62fLqOLc3LlENUprM01wPKqTgMuIgeFd9q6yOGeDzwb
+p8DF+zpvNFO+3n1KG+UAtZdNOdmFoZoMJZ76ZEngw67yYODSD1EKs1e9ckyTvGc
28hG3lle+9ApmVDocREPb3vs6ZhE5CjjrtSzz8ZYyKJPif8U+VwrDg3AjfaDTSVk
3JFC0ow2/smjDJ/er287114g+yXOR4ABojE45gJ/hr2IUrO/GWiwmO3Bhk/EGeck
24FOJ8ntBt5OqOXUX1LpcjpsoZujf3kQEyx3HC+Y7USijS02OZoVmvjTvlIdW4yE
Fvl08wxOcjRo8GkdYoBMBwLQd56O11h2qOBHMa++ij09GLpbzHAj5z0Aac5ppLjl
C2pgnAob1wRsfsaym726dOvtipRhXJyaIHxzjd7TqvCUG+47ypyWkxGpHyN9WzXE
YEGI3UI7qpkBBNl43KRHyo5slz9YDgcDRQYFjh0MufXBFuE5s2q9AO4y1eIWO7G2
q/P5MgKuUPjlFmBNAeh7C5FFtiKPx7LXkchfvfjD7J5c+tTOKokXJC7uU7W6mZkt
joGjO6oxh7LnVy4hPDtqS5TbwX9pzYbCdidFJpptH0LgMR6/4T8a00Aj81KLzy50
x4vaYzEKdFHYQwmHhdqf
=Zyum
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Posted by André Warnier <aw...@ice-sa.com>.
dmccrthy wrote:
> Hi,
>
> Is it possible to configure or hack Tomcat in some way to intercept
> outbound HTTP URL requests from a deployed web application and convert them
> to HTTPS with Mutual Authentication?
>
> My scenario is:
>
> * 3rd party web application that makes client invocations to a server that
> requires HTTPS with Mutual Authentication
> * I don’t know what framework the web application uses or how it creates
> the HTTP client connections
> * I can’t make changes to the 3rd party application
>
> I have investigated the below but they don’t seem to offer a solution
>
> * Adding Custom Resource Factories -
> http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-
> <http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html>
> howto.html
> <http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html>. This
> requires changes to the client application
> * HTTP connector - http://tomcat.apache.org/tomcat-7.0-doc/config/http.html..
> This is for the Tomcat web server, not for outbound client connections
>
> I have successfully configured the server and can make SoapUI calls to it
> using HTTPS and Mutual Authentication. If I had control of the client code
> I would use HttpClient and accomplish it that way.
>
> For the Tomcat client application I have searched Google, Stackoverflow,
> and the Tomcat wiki and mail archives but all HTTPS/Mutual Authentication
> solutions I can find refer to Tomcat as the web server, not to web
> applications making outbound connections from a Tomcat instance.
>
> If there is no option to configure Tomcat then the only options I can think
> of are below, but if anyone has any other insights it would be much
> appreciated.
>
> 1) Write a between the Tomcat “client” instance and the HTTPS/MA endpoint
> 2) Find out the framework/socket factory/url connection factory the
> 3rdparty web app uses and override it with a Tomcat plugin
> 3) Raise a feature request with the 3rd party vendor to support HTTPS/MA
>
I don't know really about the "hacking Tomcat" option (but I believe that is not possible
in this case, because Tomcat is not involved at all in those connections which the webapp
is making "on the side").
This is what you could do outside of Tomcat (but it is some work) :
1) find out to what hostname:port that application is making a call.
Say for now that it is "server.company.com:8000".
2) in the "hosts" file of the Tomcat server, add an entry for that hostname, with IP
address 127.0.0.1, like
127.0.0.1 server.company.com
(alternatively, you could use another valid IP of your Tomcat server)
3) on the Tomcat server, create a separate "proxy" process which listens on that IP and
port 8000 for such HTTP requests, and forwards them via HTTPS to the real external
host/port (while being careful not to create a loop via the hosts file - iow, if possible,
it should not do a DNS lookup for the external hostname "server.company.com", because it
would get 127.0.0.1 as the IP address, and that would be self-defeating)
Of course then, the burden of the HTTPS/MA dialog falls on that process which you create.
Note that this approach is somewhat simplistic and flaky, and will only work if these
external HTTP requests/responses are really simple, and the responses returned by the
external server don't do things like re-directs elsewhere etc..
It would indeed be a lot better to ask the webapp provider to fix their code.
But also note that to simplify your life you may be able, for this separate "proxy"
process, to use an already-existing piece of software such as an Apache httpd webserver
(listening on localhost:8000) (*), or some utility that creates "tunnels"..
(*) or even a dedicated Tomcat instance, provided you find a webapp able to act as a
HTTPS/MA proxy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS
Mutual Authentication connections
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Diarmuid,
On 1/8/15 8:51 AM, dmccrthy wrote:
> Is it possible to configure or hack Tomcat in some way to
> intercept outbound HTTP URL requests from a deployed web
> application and convert them to HTTPS with Mutual Authentication?
Why not just do that directly in your web application?
The short answer is that Tomcat is only in charge of the incoming
requests; what your web application decides to do (e.g. making an
outgoing connection) is not its concern. There may be full Java EE
servers that provide services like what you describe, but Tomcat does not.
> My scenario is:
>
> * 3rd party web application that makes client invocations to a
> server that requires HTTPS with Mutual Authentication * I don’t
> know what framework the web application uses or how it creates the
> HTTP client connections * I can’t make changes to the 3rd party
> application
I see. Can you change the URL that the 3rd party application uses to
call-out?
> I have investigated the below but they don’t seem to offer a
> solution
>
> * Adding Custom Resource Factories -
> http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-
> <http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html>
>
>
howto.html
> <http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html>.
> This requires changes to the client application * HTTP connector -
> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html. This is
> for the Tomcat web server, not for outbound client connections
Nah, what you'd want to do is register a URL protocol stream handler,
and then use that special URL which would then call your code. Your
code can decorate the connection however it wants.
What you are really trying to do is a MITM attack against your own
software.
You can check out this project on SourceForge which has all the source
code available to register a protocol handler. You'd have to write the
HTTP-to-HTTPS stuff, though.
https://sourceforge.net/projects/tuc/
> I have successfully configured the server and can make SoapUI calls
> to it using HTTPS and Mutual Authentication. If I had control of
> the client code I would use HttpClient and accomplish it that way.
>
> For the Tomcat client application I have searched Google,
> Stackoverflow, and the Tomcat wiki and mail archives but all
> HTTPS/Mutual Authentication solutions I can find refer to Tomcat as
> the web server, not to web applications making outbound connections
> from a Tomcat instance.
>
> If there is no option to configure Tomcat then the only options I
> can think of are below, but if anyone has any other insights it
> would be much appreciated.
>
> 1) Write a between the Tomcat “client” instance and the HTTPS/MA
> endpoint 2) Find out the framework/socket factory/url connection
> factory the 3rdparty web app uses and override it with a Tomcat
> plugin 3) Raise a feature request with the 3rd party vendor to
> support HTTPS/MA
Ultimately, #4 is the right solution: you should start there and only
resort to heroic measures if they either say "no" or tell you that the
timeframe is going to be very long.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUrpdpAAoJEBzwKT+lPKRYWFMP/A7f59Oo5O/zVaxXCnR49OuJ
0mCJN8NY3ocnABjmeCGM0kTSEgNilCfSYXsFcl3sGLLpdnmORavSNe0fZxYJV/Fu
ZPZ6VAVwAoVah/snwq9ZXA5T3U0ecyCVYUJXSXPVZgeHUcoebwRYVYTNABpYN2O7
GHPuv8X2iUJPNJN6pBCx2j8oAVZTOCLBKcjTShxf4qJNotl5X/gDU5OVPQ7Lss6m
iAujUz322/aA13tXddVDmAxnDdVQcbItTmahpxoICkKouDHheT/GefCk2A1T+aoC
z+NgrgNGY9TVpl44RxYvwvvUkd2x1DgQXEeILzKvHqiF6bWPii8/Nn4XkzGog/S6
kFCM18Yxw8cPEVuvXgtjW9TB5xu2SjinzSFgyPDOaleE1RN98NJwUPAJSuoUT13H
bOEcXc8RHmBtgQ4H7ZbPPakiQYCLPW7LWvwAcJbY5yCQ1Rp9LEQ5XiRTP7BwSuXi
JT9p/T7wLmdsXQ4taKLvCMyOV0Luagu3aJiEtCmzA1xZC5Iyb4zcWsnSUsXDbNo1
NmHMamItyuHKA+7tMDTF/rtCTgAzb/cLgiMr77VUgq2mRCMiT0k9fW5GR5ir3wYZ
cK2/2PM7z0vxVETQlu9rzgGEGiaGi1t27nSlK7akKRP9PDlaP8h340Ru+v3VadVD
TmwnRQyf1zzk5X92oVV5
=N2uG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org