Re: Restricting SSL access within webapp
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
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 signature.asc Description: Digital signature
Re: Restricting SSL access within webapp
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting SSL access within webapp
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Restricting SSL access within webapp
Hi, -Original Message- From: John Smith [mailto:tomcat.ran...@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.caldar...@unisys.com wrote: From: John Smith [mailto:tomcat.ran...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Restricting SSL access within webapp
From: John Smith [mailto:tomcat.ran...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting SSL access within webapp
On Fri, Aug 1, 2014 at 4:34 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: John Smith [mailto:tomcat.ran...@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
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting SSL access within webapp
-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.caldar...@unisys.com wrote: From: John Smith [mailto:tomcat.ran...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting SSL access within webapp
On Fri, Aug 1, 2014 at 1:55 PM, John Smith tomcat.ran...@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
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting SSL access within webapp
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
