6 ms·

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 d

by timr 14y ago

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?

deleted 14y ago
[deleted]
ceph_ 14y ago
Without the proper tuning https will be significantly slower than http.
- Zirro 14y ago
  Could you clarify what "proper tuning" entails?
  - ams6110 14y ago
    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.html http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...
emmelaich 14y ago
By protocol relative, are you referring to the // urls? (http://paulirish.com/2010/the-protocol-relative-url/ http://paulirish.com/2010/the-protocol-relative-url/) Because they wound't be so PITAish would they?
- deleted 14y ago
  [deleted]
pornel 14y ago
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 14y ago
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.

by timr 14y ago

deleted 14y ago

[deleted]

ceph_ 14y ago

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

Zirro 14y ago
Could you clarify what "proper tuning" entails?
- ams6110 14y ago
  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.html http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...

emmelaich 14y ago

By protocol relative, are you referring to the // urls? (http://paulirish.com/2010/the-protocol-relative-url/ http://paulirish.com/2010/the-protocol-relative-url/) Because they wound't be so PITAish would they?

deleted 14y ago
[deleted]

pornel 14y ago

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 14y ago

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.