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
