Make full site HTTPS / SSL? What performance / SEO issues & best practices still apply in 2012?

Question

Note: There are existing question that look like duplicates (linked below) but most of them are from a few years ago. I'd like to get a clear and definitive answer that proves things either way.

Is making an entire website run in HTTPS not an issue today from a best practice and performance / SEO perspective?

UPDATE: Am looking for more information with sources, esp. around impact to SEO. Bounty added

Context: The conversation came up when we wanted to introduce some buttons that spawn lightboxes with forms in them that collect personal information (some of them even allow users to login). This is on pages that make up a big portion of the site. Since the forms would need to collect and submit information securely and the forms are not on pages of their own, the easiest way we could see to make this possible was to make the pages themselves be HTTPS.

What I would like is for an answer that covers issues with switching a long running popular site to HTTPS such as the ones listed below:

1. Would a handshake be negotiated on every request?
2. Will all assets need to be encrypted?
3. Would browsers not cache HTTPS content, including assets?
4. Is downstream transparent proxies not caching HTTPS content, including assets (css, js etc.) still an issue?
5. Would all external assets (tracking pixels, videos, etc) need to have HTTPS version?
6. HTTPS and gzip might not be happy together?
7. Backlinks and organic links will always be HTTP so you will be 301'ing all the time, does this impact SEO / performance? Any other SEO impact of changing this sitewide?

There's a move with some of the big players to always run HTTPS, see Always on SSL, is this setting a precedent / best practice?

Duplicate / related questions:
Good practice or bad practice to force entire site to HTTPS?
Using SSL Across Entire Site
SSL on entire site or just part of it?

Answer 1

Not sure I can answer all points in one go with references, but here goes. Please edit as appropriate:

Would a handshake must be negotiated on every request?

No, SSL connections are typically reused for a number of consecutive requests. The overhead once associated with SSL is mostly gone these days. Computers have also gotten a lot faster.

Will all assets need to be encrypted?

Yes, otherwise the browser will not consider the entire site secure.

Would browsers not cache HTTPS content, including assets?

I do not think so, caching should work just fine.

Is downstream transparent proxies not caching HTTPS content, including assets (css, js etc.) still an issue?

For the proxy to cache SSL encrypted connections/assets, the proxy would need to decrypt the connection. That largely negates the advantage of SSL. So yes, proxies would not cache content.

It is possible for a proxy to be an SSL endpoint to both client and server, so it has separate SSL sessions with each and can see the plaintext being transmitted. One SSL connection would be between the proxy and the server, the proxy and the client would have a separate SSL connection signed with the certificate of the proxy. That requires that the client trusts the certificate of the proxy and that the proxy trusts the server certificate. This may be set up this way in corporate environments.

Would all external assets (tracking pixels, videos, etc) need to have HTTPS version?

Yes.

HTTPS and gzip might not be happy together?

Being on different levels of protocols, it should be fine. gzip is negotiated after the SSL layer is put over the TCP stream. For reasonably well behaved servers and clients there should be no problems.

Backlinks and organic links will always be HTTP so you will be 301'ing all the time, does this impact SEO?

Why will backlinks always be HTTP? That's not necessarily a given. How it impacts SEO very much depends on the SE in question. An intelligent SE can recognize that you're simply switching protocols and not punish you for it.

Answer 2

1- Would a handshake be negotiated on every request?

There are two issues here:

• Most browsers don't need to re-establish a new connection between requests to the same site, even with plain HTTP. HTTP connections can be kept alive, so, no, you don't need to close the connection after each HTTP request/response: you can re-use a single connection for multiple requests.

• You can also avoid to perform multiple handshake when parallel or subsequent SSL/TLS connections are required. There are multiple techniques explained in ImperialViolet - Overclocking SSL (definitely relevant for this question), written by Google engineers, in particular session resumption and false start. As far as I know, most modern browsers support at least session resumption.

  These techniques don't get rid of new handshakes completely, but reduce their cost. Apart from session-reuse, OCSP-stapling (to check the certificate revocation status) and elliptic curves cipher suites can be used to reduce the key exchange overhead during the handshake, when perfect forward-secrecy is required. These techniques also depend on browser support.

  There will still be an overhead, and if you need massive web-farms, this could still be a problem, but such a deployment is possible nowadays (and some large companies do it), whereas it would have been considered inconceivable a few years ago.

2- Will all assets need to be encrypted?

Yes, as always. If you serve a page over HTTPS, all the resources it uses (iframe, scripts, stylesheets, images, any AJAX request) need to be using HTTPS. This is mainly because there is no way to show the user which part of the page can be trusted and which can't.

3- Would browsers not cache HTTPS content, including assets?

Yes, they will, you can either use Cache-Control: public explicitly to serve your assets, or assume that the browser will do so. (In fact, you should prevent caching for sensitive resources.)

4- Is downstream transparent proxies not caching HTTPS content, including assets (css, js etc.) still an issue?

HTTP proxy servers merely relay the SSL/TLS connection without looking into them. However, some CDNs also provide HTTPS access (all the links on Google Libraries API are available via https://), which, combined with in-browser caching, allows for better performance.

5- Would all external assets (tracking pixels, videos, etc) need to have HTTPS version?

Yes, this goes with point #3. The fact that YouTube supports HTTPS access helps.

6- HTTPS and gzip might not be happy together?

They're independent. HTTPS is HTTP over TLS, the gzip compression happens at the HTTP level. Note that you can compress the SSL/TLS connection directly, but this is rarely used: you might as well use gzip compression at the HTTP level if you need (there's little point compressing twice).

7- Backlinks and organic links will always be HTTP so you will be 301'ing all the time, does this impact SEO?

I'm not sure why these links should use http://. URL shortening services are a problem generally speaking for SEO if that's what you're referring to. I think we'll see more and more usage of HTTP Strict Transport Security, so more https:// URLs by default.