Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Mon, 4 Aug 2014 11:34:13 -0400
From: "Mark H. Wood" <mwood@IUPUI.Edu>
To: users@tomcat.apache.org
Subject: Re: Restricting SSL access within webapp
Message-ID: <20140804153413.GA14148@IUPUI.Edu>
References: 
 <CAPhkb91kjT4TiL_ZaBC1+6NJsiMS-q+Y3Y0Uo-SJ5oQvhx99PQ@mail.gmail.com>
 <99C8B2929B39C24493377AC7A121E21FEC2F6BEFC7@USEA-EXCH8.na.uis.unisys.com>
 <CAPhkb93xG1M59qYHS_v+1w2bU25PDhTXo3qXbh2w9YiK=NZGvg@mail.gmail.com>
 <53DC0F79.1010205@touchtonecorp.com>
 <53DC289B.9080604@verizon.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK"
Content-Disposition: inline
In-Reply-To: <53DC289B.9080604@verizon.net>
User-Agent: Mutt/1.5.22 (2013-10-16)

--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 secure=
ly
> >> 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 HTT=
PS.
>=20
> I don't think the problem is so much bandwidth as it is server CPU.=20
> 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.

--=20
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

--YZ5djTAD1cGYuMQK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEAREIAAYFAlPfp/UACgkQs/NR4JuTKG/GuwCfSU96xwtnEBgXzUT1W6gfHcoe
BT8AoJmI0h6z2Csu6B/xETuXMnyykHEf
=gJbY
-----END PGP SIGNATURE-----

--YZ5djTAD1cGYuMQK--