USE ENCRYPTION TO IMPROVE YOUR ORGANIZATION’S WEB SECURITY AND SEARCH ENGINE RANKINGS.


This is a short guide intended for CISOs, CIOs, or CMOs who are not programmers, but want to quickly improve security AND search engine rankings (because Google awards better rankings for sites with best practices for encryption and security!).

We often notice websites with weak encryption at organizations that otherwise have a robust internal security practice. Given how little effort is involved in solving this compared to most other security initiatives, this seems like an easy win for most teams. You can test your site’s existing configuration and if your site isn’t already earning an A or A+ grade, read on.

OUR 5 RECOMMENDATIONS:
  1. Use encryption to protect your whole web presence
  2. Add HSTS headers to tell browsers to always use encryption when connecting to your site
  3. Use the best encryption configuration settings on your webserver
  4. Pre-load your site’s use of encryption into browsers
  5. Pin your site’s Certificate Authorities

More in-depth technical resources are listed at end of this document.

1. USE ENCRYPTION TO PROTECT YOUR WHOLE WEB PRESENCE

If your website doesn’t use encryption, you can assume that ISPs and compromised routers and networks all over the world will record all submitted information (including login credentials) and inject malicious advertisements or content into your pages.

Some websites only encrypt the portions considered “sensitive” (like the login or payment forms) but this is a mistake, and makes the whole site (including the “sensitive” parts) as vulnerable as if encryption were not used at all. The best solution is that requests to say http://example.com/ are only ever met with a redirect to the https URL.

All content served by your site (including embedded videos to Youtube, etc.) should use HTTPS URLs to avoid problems with “mixed content.” In most cases this just means adding an “s” to any non-secure URLs (e.g. rewriting http to https.) This is not a requirement for all external links on your site – only content that is embedded.

2. ADD STRICT HEADERS TO MAKE BROWSERS ALWAYS ENCRYPT WHEN VISITING YOUR SITE

At the moment a user visits your site, let’s say they type in just “example.com”, and the browser makes an unencrypted request to example.com, and your webserver (as configured above) redirects them to make that same request using encryption.

This works great in the normal case, but it won’t stand up to attacks. Any attacker in a privileged network position (for example because of a compromised wifi hotspot at an airport or hotel) can intercept the first request, and then perform an ssl stripping attack where the attacker acts as a middle man, talking to the server using HTTPS (pretending to be the client), but responds to the client using HTTP. The client won’t know the difference, because the client never receives the redirect to tell it to connect to the server using HTTPS.

To solve this problem, you can add a simple header to all responses your webserver sends. This is a simple matter of web server configuration, and does not change any content or interfere with the operation of web applications.

Once a browser sees this header for the first time, it will remember it and always use encryption when connecting to your website. Most importantly, it also disables the option for a user to proceed even when there is a certificate validation error (i.e. if an attacker presents a bad certificate for the website, the user will not be given the option to click OK and proceed anyway, which is a huge improvement!)

The header should generally look like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

3. USE THE BEST ENCRYPTION CONFIGURATION SETTINGS

A strong configuration includes using only newer protocols, strong keys, and unbroken algorithms. The simplest way to get this configuration right is to use the testing tool at https://www.ssllabs.com/ssltest/analyze.html and make the recommended changes to receive an A+ grade.

This requires making changes to your web server SSL configuration (i.e. Microsoft IIS, Apache, or Nginx) but generally just requires pasting a recommend configuration into the right place.

4. PRE-LOAD YOUR SITE’S USE OF ENCRYPTION INTO BROWSERS

Once you’ve done the above, all this requires is submitting a one question form! In the explanation above about the Strict-Transport-Security header we explained how the first time user’s browser visits your site, it stores a record that will require it to always use HTTPS when connecting to your site. However this does not protect against the very first visit to your site by that browser. If it has never seen the Strict-Transport-Security header before, it doesn’t know to use it.

Submitting this form to Google will cause the Chrome Browser to always use HTTPS when visiting your site, even on the very first visit. The Firefox browser uses this same preload list. Just go to https://hstspreload.appspot.com/ (yes, that’s the right URL, maintained by Google, even though it looks very unofficial). The site will check your site’s eligibility (checking your SSL configuration and your existing Strict Transport Security header)

5. PIN YOUR SITE’S CERTIFICATE AUTHORITIES

This last step is slightly more complicated than the others, because we cannot give you the exact header you need to add in advance. However it’s not very hard to calculate, and if you need help, feel free to contact us at SpiderOak.

If you’ve done all the above, now the only attackers that can impersonate your website to inject malware or capture credentials are those that 1) have your webserver’s private keys (which is hopefully no one) or 2) One of the 600+ root Certificate Authorities in the world, or any of the many more intermediate authorities, or anyone that hacks or socially engineers one of the above.

Certificate Authorities don’t have an amazing track record in this regard, with a long history of spectacular failures in chain of custody, trust, operational security practices, bribery, government influence, etc.

A simple way to mitigate this problem is to add a Public-Key-Pins header to your website, similar to the Strict-Transport-Security header discussed above. We recommend you use this header to pin the root certificates of the one or two Certificate Authorities your organization normally buys certificates from. If you only buy certificates from one Certificate Authority today, that’s fine: pick the Certificate Authority you’d likely use if you had to switch for some reason as the backup.

This configuration means that you can continue buying and using certificates the way you do today, but the potential attackers are now reduced just to those who can fraudulently obtain a certificate from your particular chosen authorities, instead of any one of the many authorities trusted by browsers.

See Public Key Pinning on Mozilla’s Developer Network.

OTHER RESOURCES

Google: HTTPS as a Ranking Signal. This shows that you can improve your search engine rankings by better securing your website.

SSL Labs Best Practices Guide: More more detailed and in-depth than this document, for a more technical audience.

Discussion of public key pinning strategies and Mozilla’s documentation.