Background

In Fall of 2017, we began the daunting task of switching our web platforms to HTTPS. But why? This change was triggered by a recent change in the Google Chrome browser that identifies any HTTP webpages where users can type information as "Not Secure."  This means our Library Catalog, homepage, and a lot of our widgets were triggering a "Not Secure" warning for users accessing our website over Chrome (over half our total website visitors!)

To make these pages secure within Google Chrome (and other browsers in the future), we have to convert our web platforms to the HTTPS protocol. HTTPS is more secure because it provides encrypted communication between the user's browser and the website.

Benefits of Serving Web Pages over HTTPS

• Authentication - HTTPS provides some level of verification that the website is managed by whom it claims it is (e.g., libguides.furman.edu).

• Data Integrity - HTTPS websites are more resistant to being tampered with.

• Privacy - HTTPS websites are harder to read by a third party.

What Is Involved with an HTTPS Migration?

There are 2 steps to migrating our web platforms to HTTPS.

1. All our web platforms must have a secure SSL certificate. This will allow all the webpages to load over HTTPS
2. We have to identify and update all the mixed content on our webpages.

What is Mixed Content?

Mixed content occurs when a webpage is loaded over HTTPS, but the page contains some content that is loaded over HTTP. Most webpages, except for the most basic ones, contain resources that aren't actually part of the HTML file. Examples of external webpage resources are images, scripts, or iframes. Because webpages that are loaded over HTTPS are considered to be more secure than pages loaded over HTTP, most browsers will actually block the loading of HTTP resources into a page that was loaded over HTTPS. In other words, the browsers will not display certain types of mixed content that are considered to be the most potentially risky.

Note that images referenced via an HTTP URL, like <img src="http://library.somewhere.edu/images/logo.jpg" alt="Library Logo"> are a useful example of mixed content, because it's easy to understand that they are separate files from the basic HTML of a webpage, but most browsers will not block the loading of HTTP images on HTTPS pages at this time.

Which Types of Mixed Content are Blocked?

Here are the types of webpage resources that we think you are most likely to use in your guides, and which will be blocked by most browsers, if you try to load them as HTTP resources.

• external scripts
• external stylesheets
• iframes
• Flash objects
• embedded content (such as widgets, videos, etc.)

Mozilla has detailed information about mixed content

This overview was adapted from Google's What is Mixed Content page.

All LibGuides-generated URLs are good to go!

We're not aware of any LibGuides functionality, that allows you to point and click to insert content, or generates content for you, that doesn't use URLs that will load those resources over HTTPS on HTTPS pages.

There is a bit of nuance here, that you might want to be aware of, if you peek under the hood. Some LibGuides-generated URLs start with HTTPS, and those are, obviously, good to go. LibGuides also uses a special type of URL called a "protocol-neutral" URL. Those URLs start with //, which means that they don't specify either the HTTP or the HTTPS protocol. Web browsers will automatically complete those URLs, by prepending the protocol used by the current web page, so those URLs will use HTTPS on HTTPS pages. Those URLs are also good to go.