On Sunday 19th November 2017 in Thika town in Kenya, a group of thugs successfully crept unscathed through a 30-metre-long underground tunnel leading into a bank’s strongroom and made away with over USD500,000.

Pitifully at the bank’s main entrance the security team attentively and diligently  guarded the bank against any external intrusion  and the rest is history. Of course detailed planning and intelligence work is involved in making such a scheme a success.  By applying a crafty ‘bloodless’ offensive action and the  ‘next day’ surprise tactic, two  key principles of war, this mission was bound to succeed.

Similarly  sensitive online missions transacted over the Internet must equally be secured.  Tunnels are ‘dug’ for the transmission of sensitive credit card information and other private data thanks to the secure hyper-text transfer protocol (https).

Internet must equally be secured. Tunnel are ‘dug’ for the transmission of sensitive credit card information and other private data thanks to the secure hype-text transfer protocol (https).

But what comfort do we get from this when we do business online fully aware that every click we make, every data we send travels through cyber space – the hackers’ dance floor?

When the http access mechanism was invented in 1991 the time the first web site was launched, it could only speak some few words but today it has grown and matured strong enough to cope up with contemporary world challenges with insatiable Internet demands for rich graphics, high density media, dynamic content, and most of all safety.  It is this protocol that allows the 3.92 billion Internet users to interact with the 1.877 billion web sites today (www.internetlivestats.com).

It is for the sake of safety of e-commerce transactions that the complementary protocol https, ‘s’ for secure was born. For the not so Internet savvy  readers just remember that when you surf or shop using the HTTPS  protocol the information you share is reacted with some other substances – a process known as ciphering and the results can only be read, with ease, by yourself and  the intended receiver of that information. Period.

Let’s embark on the journey that we go through to achieve a secure online connection using our smart devices. It all starts when you visit a web page whose Uniform Resource Locator (URL) aka the web address is prefixed by the HTTPS protocol.

Upon hitting the return key – the archaic  way, a request lands on the web server on the other side of the world, but geographically it could be in your neighborhood, the web server immediately sends you a digital certificate in a manner convincing you to trust it.   Your browser which is a quite intelligent app does all the inspections of the certificate presented. There are several pieces of information on the certificate but the three main items are : (i) address of the server, (ii) Public key of the server, and (iii) a digital signature.

The address  and public key of the server mentioned above are used to generate some magical data known as a “Hash” which is encrypted by a trusted agent known as the Certificate Authority (CA). The CA signs or in a human language they encrypt this hash using their private (secret) key. This means that if you open the signature using the decryption process applying the public key of the agent(CA)  that had signed it, you will get a certain hash. Remember that the public keys of the serious CAs are found on your browser. See example from Mozilla under “Options” then  “Privacy & Security”.

If you do your own hashing of the web address mixed with public key of the server, and it matches  the one you just opened, it therefore means that you have successfully authenticated the bearer of the certificate. This is what your browser does to guarantee you some online security.

Once your browser is happy about the certificate, it is now ready to start using the public key on the certificate.  Using the SSL/TLS process, the browser generates another key  known as the Session Key. This session key used both by your station and the server is encrypted by your browser using the public key given on the certificate and sent to the server. The server on the other hand decrypts it since it has the matching private key. Now the two systems have a common key that they use thereafter for all the secure transactions.

This Session Key is valid for the current communication session and it is the one used to protect all the data  exchanged between your station and the server. The moment you close your browser this process is repeated invalidating the old session keys generated earlier.

The reason behind the use of session key which is a private key is the reduced processing requirements associated with the public key counterparts and the limited exposure time for each session key.

The above process assures us some levels of comfort whenever we are prompted to share  private and sensitive information through the hacker paradise – the Internet.

Be safe!