Online Security on Websites Explained

Security

When creating resources for online consumption you are aware of all the aspects of creating beyond the material itself. Where will it be hosted? What form will it take? What licence should it be released under?

What about, are my users comfortable with my security when viewing? This isn’t usually a concern when using a third party service like YouTube or Dropbox as hosting or when the material is held on internal repositories. But, when it comes to your own platforms or making a choice of third party ones, is the need for secure transmission applicable and should it form part of your decision making process.

If you are making your users provide personal information to access your resources, such as third party logins or providing email addresses, you should be providing the logged in part of your website under a secure domain. This stops the passwords, emails and possible payment details from being sent as plain text, as it is whenever you don’t see the padlock icon on a website.

What is a secure domain?

All website URLs, no matter if browser URL bar hides the text or not, start with http://. A secure domain will use https:// and provide secure transmission between the website and the user. The web server provides a certificate, usually bought or given under provisions that require identification that matches the domain you wish to secure against the details of the purchaser to make sure they own the domain they are saying is owned by who it purports to be.

This certificate is created against a root certificate from the certificate authority (CA) such as DigiCert, VeriSign or the free alternative the Let’s Encrypt initiative. This means all browsers that trust the issuers, trust all the certificates they issue, meaning they trust your certificate for your website.

There are many levels or types of certificate which all have different effects and are shown to the browser users in different ways. The highest level is the most expensive but most visible, something usually reserved for purchasing online. The second, a more appropriate level is secure but not requiring the organisations name, the bottom URL is one which is secure but is using content from an insecure source.

Some of the certificates cover a various number of combinations of domains. These range from a single URL, a specific list of URLs or wildcard URLs so you can secure all sub-domains, such as *.cadarn.ac.uk. The different types are explained on the page, https://www.thesslstore.co.uk/products/ssl.aspx.

For a technical overview of why this should be done and why Google thinks it is so important watch this presentation by them from 2014

How do I become secure?

To have webpages that are secured under SSL/TLS and give that user trusted padlock, you need a certificate from an issuer. This can be bought or may even already be available if your organisation has domain or wildcard based certificate already.

You provide the issuer with your URL and your details. Depending on the product you may have to answer a range of questions to verify you are the owner of the web pages contained under the URL. The next step is to install the certificate onto your web server. Most hosting companies or your trusty local web employee can do this for you if you cannot do this yourself.

When implementing this on your website, any links you may have written or resources already created will be linked through your old http:// url and may need changing to make use of the new https://. These may have to be redirected on your web server to ensure people who have manually types the http or have an old link bookmarked are directed to the correct place. This also applies to any internal website resources you are using. The image of your logo has a URL to be displayed, if this is the full http:// URL then the image may not show or even produce a difference in the browser URL display, due to secure webpages only allowing content from secure sources.

To stop the security becoming stale all certificates have a maximum life of three years, this needs to be planned for as an out of date certificate will stop users visiting your sites before they see your content in most browsers today, who knows what they will not allow access to three years from now.

User tracking happens through HTTPS

The tracking of users is a topic wholly separate from using HTTPS, but sometimes is misunderstood by users and content producers alike. This method of getting information on user behaviour is prevalent across all major websites and was the driving force behind the “Cookie Notice” in the EU laws. Your users might not want to use websites that do this sort of tracking, you yourself as an educator might find it unfair of these companies to use your students learning to sell advertising to. Advertising is a common way but embedded YouTube, Facebook or Google Maps content will do the same job. This is unaffected by your choice to use HTTPS and shouldn't alter whatever notices or provisions you set to display to your users .

Checklist

So to get started follow these steps;

  • Decide if you really need secure pages. Is your information and users worth protecting?
  • Decide what domains you need now, and in the future for securing your pages.
  • Make sure your web content either has no http in the URL or is changeable to https
  • Get and apply the certificate to your web server.
  • Alter the URLs in your content if required.

Moving to HTTPS for some or all your webpages is a task that requires planning and forethought but it will gain you viewers and give peace of mind to your users that what they viewing cannot be altered and their online identities cannot be stolen from using your website.

Image credit https://www.flickr.com/photos/111692634@N04/11406985424 Creative Commons Attribution-ShareAlike 2.0 Generic

about the author

Referencing[+]

  • Creative Commons - Full

    Online Security on Websites Explained by Daniel Pullin is licensed under Creative Commons - Attribution
  • Creative Commons - Short

    This work by Daniel Pullin / Creative Commons - Attribution
  • Harvard

  • IEEE

  • MLA

To use this site as it was intended you need JavaScript to be enabled.