[timr]

Honest question, for those who have done it: what are the downsides of allowing your whole site to be accessed via SSL?

Obviously, you need to be a bit more diligent about making asset urls protocol-relative (which can be a PITA across a large, dynamically generated site), but are there any other gotchas? Server load? Reduced cache-ability?

[pornel]

You can have good cacheability—you just need to send explicit Cache-Control headers (which is a good idea anyway).

If you don't do SSL properly (e.g. non-SSL-terminating load-balancer can break SSL session resuming by forwarding requests to different servers which don't share tickets) then you'll have lower front-end performance.

webpagetest.org nicely shows connections including time spent on SSL negotiation, so you can use it to check your SSL overhead.

[otterley]

In my case, I work for a SaaS provider that performs virtual hosting using customer-provided SSL certificates (myservice.customer.com). This puts us in the unenviable position of having to maintain thousands of IP address endpoints, one per customer, along with all the network-related complexity that goes along with it.

SNI would help a lot, but unfortunately it will never be a feature in the SSL client code in Windows XP (which MSIE uses) and so we're stuck with this for the foreseeable future.

[emmelaich]

By protocol relative, are you referring to the // urls?

(http://paulirish.com/2010/the-protocol-relative-url/)

Because they wound't be so PITAish would they?

[ceph_]

Without the proper tuning https will be significantly slower than http.

[Zirro]

Could you clarify what "proper tuning" entails?

[ams6110]

SSL/TLS is not computationally expensive any more[1] but there are some things that can help/hurt discussed in the footnote.

[1] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...