// The facts
- 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.
- Inexpensive devices exist that listen out for these call requests and automatically reply “Yes, I’m here” to any and all requests.
- 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.
- 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 => 188.8.131.52
- A request is made to the server machine at the IP address for the file you have requested.
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.
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:
- As before the server name component is translated to an internet IP address.
- 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.
- 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.
- 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:
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.