You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Rafael Liu <ra...@gmail.com> on 2011/06/20 23:20:07 UTC
Setting SSL for login pages
So guy,
I want the user to be redirected to HTTPS once he hits an authenticated
page. So I think it would be natural something like this:
<security-constraint>
<web-resource-collection>
<web-resource-name>SSL login</web-resource-name>
<url-pattern>/login/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>MyRealm</realm-name>
<form-login-config>
<form-login-page>/login/login.jsp</form-login-page>
<form-error-page>/login/error.jsp</form-error-page>
</form-login-config>
</login-config>
The problem is the FormAuthenticator Valve uses a forward, so the URL used
is the one of the target page, not the login page. That means that the
/login/login.jsp URL is never requested and the security constraint is never
applied. The same way an Apache HTTPD proxy can't know whether the request
resulted in a login page or not.
As I see, the way it is, all authenticated pages must be set to CONFIDENTIAL
also (in case the user is not authenticated and ends up in the login page).
But if the user IS authenticated he is forced to use HTTPS too, and that I
was trying to avoid.
Am I missing something?
--
Rafael Liu
+55 61 9608-7722
http://rafaelliu.net
Re: Setting SSL for login pages
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rafael,
On 6/21/2011 12:05 PM, Rafael Liu wrote:
> I agree it's kind of a philosophical question but I see some real
> implications. Anyway, for the record, as a quick and dirty fix I set the
> full URL with https schema in /form@action. But the hosting page isn't HTTPS
> and the user may feel unsecure..
I have posted a recipe to this list once or twice that should work.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4AxgEACgkQ9CaO5/Lv0PCaaQCgwrsz3zNYNuT8KM7OZ7ZQbhcF
z4cAoIZuRO71h6b+uEXeFqY3K6j/6FUG
=ZH0o
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting SSL for login pages
Posted by Rafael Liu <ra...@gmail.com>.
Well, if it's the spec I guess there's no much to argue. Maybe turn it into
an option, but I already got the feeling of the community. I won't insist as
this is my specific requirement and may not be of use to a wide range of the
community.
Mark, there could be a MIM attack but that's yet another security issue. I
guess you are missing my point. The way it's being discussed (point all
security flaws), it's like we should also constraint the use of BASIC/DIGEST
auth to be used only with CONFIDENTIAL transport, enforce CLIENT-CERT, etc.
The point is not making the system all secure, is having the ability to
CHOOSE what to secure (which Servlet/JSP spec already allows, I'm bringing
to discussion just another degree).
Actually this MIM attack is introduced by the workaround, I agree it would
be better to specify the login page in the security constraints and that's
actually the reason for this email.
On Tue, Jun 21, 2011 at 1:25 PM, Mark Thomas <ma...@apache.org> wrote:
> On 21/06/2011 17:05, Rafael Liu wrote:
> > Hey Chris,
> >
> > as you said, each problem compromise different kinds of things: account
> vs
> > credentials. And I think they have different kind of consequences and can
> > be, each one , dangerous its own way. I brought the discussion into the
> list
> > because I thought it was relevant.
> >
> > Looking at the code, a fix would be quite simple: replacing the forward()
> by
> > a send(). To have the same behaviour as today to the end user, a few more
> > things should be done, because we would be changing from a POST to a GET,
> > but AFAIK it's a matter of saving the target URL as a request parameter.
> > Back button, bookmark and normal login should work.
>
> The spec requires that POST is used.
>
> > I agree it's kind of a philosophical question but I see some real
> > implications. Anyway, for the record, as a quick and dirty fix I set the
> > full URL with https schema in /form@action. But the hosting page isn't
> HTTPS
> > and the user may feel unsecure..
>
> And rightly so. If the login page is not delivered over SSL that opens
> the way for various MITM middle attacks.
>
> > On Tue, Jun 21, 2011 at 11:46 AM, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> > Rafael,
> >
> > On 6/20/2011 8:12 PM, Rafael Liu wrote:
> >>>> Good point Chuck. I agree with you, the webapp wouldn't be all
> secured.
> > But
> >>>> there are 2 different things here:
> >>>>
> >>>> * the issue with the plain password
> >>>> * the issue with session hijacking
> >
> > This does become somewhat of a philosophical question. I agree that
> > credentials should always be secured. If the service itself is not
> > particularly sensitive, I think it's acceptable to use SSL only during
> > authentication.
>
> That is very much the minority view. I find it very hard to imagine any
> scenario where a user needs to be authenticated (and hence the password
> needs to be protected) but it is OK for the session to be compromised
> without that being considered a security breach.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Rafael Liu
+55 61 9608-7722
http://rafaelliu.net
Re: Setting SSL for login pages
Posted by Mark Thomas <ma...@apache.org>.
On 21/06/2011 17:05, Rafael Liu wrote:
> Hey Chris,
>
> as you said, each problem compromise different kinds of things: account vs
> credentials. And I think they have different kind of consequences and can
> be, each one , dangerous its own way. I brought the discussion into the list
> because I thought it was relevant.
>
> Looking at the code, a fix would be quite simple: replacing the forward() by
> a send(). To have the same behaviour as today to the end user, a few more
> things should be done, because we would be changing from a POST to a GET,
> but AFAIK it's a matter of saving the target URL as a request parameter.
> Back button, bookmark and normal login should work.
The spec requires that POST is used.
> I agree it's kind of a philosophical question but I see some real
> implications. Anyway, for the record, as a quick and dirty fix I set the
> full URL with https schema in /form@action. But the hosting page isn't HTTPS
> and the user may feel unsecure..
And rightly so. If the login page is not delivered over SSL that opens
the way for various MITM middle attacks.
> On Tue, Jun 21, 2011 at 11:46 AM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> Rafael,
>
> On 6/20/2011 8:12 PM, Rafael Liu wrote:
>>>> Good point Chuck. I agree with you, the webapp wouldn't be all secured.
> But
>>>> there are 2 different things here:
>>>>
>>>> * the issue with the plain password
>>>> * the issue with session hijacking
>
> This does become somewhat of a philosophical question. I agree that
> credentials should always be secured. If the service itself is not
> particularly sensitive, I think it's acceptable to use SSL only during
> authentication.
That is very much the minority view. I find it very hard to imagine any
scenario where a user needs to be authenticated (and hence the password
needs to be protected) but it is OK for the session to be compromised
without that being considered a security breach.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting SSL for login pages
Posted by Rafael Liu <ra...@gmail.com>.
Hey Chris,
as you said, each problem compromise different kinds of things: account vs
credentials. And I think they have different kind of consequences and can
be, each one , dangerous its own way. I brought the discussion into the list
because I thought it was relevant.
Looking at the code, a fix would be quite simple: replacing the forward() by
a send(). To have the same behaviour as today to the end user, a few more
things should be done, because we would be changing from a POST to a GET,
but AFAIK it's a matter of saving the target URL as a request parameter.
Back button, bookmark and normal login should work.
I agree it's kind of a philosophical question but I see some real
implications. Anyway, for the record, as a quick and dirty fix I set the
full URL with https schema in /form@action. But the hosting page isn't HTTPS
and the user may feel unsecure..
On Tue, Jun 21, 2011 at 11:46 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rafael,
>
> On 6/20/2011 8:12 PM, Rafael Liu wrote:
> > Good point Chuck. I agree with you, the webapp wouldn't be all secured.
> But
> > there are 2 different things here:
> >
> > * the issue with the plain password
> > * the issue with session hijacking
>
> This does become somewhat of a philosophical question. I agree that
> credentials should always be secured. If the service itself is not
> particularly sensitive, I think it's acceptable to use SSL only during
> authentication.
>
> Be aware that some authentication schemes (i.e. HTTP Auth) send
> credentials on every request, not just the first time they are challenged.
>
> > The first one first gives the hacker a private information about the user
> > (which can even the used by the user somewhere else). The hacker will
> have
> > the actual user's credentials, and will be able to login at will.
> >
> > The second one doesn't necessarily exposes user's informations. The
> hacker
> > can pretend to be the user, but only for the time of the session. Even
> tho
> > there are tricks to keep the session alive [almos] forever, this is
> > essentially different from having the user's credential.
>
> If the system doesn't require the existing password to be supplied
> (again, in SSL!) in order to do things like change the password, then an
> attacker can hijack the session and then hijack the account. The
> credentials are still safe, but the account is not.
>
> > I see them at different levels of security. Using the same logic, one can
> > say that there's no point in using DIGEST authentication if there's still
> > room for session hijacking. Much like BASIC / DIGEST or CONFIDENTIAL /
> > INTEGRAL provides different levels of security, I think the two cases
> > mentioned also do. Giving these kind of options to the webapp can make
> NFR
> > (like performance) easier to meet and infrastructure easier to configure
> > (like rewriting on Apache).
>
> +1
>
> The right answer is: always think about what you are doing.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4Arq8ACgkQ9CaO5/Lv0PB4VwCgvU23AGCJ/8ChMOJ/RsWuM3zG
> hxQAoKykpgMpWlPX3wL52zi+N0gQep9c
> =xeZL
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Rafael Liu
+55 61 9608-7722
http://rafaelliu.net
Re: Setting SSL for login pages
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rafael,
On 6/20/2011 8:12 PM, Rafael Liu wrote:
> Good point Chuck. I agree with you, the webapp wouldn't be all secured. But
> there are 2 different things here:
>
> * the issue with the plain password
> * the issue with session hijacking
This does become somewhat of a philosophical question. I agree that
credentials should always be secured. If the service itself is not
particularly sensitive, I think it's acceptable to use SSL only during
authentication.
Be aware that some authentication schemes (i.e. HTTP Auth) send
credentials on every request, not just the first time they are challenged.
> The first one first gives the hacker a private information about the user
> (which can even the used by the user somewhere else). The hacker will have
> the actual user's credentials, and will be able to login at will.
>
> The second one doesn't necessarily exposes user's informations. The hacker
> can pretend to be the user, but only for the time of the session. Even tho
> there are tricks to keep the session alive [almos] forever, this is
> essentially different from having the user's credential.
If the system doesn't require the existing password to be supplied
(again, in SSL!) in order to do things like change the password, then an
attacker can hijack the session and then hijack the account. The
credentials are still safe, but the account is not.
> I see them at different levels of security. Using the same logic, one can
> say that there's no point in using DIGEST authentication if there's still
> room for session hijacking. Much like BASIC / DIGEST or CONFIDENTIAL /
> INTEGRAL provides different levels of security, I think the two cases
> mentioned also do. Giving these kind of options to the webapp can make NFR
> (like performance) easier to meet and infrastructure easier to configure
> (like rewriting on Apache).
+1
The right answer is: always think about what you are doing.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4Arq8ACgkQ9CaO5/Lv0PB4VwCgvU23AGCJ/8ChMOJ/RsWuM3zG
hxQAoKykpgMpWlPX3wL52zi+N0gQep9c
=xeZL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting SSL for login pages
Posted by Rafael Liu <ra...@gmail.com>.
On Tue, Jun 21, 2011 at 4:02 AM, André Brunnsberg <
andre.brunnsberg@planmill.com> wrote:
> But if the user has the session then he or she can change the user
> credentials
Actually it depends on how application that implement password change.
Usually for changing the password you need to enter the current password
also.
> (of course only for this site unless the password is shown in
> the system, which would be really bad) or if the user has enough rights
> add a new user which can be used by the hacker.
>
If we start speculating we can reach any scenario.. You are telling me IF
the system has a user registration use case and IF the hacker HAPPENS to get
an admin session, he can add a new user. That the hacker can do if the user
go for a walk and forget to look the screen too.
> Remember how easy it is to hijack cookie files under normal HTTP with the
> Firesheep extension for Firefox.
>
I am not trying to prevent session hijacking. That's not a requirement for
this system. The requirement is to secure the user password. I believe this
is a meaningful requirement.
> Cheers,
> André
>
> -----Original Message-----
> From: Rafael Liu [mailto:rafaelliu@gmail.com]
> Sent: den 21 juni 2011 03:12
> To: Tomcat Users List
> Subject: RE: Setting SSL for login pages
>
> Good point Chuck. I agree with you, the webapp wouldn't be all secured.
> But there are 2 different things here:
>
> * the issue with the plain password
> * the issue with session hijacking
>
> The first one first gives the hacker a private information about the user
> (which can even the used by the user somewhere else). The hacker will have
> the actual user's credentials, and will be able to login at will.
>
> The second one doesn't necessarily exposes user's informations. The hacker
> can pretend to be the user, but only for the time of the session. Even tho
> there are tricks to keep the session alive [almos] forever, this is
> essentially different from having the user's credential.
>
> I see them at different levels of security. Using the same logic, one can
> say that there's no point in using DIGEST authentication if there's still
> room for session hijacking. Much like BASIC / DIGEST or CONFIDENTIAL /
> INTEGRAL provides different levels of security, I think the two cases
> mentioned also do.Giving these kind of options to the webapp can make NFR
> (like performance) easier to meet and infrastructure easier to configure
> (like rewriting on Apache).
>
> What do you think?
>
> On Jun 20, 2011 6:50 PM, "Caldarale, Charles R"
> <Ch...@unisys.com>
> wrote:
> >> From: Rafael Liu [mailto:rafaelliu@gmail.com]
> >> Subject: Setting SSL for login pages
> >
> >> I think it would be natural something like this:
> >
> >> <security-constraint>
> >> <web-resource-collection>
> >> <web-resource-name>SSL login</web-resource-name>
> >> <url-pattern>/login/*</url-pattern>
> >> </web-resource-collection>
> >> <user-data-constraint>
> >> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> >> </user-data-constraint>
> >> </security-constraint>
> >
> > The login pages are usually not specified in the <url-pattern>; only
> > the
> pages to be protected. Login pages are not normally directly accessed by a
> user, but are only presented when the user attempts to access a protected
> page.
> >
> >> As I see, the way it is, all authenticated pages must be set to
> >> CONFIDENTIAL also
> >
> > Not also, instead.
> >
> >> But if the user IS authenticated he is forced to use HTTPS too, and
> >> that I was trying to avoid.
> >
> > Think about it: if the secure traffic is only for the login page,
> > anyone
> could access the not-really-protected pages by sniffing the sessionid used
> on the unsecure connection - you would have no security.
> >
> > - 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Rafael Liu
+55 61 9608-7722
http://rafaelliu.net
RE: Setting SSL for login pages
Posted by André Brunnsberg <an...@planmill.com>.
But if the user has the session then he or she can change the user
credentials (of course only for this site unless the password is shown in
the system, which would be really bad) or if the user has enough rights
add a new user which can be used by the hacker.
Remember how easy it is to hijack cookie files under normal HTTP with the
Firesheep extension for Firefox.
Cheers,
André
-----Original Message-----
From: Rafael Liu [mailto:rafaelliu@gmail.com]
Sent: den 21 juni 2011 03:12
To: Tomcat Users List
Subject: RE: Setting SSL for login pages
Good point Chuck. I agree with you, the webapp wouldn't be all secured.
But there are 2 different things here:
* the issue with the plain password
* the issue with session hijacking
The first one first gives the hacker a private information about the user
(which can even the used by the user somewhere else). The hacker will have
the actual user's credentials, and will be able to login at will.
The second one doesn't necessarily exposes user's informations. The hacker
can pretend to be the user, but only for the time of the session. Even tho
there are tricks to keep the session alive [almos] forever, this is
essentially different from having the user's credential.
I see them at different levels of security. Using the same logic, one can
say that there's no point in using DIGEST authentication if there's still
room for session hijacking. Much like BASIC / DIGEST or CONFIDENTIAL /
INTEGRAL provides different levels of security, I think the two cases
mentioned also do.Giving these kind of options to the webapp can make NFR
(like performance) easier to meet and infrastructure easier to configure
(like rewriting on Apache).
What do you think?
On Jun 20, 2011 6:50 PM, "Caldarale, Charles R"
<Ch...@unisys.com>
wrote:
>> From: Rafael Liu [mailto:rafaelliu@gmail.com]
>> Subject: Setting SSL for login pages
>
>> I think it would be natural something like this:
>
>> <security-constraint>
>> <web-resource-collection>
>> <web-resource-name>SSL login</web-resource-name>
>> <url-pattern>/login/*</url-pattern>
>> </web-resource-collection>
>> <user-data-constraint>
>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>> </user-data-constraint>
>> </security-constraint>
>
> The login pages are usually not specified in the <url-pattern>; only
> the
pages to be protected. Login pages are not normally directly accessed by a
user, but are only presented when the user attempts to access a protected
page.
>
>> As I see, the way it is, all authenticated pages must be set to
>> CONFIDENTIAL also
>
> Not also, instead.
>
>> But if the user IS authenticated he is forced to use HTTPS too, and
>> that I was trying to avoid.
>
> Think about it: if the secure traffic is only for the login page,
> anyone
could access the not-really-protected pages by sniffing the sessionid used
on the unsecure connection - you would have no security.
>
> - 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Setting SSL for login pages
Posted by Rafael Liu <ra...@gmail.com>.
Good point Chuck. I agree with you, the webapp wouldn't be all secured. But
there are 2 different things here:
* the issue with the plain password
* the issue with session hijacking
The first one first gives the hacker a private information about the user
(which can even the used by the user somewhere else). The hacker will have
the actual user's credentials, and will be able to login at will.
The second one doesn't necessarily exposes user's informations. The hacker
can pretend to be the user, but only for the time of the session. Even tho
there are tricks to keep the session alive [almos] forever, this is
essentially different from having the user's credential.
I see them at different levels of security. Using the same logic, one can
say that there's no point in using DIGEST authentication if there's still
room for session hijacking. Much like BASIC / DIGEST or CONFIDENTIAL /
INTEGRAL provides different levels of security, I think the two cases
mentioned also do.Giving these kind of options to the webapp can make NFR
(like performance) easier to meet and infrastructure easier to configure
(like rewriting on Apache).
What do you think?
On Jun 20, 2011 6:50 PM, "Caldarale, Charles R" <Ch...@unisys.com>
wrote:
>> From: Rafael Liu [mailto:rafaelliu@gmail.com]
>> Subject: Setting SSL for login pages
>
>> I think it would be natural something like this:
>
>> <security-constraint>
>> <web-resource-collection>
>> <web-resource-name>SSL login</web-resource-name>
>> <url-pattern>/login/*</url-pattern>
>> </web-resource-collection>
>> <user-data-constraint>
>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>> </user-data-constraint>
>> </security-constraint>
>
> The login pages are usually not specified in the <url-pattern>; only the
pages to be protected. Login pages are not normally directly accessed by a
user, but are only presented when the user attempts to access a protected
page.
>
>> As I see, the way it is, all authenticated pages must be set
>> to CONFIDENTIAL also
>
> Not also, instead.
>
>> But if the user IS authenticated he is forced to use HTTPS
>> too, and that I was trying to avoid.
>
> Think about it: if the secure traffic is only for the login page, anyone
could access the not-really-protected pages by sniffing the sessionid used
on the unsecure connection - you would have no security.
>
> - 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: Setting SSL for login pages
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Rafael Liu [mailto:rafaelliu@gmail.com]
> Subject: Setting SSL for login pages
> I think it would be natural something like this:
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>SSL login</web-resource-name>
> <url-pattern>/login/*</url-pattern>
> </web-resource-collection>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
The login pages are usually not specified in the <url-pattern>; only the pages to be protected. Login pages are not normally directly accessed by a user, but are only presented when the user attempts to access a protected page.
> As I see, the way it is, all authenticated pages must be set
> to CONFIDENTIAL also
Not also, instead.
> But if the user IS authenticated he is forced to use HTTPS
> too, and that I was trying to avoid.
Think about it: if the secure traffic is only for the login page, anyone could access the not-really-protected pages by sniffing the sessionid used on the unsecure connection - you would have no security.
- 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