Overview
What is “Secure Mode”
For the purpose of this document, we're calling a series of web encryption techniques “Secure Mode.” But, as a brief explainer, we'll define a few acronyms for clarification.
- Secure Sockets Layer (SSL) is a protocol that enables secure communications over the Internet (not just the web - it may include FTP and other Internet technologies).
- Transport Layer Security (TLS) is the successor to SSL. All major modern browsers now support TLS v1.2, and previous versions are being retired due to potential vulnerabilities. TownNews.com has announced we will drop support for TLS v1.0 and v1.1 in the first half of 2017.
- Hypertext Transfer Protocol Secure (HTTPS) is the web-specific implementation of SSL/TLS. It provides encrypted communication over the web.
- Hypertext Transfer Protocol (HTTP) is of course the insecure version of HTTPS.
It should be noted that, depending on context, these terms can sometimes be used almost interchangeably. From here on out though, we'll refer to it as “Secure Mode” or HTTPS.
Why is "Secure Mode" Important
Even if you don’t handle top-secret information on your site, it is recommended to run in secure mode whenever possible. The benefits of running in Secure Mode are numerous:
- It protects your website from intruders who want to intercept the communication between your website and the user’s browser. This may include malicious hackers, but also legitimate services who may want to inject ads or change the website for a certain purpose. (Note that running a site in Secure Mode doesn’t prevent ad blocking technologies, which happen within the browser after the communication has taken place between the end user and the web server.)
- Running in Secure Mode protects the traffic from the web server to the end user, ensuring that third-parties (such as hackers or even intrusive governments) cannot listen to the communications.
- Several major web browsers, such as Google Chrome, will begin warning end users that a site is not secure, which could lead to loss of pageviews as users get spooked and leave the site.
- Google has announced they will begin to reward secure sites with a bump in SEO. The change thus far has been very subtle, but it is likely they will increase the boost over time.
Assess Your Site For Insecure (HTTP) References
To begin the process of switching to a secure site, we recommend first looking through your site for things that may be referenced in an insecure way.
All items implemented in default templates by TownNews.com will be secure by default. So you’ll want to review your page for non-standard code from outside sources. Top contenders would be:
- Ad network code
- Third-party embed codes
- Custom blocks or custom code that is off the ‘update path’
- Analytics tags
- Widgets from third-parties
- Non-standard integrations with third-party vendors
- Custom font libraries
If you have a developer, they can look through their custom code (such as global directories or the site component) in order to look for hard-coded http references.
If you find code that is insecure, contact the vendor and ask if they have a secure version of their code available. Many do.
If they do not, I would consider switching to another vendor, or waiting until they have a secure version available before you switch to Secure Mode.
Preview Your Site in The Admin Dashboard
An easy first-step to test for insecure widgets is to preview your site in the admin dashboard. The admin preview is always secure, so insecure widgets and other integrations will not load. If you see big blank spaces where your Twitter widget should be, for example, you can look more closely at that code to determine if it is referencing HTTP or HTTPS.
Note that there are other times when items may not work in the admin preview (because of how the ads are implemented, or because of how URLs are re-written in this area), but it is a good place to start.
Perform a Limited Test on a single URL
After you’ve done the best you can to vet your site for custom code and third-party integrations that aren’t secure, it is time for a limited test.
To do this go to a specific URL in the URL map (such as “entertainment” or “business”), under Settings / Urls and check the “Require HTTPS” box in the “Page properties” tab. This will make all traffic to this section secure.
It is important to note that this property does not inherit down to subsections, so if you have subsections that you also want to test, you should check the box on these sections as well.
WARNING: Do NOT use the URL map's Require HTTPS setting if you want to require HTTPS on the entire site. That should instead be accomplished by using the Site Setting (shown below, under "Large-Scale Testing").
Once this is enabled, wait 5 - 10 minutes for cache to clear, and then examine this section. If everything is working properly, you’ll see the site redirect to HTTPS in the address bar when you view that URL on the live site.
If there are no insecure elements on your page, you’ll see the “secure” green lock on the Google Chrome browser. Congratulations! This means everything is working!
If you don’t see the green lock, it is time for further investigation.
At this point, you can use the Chrome DevTools to look at which interactions on the webpage are insecure. Click on “Security” in the DevTools toolbar, and you will see all elements that have “non-secure origins.”
You can also click on “Network” to see exactly which requests were made in an insecure manner. This will tell you the functionality you need to investigate and replace with secure code.
Note: It is very important to specifically check for analytics code and ad network code - since those items may not be apparent on the front-end, and may cause significant damage if they are not loading properly.
Large-Scale Testing
Once you feel confident with your limited test, it is time for a larger test.
At this point, you may consider turning “Require HTTPS” on more URLs, or more trafficked sections such as “obituaries” or “news.” You may also want to test out specific URLs that have different integrations or their own third-party widgets.
Next, it is time to try “Do nothing” mode. This mode is available in the HTTPS panel in the site settings, and tells BLOX CMS to stop redirecting to HTTP mode (which is the current default on all pages except those places where user information is gathered - such as Ad Owl, the User Dashboard and the BLOX Forms pages).
When you have “Do nothing” enabled, you are able to browse through the site in secure mode (by simply typing in HTTPS in the browser) and you won’t be redirected to an insecure page.
This will allow you to walk through the site again, in the same manner described above, to look for insecure code or widgets.
The Final Step To Go Secure (HTTPS)
Once you feel confident that your site has no more insecure connections, you can click on “Redirect to HTTPS” in the HTTPS site settings panel. Once the cache clears in a few minutes, you’ll find that your site will be redirected to an HTTPS connection regardless of what you type into the address panel.
Again, it is important to walk through the site and look for pages which don’t have the green checkbox.
It is also a good time to ensure that you are seeing proper ad impression rates, and double check that your analytics is still working.
Additional Note About Pages That Gather User Data
It is important to note that, even in full Secure Mode, there are some further restricted pages in BLOX CMS. These pages are places where sensitive user data is gathered, such as login screens, User Dashboard, form pages and Ad Owl pages (essentially, any pages where the user may input their personal information or credit card data).
These pages have always required HTTPS, but additionally, we do not allow third-party ads on these pages. The reason is that even secure ads from reputable networks can be compromised by malvertising, which can theoretically capture user data once on the page.
Support & Resources
