12 May 2017

HTTPS secure access to the website

A quick explanation behind the use of HTTPS for secure access to the University's website.

Historically websites have been made available over HTTP (Hypertext Transfer Protocol) with the more secure HTTPS being used for things like online banking and shopping.

More recently there has been a push for more sites to make use of HTTPS for added security - for example if you use Facebook or Twitter you’ll see that all the pages on their site use HTTPS.

While HTTPS has always been available on the University website, the default people get is the less secure version. Only when accessing specific applications - such as logging into MUSE or supplying a username and password - have we ensured people are using HTTPS.

We’ve now configured the University website to use HTTPS on all CMS pages. If anyone tries to access anything over the insecure protocol we automatically send them to HTTPS instead. A visitor won’t notice any difference, other than the padlock icon at the top to indicate the page is over HTTPS.

Does this mean everything is secure now?

Security is not black and white - it’s more of a sliding scale. Things are more secure than they were, but if for example you have a form on your CMS pages, you still should only be asking for and storing appropriate data. Just because we have HTTPS doesn’t mean, for example, that it’d be safe to process credit card details using a CMS form.

As a CMS editor, will I have to do anything?

If you’ve used the standard features in CMS you should find that everything works without you having to do anything. Where you might see issues with your pages are if you have manually embedded insecure (HTTP) content in your CMS pages. For example, if you embed a video or image on your pages which is coming from a server using HTTP then the visitor's browser may show a warning message about the insecure content, or that asset may not load at all.

If you find a page on your site is showing a warning, or you don’t get the green padlock icon, then you’ll need to find any assets (images, videos etc) which are setup to use HTTP, and convert them to using HTTPS. If the asset is in CMS you can use the inbuilt tools. If it’s hosted outside of the CMS you might find that HTTPS is not available and you’ll need to take a look at hosting options. Videos embedded from YouTube for example support embedding over HTTPS.

Website address consistency

As well as standardising on HTTPS access we've also done the same with one domain name too. Since we first had a website, the site has been available to visitors who type in:

  • www.shef.ac.uk
  • www.sheffield.ac.uk
  • shef.ac.uk
  • sheffield.ac.uk

There are historical reasons for this variety of names, dating back a very long way!

To improve the experience of visitors to the site, and also to help improve our search engine ranking and data we collect using Google Analytics, we’ve reconfigured the site to ensure that all visitors use the site will do so at www.sheffield.ac.uk

Anyone who visits the site using any of the other domain names won’t notice - all old web addresses will continue to work and we’ll seamlessly send them to the right page on the main domain name. In the address bar of their browser they’ll see www.sheffield.ac.uk.

Will I have to do anything differently?

Any existing links to www.shef.ac.uk will continue to work as before, but if you notice you’ve got any links around the site which go to the HTTP version of the site, or any of the other domain names (www.shef.ac.uk, shef.ac.uk or sheffield.ac.uk) you could update them to point to https://www.sheffield.ac.uk/)

As all the different domain names we have will continue to work, visitors finding old links will still be able to use the site as normal.

Get in touch

If you have CMS questions or are stuck then get in touch and we'll do our best to help.