Transport layer security or TLS is a successor of SSL (Secure Socket Layer), Cryptographic protocols designed to provide security over network communication. Mobile being extremely used over public Wi-Fi networks is vulnerable to man in the middle and sniffing attacks if the communication is not encrypted and the user of the particular application is exposed to potential data theft if the communication is not properly encrypted.
In a typical SSL usage scenario, a server is configured with a certificate containing a public key as well as a matching private key. As part of the handshake between an SSL client and server, the server proves it has the private key by signing its certificate with public-key cryptography.
However a certificate and private key can be generated by any one and thus there needs a way by which it can be verified.
Here is where the certificate authority comes into picture whose signature is already trusted by the client and thus the certificate signed by the Certificate Authority (e.g. Veri-Sign) is also trusted.
However this brings in a new problem as CA issues certificate for many Servers so to identify this. The CA issues certificate on specific or wild card domains.
Example of a typical handshake scenario
The client sends the server the client’s SSL version , cipher settings, session data, and other information that the server needs so as to facilitate communication between them through Secure socket Layer.
Server repeats the step and includes the certificate this time and if client has requested any resource that needs authentication, it may also request for clients certificate.
Then the client checks the resources provided by the server and if it is trustable the client proceeds to the next step else the connection is revoked.
Using the data obtained from the server so far the client generates a key and encrypts the same with the server’s public key found in the certificate and sends it to the server.
If the server requested authentication from client the client also sends a signed data that is unique to the particular session along with clients certificate and the encrypted key mentioned earlier.
If client’s authentication is required as to validate the client the server checks the client’s identity and if this fails, the session is terminated else the client uses its private key to decrypt the key send by client which is then processed by the server as well as the client to generate a secret key.
The client and server uses this key to generate a symmetric (unlike the asymmetric key used earlier which uses different key to encrypt and decrypt) key which is further used to encrypt and decrypt the communication.
Then the client and server sends messages to each other and confirms that further communication will be encrypted with this symmetric key to verify integrity.
Using a secure connection adds one layer of security to your data transfer than using a normal HTTP connection. Especially when the user is using some public Wi-Fi networks and can help us in keeping our users communication to the server secure and protected
The certificate described earlier uses RSA algorithm to generate public and private key
Note: This doesn’t assure complete safety of your users but it is 1 step closer
Let us keep our users Safe!
The author of this blog is a CEH v 7.0 committed to protect user privacy.