You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by John Smith <to...@gmail.com> on 2014/08/01 20:55:02 UTC
Restricting SSL access within webapp
In my webapp there's a directory '/admin' that's protected under SSL. Users
are forced to use SSL via a security constraint in web.xml. It works great.
As mentioned in the docs and other places, it would be good to prevent SSL
everywhere else on the site, but I searched around and couldn't find
anything that works.I tried adding another security constraint with
transport guarantee set to NONE for url-pattern '/*' but it didn't prevent
https access to the site as a whole.
What's the correct way to selectively restrict https to only one area of a
webapp?
TIA,
John
Re: Restricting SSL access within webapp
Posted by Leo Donahue <do...@gmail.com>.
On Fri, Aug 1, 2014 at 1:55 PM, John Smith <to...@gmail.com> wrote:
> In my webapp there's a directory '/admin' that's protected under SSL. Users
> are forced to use SSL via a security constraint in web.xml. It works great.
>
> I would also agree with Chuck and James.
Can you not move this admin app to another instance of Tomcat? Why dangle
it out there on the same server that has all your other non-SSL required
webapps?
Just asking.
leo
Re: Restricting SSL access within webapp
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 8/1/14 4:54 PM, David Kerber wrote:
> I don't think the problem is so much bandwidth as it is server CPU.
> Encryption and decryption are very cpu-intensive tasks.
Not to mention client CPU. (Let's face it, if somebody's on dial-up,
they're probably on an old, slow box, too. Like my G4 "bionic desk lamp"
iMac.)
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting SSL access within webapp
Posted by John Smith <to...@gmail.com>.
All, Thanks for the thoughtful advice and replies.
To answer a few questions, belatedly, yes it would be an option to move the
admin tools to another instance of TC, as Leo suggested -- in a way a
better one, since it wouldn't need session replication, could exist on a
single server since the traffic would be be trivial, and would be
potentially more secure. I'll probably do this in the long term.
If not that, then url-rewrites or a filter to bounce users out of https is
another simpler option, as Chris suggested.
Based on the information about SSL not being that expensive, I'll just
leave it in for now, at the clients discretion, as Charles originally
suggested. Our user base is probably not going to suddenly all jump on
https, so I can watch and see if it affects performance. The area that
mandatorily requires SSL is configured with a security constraint -- for
the rest of the site, I'll leave it up to the user.
Best,
John
Re: Restricting SSL access within webapp
Posted by Ognjen Blagojevic <og...@gmail.com>.
Chris,
On 4.8.2014 22:47, Christopher Schultz wrote:
> Encryption is more expensive than /not/ encrypting, but it's much
> harder on the server (many connections) than it is on the client
> (single-digit). Since these days, everyone is disabling compression
> for SSL, the biggest problem for a dial-up connection for SSL would be
> the increased payload size.
For most use-cases, encryption is not that expensive anymore, even on
the server-side. More info here:
http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose
https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting SSL access within webapp
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 8/4/14, 11:34 AM, Mark H. Wood wrote:
> On Fri, Aug 01, 2014 at 07:54:03PM -0400, David Kerber wrote:
>> On 8/1/2014 6:06 PM, James H. H. Lampert wrote:
>>>>> Why would you want to do that? Other than a few extra
>>>>> server CPU cycles, what's the harm in allowing SSL anywhere
>>>>> at the client's discretion?
>>>
>>> I'm with Chuck on that one.
>>>
>>>> From the docs:
>>>>
>>>> Also, while the SSL protocol was designed to be as efficient
>>>> as securely possible, encryption/decryption is a
>>>> computationally expensive process from a performance
>>>> standpoint.
>>>
>>> Well, I'll say that I find it rather irritating, when on my
>>> dial-up (YES, DIAL-UP) at home, that Google unilaterally
>>> insists on HTTPS unless you're signed on, and explicitly opt
>>> out of it.
>>>
>>> But then again, there are a LOT of web sites that are
>>> immensely bandwidth-intensive, and actively hostile to older
>>> browsers (that may nonetheless be the newest browsers available
>>> for a given combination of hardware and OS), all for no good
>>> reason (other than adware and spyware), and SSL is only a small
>>> part of that unnecessary waste of bandwidth.
>>>
>>> But that said, I think that when there's no overriding security
>>> reason to require SSL, and no overriding bandwidth limitation
>>> reason to prohibit it, it should be the user's call on whether
>>> to use HTTP or HTTPS.
>>
>> I don't think the problem is so much bandwidth as it is server
>> CPU. Encryption and decryption are very cpu-intensive tasks.
>
> Negotiating the session key is expensive, but it happens once per
> short session, and at long intervals for a long session. Most of
> the session uses symmetric encryption, which is far, far cheaper.
+1
Encryption is more expensive than /not/ encrypting, but it's much
harder on the server (many connections) than it is on the client
(single-digit). Since these days, everyone is disabling compression
for SSL, the biggest problem for a dial-up connection for SSL would be
the increased payload size.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJT3/FtAAoJEBzwKT+lPKRY7lMP/1NCWSHwdY0NzitW8p/mfqdG
fkXwSGwzG26n6sC/vgdh1i1QA0nzqZvztCO1nMMLXhrvL4goh7WtbTH9n0Duv18X
TQM5sNhG/GSjx3fSRFeVSW/fwjvNa5p4y1Wrsu2Ax/wRZn2Z43HmdFscy3WhbTL1
PRB5oXjLOj2p7kOY8uo/GZns1D6zCnAh5i2ElGACfvqWXa6h39wZZ5jYNSioatAk
rfMcbw4z0zHUEvRhmsckm5WrLLwuvJN+xOHlITW2D1hh1NV8cAKjp7gCngkuo/4l
H14gGrq+LsWjjPfuE7xKzqrFtT+6FuvIJbPvmdIey95pi1joF9FUT5oB6LxVaWO0
0iijDHnGcbI2da1sa0zR6RWkqh7tx6zxxskeZk+SGEyclHjleX9BIkEN+zX5lIhp
bamoKljgSCnvuW7WNVSd6qxbXqkv9r8SmSiLEVdBFdHQXLLeyV3UY25M2XshQTDe
8RQbeO3yqHz5+KEWl+9L+XOt58MHDUEppbKcBJe6Vqme4BNuPOcFn63sqAq2HCi3
my0M2kJJjv5n7CtWCDRLiXzt1S3dvC7rO5wggp9hh4NP0T7zaw454EHlNihfUElg
zDvU5PDNdvguT5/ICO9PTR6EhE4O8ngrYLYxgyxwXBE8jWGpq7JozQ8wBhp5rdLX
3qmKrlMdCDbh/3gd+ELr
=A92+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting SSL access within webapp
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Fri, Aug 01, 2014 at 07:54:03PM -0400, David Kerber wrote:
> On 8/1/2014 6:06 PM, James H. H. Lampert wrote:
> >>> Why would you want to do that? Other than a few extra server CPU
> >>> cycles,
> >>> what's the harm in allowing SSL anywhere at the client's discretion?
> >
> > I'm with Chuck on that one.
> >
> >> From the docs:
> >>
> >> Also, while the SSL protocol was designed to be as efficient as securely
> >> possible, encryption/decryption is a computationally expensive process
> >> from
> >> a performance standpoint.
> >
> > Well, I'll say that I find it rather irritating, when on my dial-up
> > (YES, DIAL-UP) at home, that Google unilaterally insists on HTTPS unless
> > you're signed on, and explicitly opt out of it.
> >
> > But then again, there are a LOT of web sites that are immensely
> > bandwidth-intensive, and actively hostile to older browsers (that may
> > nonetheless be the newest browsers available for a given combination of
> > hardware and OS), all for no good reason (other than adware and
> > spyware), and SSL is only a small part of that unnecessary waste of
> > bandwidth.
> >
> > But that said, I think that when there's no overriding security reason
> > to require SSL, and no overriding bandwidth limitation reason to
> > prohibit it, it should be the user's call on whether to use HTTP or HTTPS.
>
> I don't think the problem is so much bandwidth as it is server CPU.
> Encryption and decryption are very cpu-intensive tasks.
Negotiating the session key is expensive, but it happens once per
short session, and at long intervals for a long session. Most of the
session uses symmetric encryption, which is far, far cheaper.
--
Mark H. Wood
Lead Technology Analyst
University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu
Re: Restricting SSL access within webapp
Posted by David Kerber <dc...@verizon.net>.
On 8/1/2014 6:06 PM, James H. H. Lampert wrote:
>>> Why would you want to do that? Other than a few extra server CPU
>>> cycles,
>>> what's the harm in allowing SSL anywhere at the client's discretion?
>
> I'm with Chuck on that one.
>
>> From the docs:
>>
>> Also, while the SSL protocol was designed to be as efficient as securely
>> possible, encryption/decryption is a computationally expensive process
>> from
>> a performance standpoint.
>
> Well, I'll say that I find it rather irritating, when on my dial-up
> (YES, DIAL-UP) at home, that Google unilaterally insists on HTTPS unless
> you're signed on, and explicitly opt out of it.
>
> But then again, there are a LOT of web sites that are immensely
> bandwidth-intensive, and actively hostile to older browsers (that may
> nonetheless be the newest browsers available for a given combination of
> hardware and OS), all for no good reason (other than adware and
> spyware), and SSL is only a small part of that unnecessary waste of
> bandwidth.
>
> But that said, I think that when there's no overriding security reason
> to require SSL, and no overriding bandwidth limitation reason to
> prohibit it, it should be the user's call on whether to use HTTP or HTTPS.
I don't think the problem is so much bandwidth as it is server CPU.
Encryption and decryption are very cpu-intensive tasks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting SSL access within webapp
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
>> Why would you want to do that? Other than a few extra server CPU cycles,
>> what's the harm in allowing SSL anywhere at the client's discretion?
I'm with Chuck on that one.
> From the docs:
>
> Also, while the SSL protocol was designed to be as efficient as securely
> possible, encryption/decryption is a computationally expensive process from
> a performance standpoint.
Well, I'll say that I find it rather irritating, when on my dial-up
(YES, DIAL-UP) at home, that Google unilaterally insists on HTTPS unless
you're signed on, and explicitly opt out of it.
But then again, there are a LOT of web sites that are immensely
bandwidth-intensive, and actively hostile to older browsers (that may
nonetheless be the newest browsers available for a given combination of
hardware and OS), all for no good reason (other than adware and
spyware), and SSL is only a small part of that unnecessary waste of
bandwidth.
But that said, I think that when there's no overriding security reason
to require SSL, and no overriding bandwidth limitation reason to
prohibit it, it should be the user's call on whether to use HTTP or HTTPS.
--
JHHL
_
( )
X
/ \ ASCII ribbon for plain text email
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting SSL access within webapp
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
John,
On 8/1/14, 5:43 PM, John Smith wrote:
> On Fri, Aug 1, 2014 at 4:34 PM, Caldarale, Charles R <
> Chuck.Caldarale@unisys.com> wrote:
>
>>> From: John Smith [mailto:tomcat.random@gmail.com] Subject:
>>> Restricting SSL access within webapp
>>
>>> What's the correct way to selectively restrict https to only
>>> one area of
>> a webapp?
>>
>> Why would you want to do that? Other than a few extra server CPU
>> cycles, what's the harm in allowing SSL anywhere at the client's
>> discretion?
>>
>> - Chuck
>>
>
>> From the docs:
>
> Also, while the SSL protocol was designed to be as efficient as
> securely possible, encryption/decryption is a computationally
> expensive process from a performance standpoint. It is not strictly
> necessary to run an entire web application over SSL, and indeed a
> developer can pick and choose which pages require a secure
> connection and which do not. For a reasonably busy site, it is
> customary to only run certain pages under SSL, namely those pages
> where sensitive information could possibly be exchanged.
>
> Unfortunately how to do this isn't explained. I might use a filter.
> Our site handles 500,000 visitors a day on two TC instances.
> Believe me, I need to consider performance costs.
You'd have to determine which URL patterns are "okay" for dropping
HTTPS and then do a protocol-changing redirect. You can do this with a
custom Filter, or you might even be able to use url-rewrite to do the
job... I've never tried to configure that to switch protocols and do a
self-redirect.
Writing the code yourself should be easy, but you should probably give
url-rewrite a try first.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJT3A+5AAoJEBzwKT+lPKRYTVQP/0wfHnoTIn0KAagCY7zRUlml
jbWW9GHtOpxt3ZV7BxVdAkC4VipTm/apiTQnbPOMpqzzoQS4fuw2ccc837M7u8lW
ZpqVN5yvaQPe21wGUuEWT79wi0gXZhZe6eUb2B+PHcqwWz8DPYLAedGYYCEsZAYb
Rtrztb9HnVRSYaiQJOr3pvzmrkuoOT8db1qhuggtOzsSFXDcTcQzYLF3iaK99cDc
WkZlOsbwV4dpMARqfrKsM0b8obUXS96qjjB4zWtmczp12vjhtYQI9w/I1lTSKnDl
L26DcCnoDJIi3wIY/Omm6sD/0e1BmHfC+2Pxv84HVIvGgRjG0sOLCDIPxFLfw6C4
LlomNmdPzFlwebkTjUc5hC3SQoNk5+a3LM6TFiouf4vw7wnpsNhyvt9odU4bGUv3
2eSiS9n1AMP/Zrb/6Ks92THXY1XzH17a7jCMXpwDxSYqXnYsEeUlB+oPLadkBe38
bMm5P9IXidccm0Fuvha6I042Xd/W++siA+fK3OChEI1FsDgrIhXQmmMRn39a7GOV
GmX390FMxfUfxqQMrkgaKYqwYhTzS9rnhy0shZyOsnZvTASJU8X6qi2BcLE8HEZL
4OKWWfnHDf744NM18fie6ltCjs2LfalyyU8dm741j6CYBraBd9dlgGEYOz58kOAx
XpVVogN5dbaL3erz4or+
=udcL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Restricting SSL access within webapp
Posted by Konstantin Preißer <kp...@apache.org>.
Hi,
> -----Original Message-----
> From: John Smith [mailto:tomcat.random@gmail.com]
> Sent: Friday, August 1, 2014 11:43 PM
> To: Tomcat Users List
> Subject: Re: Restricting SSL access within webapp
>
> On Fri, Aug 1, 2014 at 4:34 PM, Caldarale, Charles R <
> Chuck.Caldarale@unisys.com> wrote:
>
> > > From: John Smith [mailto:tomcat.random@gmail.com]
> > > Subject: Restricting SSL access within webapp
> >
> > > What's the correct way to selectively restrict https to only one area of
> > a webapp?
> >
> > Why would you want to do that? Other than a few extra server CPU cycles,
> > what's the harm in allowing SSL anywhere at the client's discretion?
> >
> > - Chuck
> >
>
> From the docs:
>
> Also, while the SSL protocol was designed to be as efficient as securely
> possible, encryption/decryption is a computationally expensive process from
> a performance standpoint. It is not strictly necessary to run an entire web
> application over SSL, and indeed a developer can pick and choose which
> pages require a secure connection and which do not. For a reasonably busy
> site, it is customary to only run certain pages under SSL, namely those
> pages where sensitive information could possibly be exchanged.
>
> Unfortunately how to do this isn't explained. I might use a filter. Our
> site handles 500,000 visitors a day on two TC instances. Believe me, I need
> to consider performance costs.
Note, that putting a complete website on SSL (and not only parts of it) can help protecting users from SSL Stripping attacks: This is where an Man-In-The-Middle manipulates the HTTP traffic, so that all references to HTTPS (e.g. a Link to a "Login" form) are substituted by HTTP ones, so that when the user goes to a part of the website which should be accessed over SSL, he accesses it over plain HTTP so the attacker can intercept all traffic (assuming the user doesn't know if the login part of this particular website should only be accessed over HTTPS and not HTTP).
Therefore, I think it’s a good practice (at least for security-sensitive sites and if the users are not so technologically adept to know to access e.g. the Login page only over HTTPS) to use SSL for the whole website, not only for a part of it. Additionally, HTTP Strict Transport Security [1] will help to prevent that the user accidentally views a website over HTTP instead of HTTPS, and requires that the whole website uses SSL.
Regards,
Konstantin Preißer
[1] http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting SSL access within webapp
Posted by John Smith <to...@gmail.com>.
On Fri, Aug 1, 2014 at 4:34 PM, Caldarale, Charles R <
Chuck.Caldarale@unisys.com> wrote:
> > From: John Smith [mailto:tomcat.random@gmail.com]
> > Subject: Restricting SSL access within webapp
>
> > What's the correct way to selectively restrict https to only one area of
> a webapp?
>
> Why would you want to do that? Other than a few extra server CPU cycles,
> what's the harm in allowing SSL anywhere at the client's discretion?
>
> - Chuck
>
>From the docs:
Also, while the SSL protocol was designed to be as efficient as securely
possible, encryption/decryption is a computationally expensive process from
a performance standpoint. It is not strictly necessary to run an entire web
application over SSL, and indeed a developer can pick and choose which
pages require a secure connection and which do not. For a reasonably busy
site, it is customary to only run certain pages under SSL, namely those
pages where sensitive information could possibly be exchanged.
Unfortunately how to do this isn't explained. I might use a filter. Our
site handles 500,000 visitors a day on two TC instances. Believe me, I need
to consider performance costs.
RE: Restricting SSL access within webapp
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: John Smith [mailto:tomcat.random@gmail.com]
> Subject: Restricting SSL access within webapp
> What's the correct way to selectively restrict https to only one area of a webapp?
Why would you want to do that? Other than a few extra server CPU cycles, what's the harm in allowing SSL anywhere at the client's discretion?
- 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