1

I was reading this blog(http://googlepublicpolicy.blogspot.com/2009/06/https-security-for-web-applications.html) posted by google on not enabling HTTPS for gmail by default. One of the paragraph says as below.

Unless there are negative effects on the user experience or it's otherwise impractical, we intend to turn on HTTPS by default more broadly, hopefully for all Gmail users. We're also considering how to make this work best for other apps including Google Docs and Google Calendar (we offer free HTTPS for those apps as well).

I didn't understand what negative effects can there be, by shifting over to HTTPS. Is there a benchmarking done on the peformance of HTTP and HTTPS.

I feel that https actually involves some additional protocol messages initially and data encryption later on. Can't these issues be taken care by having SSL browser code to be loaded by default etc..

Thank you Bala

Boolean
  • 14,266
  • 30
  • 88
  • 129
  • please run a quick google search for "overhead of https" and you'l find a paper on the very first page that looks at the overhead. – atk Dec 12 '09 at 13:43

3 Answers3

2

The major cost of https is generally the key exchange at the start of the session, which is CPU intensive. Hardward acceleration is available to handle this. If it is an EV cert then it will also need revocation checking. Actual encryption of the stream is relatively cheap. Sun Niagara II has "zero overhead" encryption which uses spare FPU cycles to do the processing.

Tom Hawtin - tackline
  • 145,806
  • 30
  • 211
  • 305
  • the Sun Niagra processor line is horrible for encryption, unless (and only unless) you've recompiled to have SSL running using the encryption accelerators: the base CPU has 32 integer pipelines, but they all share one FPU - it's dog-ass-slow on encryption – warren Dec 14 '09 at 15:42
  • Woah. Why would you not compile to have the OS handle SSL? That kind of seems a reasonable thing to me. The Niagara 1 did have a single FPU, but didn't have this feature. The Niagara 2 (which has been shipping in servers for over two years) has 8 FPUs - one per core. It seems an unusual workload that would always keep both floating point and encryption busy - probably one or the other is going to be trivial. http://en.wikipedia.org/wiki/UltraSPARC_T2 – Tom Hawtin - tackline Dec 14 '09 at 16:08
2

The overhead of https is entirely in the key-negotiation phase during the start of the session. If the keys are set to expire in short order, they may need to be renegotiated frequently.

However, if you're living on 128-bit SSL (most common that I've seen), key generation and exchange is a very short process.

Try timing it from two machines on a network - one connecting on SSL, and the other on plaintext: it's in the single-digit percentages, and only truly noticeable at the beginning of the session.

Browser-based activity is almost always user-bound, not machine-bound.

warren
  • 32,620
  • 21
  • 85
  • 124
0

With HTTPS all traffic between the user and the server hosting the information is encrypted to be seen only by the user and the server. This makes it very difficult for a man in the middle attack. This requires additional resources on both sides to interpret what is being communicated.

Typically on high demand servers on HTTPS there is a limit to what sections of the site uses SSL or there are encryption cards that offload the encryption process.

monksy
  • 14,156
  • 17
  • 75
  • 124
  • If the additional resources are only CPU bound, I feel that majority of the machines can handle that overhead. If it still is an overhead, then I feel it might be problem with implementation and a better implementation probably in kernel can be thought of. – Boolean Dec 12 '09 at 05:06
  • With HTTPS there is an added layer of encryption per user. It will cut your performance down by a good factor. – monksy Dec 12 '09 at 05:50
  • I am still confused. Which one is higher? Overhead of doing encryption or key exchange. Thanks. – Boolean Dec 14 '09 at 19:30
  • I would say doing the encryption, since its per user/session. – monksy Dec 14 '09 at 20:00