Best practices for a fully SSL-protected site

Issue

I would like to confirm I am following best practices for SSL/TLS on my site.

Resolution

Implementing Secure Sockets Layer (SSL) across part or all of your website is a recommended security goal to use on the vast majority of Drupal websites. Creating an encrypted link for data protects your website and users' information and assets. Acquia Cloud customers can and should add SSL to their websites. There are several important factors to consider when implementing SSL:

• Varnish - If you are an Acquia Cloud Enterprise, Acquia Cloud Professional, or Acquia Cloud Site Factory customer, Varnish over SSL is enabled by default. Please see Varnish over SSL for more information.

  Note
  It is a good idea to check your certificate's encryption to see if it uses SHA-1. See Deprecation of SHA-1 for SSL certificates for additional information.

• Assets - You'll need to ensure that all your assets (CSS, JavaScript, and so on) are served from an HTTPS address. With Drupal, this isn't much of a concern because these are often provided locally through your theme files. However, if you are using any third-party APIs, you'll need to ensure that communication happens through an HTTPS address. Common third-party APIs include Twitter, Google Calendar, and Facebook. If this API connection is not communicating as HTTPS, browsers may block this as insecure content. The good news is that most modern APIs allow interchangeable HTTP or HTTPS communication (Google especially) so there's not usually much work involved, other than ensuring that the correct address is used in modules/themes.

  One method of ensuring that embedded resources are served using the correct protocol is to use the Pathologic module. You can learn more about how to use Pathologic on its documentation page. When setting this up, Correct URLs with Pathologic should be the last filter. Set Processed URL format to whichever method is most appropriate for your website. If you are switching to a fully SSL website, then set this option to Full URL.

• Redirects - Ensure that you have proper 301 redirects from your HTTP pages to HTTPS. If a website was already in production on HTTP, Google and other search engines most likely have indexed your public-facing pages. If you start serving everything over HTTPS, Google will treat these pages as a completely separate website. This can lead to duplicate content penalties, which can be frustrating and difficult to dig out from.

  To ensure that this doesn't happen, add RewriteRule directives in your .htaccess file that rewrite all requests with a 301 status code to the old HTTP website back to HTTPS with the full query string intact. The next time Google crawls the page, it will see the permanent redirect status and update your website to be indexed under HTTPS, rather than creating a duplicate. If you are an Acquia Cloud user, read Redirecting traffic between HTTP and HTTPS on Acquia Cloud to find out how to set this up.

• Resources in general - Combine as many resource requests as possible. Serving content over HTTPS requires a slightly increased amount of overhead to account for the SSL handshake and negotiation. This results in a minimal amount of additional time required for asset transmission, but when you are sending hundreds of assets, such as images and stylesheets, it can quickly add up to a measurable amount. To solve this, combine as many images into sprites as is reasonable and ensure that CSS/JS Aggregation is enabled in Drupal to serve as few stylesheets as possible.

  For websites with many images and resources, sourcing them from off server (that is, S3) is an alternative approach to reduce issues with negotiation speeds. However, this requires another SSL certificate for the second asset domain, although a wildcard could work for both domains. An example is the scenario in which you use www.example.com for the main website and images.example.com as a second domain for only the images.

With the preceding in mind, you should have no issues switching your websites over to be protected by SSL across the board, rather than only protecting a few pages using modules.