The increased security that HTTPS brings might suggest that it should be used as a matter of course, but there are drawbacks that must be considered.
- Pages accessed by HTTPS can never be cached in a shared cache. Since the conversation between browser and server is encrypted, intermediate caches are unable to see the content to cache it. Worse, some browsers will not even cache HTTPS documents in their local per-user caches. Worse still, since it is dangerous to mix HTTPS and HTTP content on the same page (there are some scripting attacks that can allow a script in one component of a page to read data from another), even embedded icons and pictures have to travel encrypted and therefore can not be cached. The lack of local caching can lead to problems in Internet Explorer that can make it impossible to save documents to disk or to open them in external applications (see for example http://support.microsoft.com/kb/812935)
- The encryption/decryption represents a computation overhead for both server and browser. Most modern client systems will probably not notice this, but on a busy server handling multiple simultaneous HTTPS connections this could be a problem.
- Some firewall or proxy systems may not allow access to HTTPS sites. Sometimes this is simply because the administrators have forgotten to allow for HTTPS. However sometimes it is a conscious security decision: since HTTPS connections are end-to-end encrypted, they can be used to carry any traffic at all. Allowing them through a firewall, which then has no way to look inside the data stream, could allow any sort of data transfer (in either direction).
- Cost. Commercial CAs charge something like £100-200 per year for issuing certificates. And you need at least one for every site that you secure, because the hostname (as it appears in URLs) forms part of the certificate. There is also the "hidden" administrative cost of applying for the certificate and of arranging for its renewal each year.
