// Why your Saas must always, always be HTTPS

// The facts

  1. If you have ever connected to an open Wi-Fi network (i.e. one that doesn’t require a password) then your mobile device will call out to see if that network is in range.
  2. Inexpensive devices exist that listen out for these call requests and automatically reply “Yes, I’m here” to any and all requests.
  3. If you happen to be in the vicinity of such a device then your laptop, mobile or smartphone will happily connect to this fake Wi-Fi without question.

// Why does this matter?

Much of the trust on the internet is based on the infrastructure through which you connect. This is especially true if the web page address begins with HTTP rather than HTTPS.

A secure web addressWhenever you request an HTTP web page, image, video or JavaScript file the following happens:

  1. The server name component of the address is translated into an internet IP address which is the underlying addressing system of the web. Eg. bbc.co.uk =>
  2. A request is made to the server machine at the IP address for the file you have requested.
  3. All being well, the server handles the request and replies with the data that represents the page, image, video or JavaScript file you requested.

Fig 1. Snooping

If you happen to request this site whilst connected to a fake Wi-Fi then the owner of the fake Wi-Fi can collect all of the data you receive, and more importantly send to the site including any personal details or passwords that you enter or view in your browser.

Some sites use HTTPS only on their sign-in pages under the assumption that this is the only point that needs protecting. This is an incorrect assumption as once you are returned to the insecure HTTP connection after sign-in the information passed becomes visible to the fake Wi-Fi owner again.

Fig 2. Fake content

Another risk is also exposed when connecting via HTTP in that it is possible to alter content en-route to your device. This opens-up the possibility of making minor modifications to any JavaScript code running on the web site to collect keystrokes, passwords or exploit other more serious security flaws that may exist in your web browser.

Fig 3 - Fake server

Finally, the fake Wi-Fi can alter the translation of the server name translation redirect requests to fake servers which trick you into providing sensitive information.

// How does HTTPS help?

In essence the request process remains the same but with a few crucial steps and checks that occur before the actual request is made:

  1. As before the server name component is translated to an internet IP address.
  2. A request is made of this server for proof that it is who it claims to be. This proof comes in the form of an SSL certificate.
  3. The SSL certificate is then checked in a tamper-proof way against the trusted issuer of this certificate, ensuring that the certificate presented matches the one expected.
  4. Assuming everything checks out, your device and the server establish an encrypted channel through which the details of the file request is passed and the content returned.

The crucial point to understand is that all transfer of information to and from the server happens across an encrypted channel – and the encryption prevents:

  • Eavesdropping
  • Tampering
  • Faking

In short, all of the potential issues above are solved in one fell swoop.

// The conclusion

Armed with this understanding we made the decision some time ago to only allow access to our Saas vLearning web servers via the secured HTTPS method.

Our subscribers create, manage and deliver blended learning using our system. Much of this content is sensitive and as employers they also have a responsibility to protect the personal details of their employees. Some subscribers in certain key industries, such as banking, regulation places additional security demands on the handling and storage of information.

We fundamentally value the trust of our subscribers and feel this is the only sensible option.

This forms one important strand of our commitment to security which also includes other significant features such as hashing and salting user passwords, encrypting all personally identifiable data within the database and ensuring that communications between system components also happens over secured channels.



Steve Mansell - CTO

Steve is our Chief Technology Officer and the mastermind behind our unique vLearning Solutions platform which has been developed from listening to client's changing eLearning requirements.