In this post we will deal with the most vital facts and the pros and cons concerning the HTTPS vs HTTP issue. Besides the security advantage, we will consider the main things that make a difference: caching, performance issue, virtual hosting issue and others.
Pros for HTTPS
- The HTTP protocol is not suitable for use in a wide range of applications because it can be so easily monitored and replayed. Capturing passwords used to access a banking web site or replaying requests that trigger financial transactions are just a couple of an unlimited number of theft methods.
- Many crawlers such as search engine bots cannot handle SSL encrypted pages.
Downsides of HTTPS
- Intermediate caching server and client won’t be able to speed anything up (it’s all encrypted, and each time it uses a different open key).
- Virtual hosting difficulty
The above-mentioned reasons cause a slow down in traffic speed. The encryption/decryption performance reasons are not so important nowadays, and the same holds true with browser support, unless there is an unusual browser visitors. For more reading click here.
Caching
Server level cache
Some claim that the information served over HTTPS isn’t cached because the next request almost certainly wouldn’t use the same encryption key, so the encrypted data which the cacher could save would be useless. Theoretically if it is re-requested by the same client session it would work, but practically no network cacher tries to handle this special case. Besides, even if the data could be cached, caching would be doubled because the network cacher wouldn’t recognize that ABC and ABC were the same thing while encrypted with different keys.
Browser level cache
For practical purposes I did some tests by sniffing secure traffic with an internal cache. HTTPWatch gave these results (see the picture), proving that the browser level cache effect is true with HTTPS. The client seems to have cached the decrypted data rather than to have newly encrypted data download. So browser level cache works for HTTPS, but for most cases the network cacher is useless for encrypted content.
Why not encrypt all the sites with HTTPS?
The encryption performance issue, as might be thought, is not what makes the final decision. The basic reasons would be the following:
- SSL handshaking length may decrease performance somewhat. While downloading large, public files, there may be a system burden to encrypt these each time.
- Server resources consumption when encrypting everything compare to encrypting only most important pages.
- HTTPS breaks name-based virtual hosting, as to IPv4 addresses. When using SSL the general policy is “one site – one IP”. This is not economical, and the management load increases. Though a wildcard SSL certificate can allow the support of as many sub-domains as one likes on a single IP address.
- Encryption is not free.
General factors that influence performance change if deploying HTTPS
There are several factors that may enhance or minimize a secure traffic performance compared with an insecure one. The following picture gives a brief look at the HTTP/HTTPS algorithms realization, with bullet points following:
- Hardware
- Server software load
- Dynamic or static content (encryption time expenditures are less significant compared to dynamic content generation time)
- Client distance to server (since in the HTTPS case, round trips are to be performed)
- Typical session length (shorter sessions cause handshake time to exceed other performance factors)
- Caching behavior of client
For more discussion on HTTPS pros and cons one can read here.