• Tweet

• Tweet

Overview

Securing the application’s environment is one of the primary concerns every software engineer should have in mind when building professional IT products. Depending on the business requirements, certain security precautions should be taken into consideration to protect against various attacks like SQL Injection, Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) being the absolute minimum.

There are different ways to address these security vectors like taking care of the user’s input and introducing additional business and database layers. The first step, however, would be to introduce a secure way of device-level identification which should provide protection against Man-in-the-middle (MIDM) attacks.

In this article, I’m going to show you one of these methods – how SSL/TLS works – why to use it and when to use it.

What is SSL/TLS ?

SSL (Secure Sockets Layer), and its successor TLS (Transport Layer Security), are security protocols based on TCP and used for establishing an encrypted connection between a server and a client, using both symmetric and assymetric encryption.

SSL and TLS as terms are often used interchangeably. Although there are some actual differences between the them, they’re considered equally secure. In fact, if you specify TLS on your browser but the server itself doesn’t support it, SSL will be gracefully used.

What is HTTPS ?

Hypertext Transfer Protocol Secure (HTTPS) is a Layer 7 extension to HTTP utilizing an encrypted channel over SSL/TLS. Used properly, it effectively minimises the risk of Man in the middle (MIDM) related attacks, providing secure connection between a server and a client (like bank transactions and other secure payments) which can be a browser or a standalone desktop application. It should be clear that the encrypted connection itself provides almost no benefit itself without a trusted certificate provider.

How does SSL/HTTPS work ?

Symmetric encryption

The Symmetric encryption uses only one key for both the encryption and the decryption of a given message. One of the main advantages of this type of encryption is the small amount of time required for the process itself. Examples of Symmetric algorithms are: Twofish, Serpent, AES (Rijndael), Blowfish, CAST5, RC4, 3DES, and IDEA. The most often used one is probably the AES (Advanced encryption algorithm).

If only Symmetric encryption is used, the Server would first send the key to the client, and after that encrypt the message with the key itself. If an attacker intercept the key, any further communication would be easily compromised.

Assymetric encryption

The Assymetric encryption uses two keys instead of only one (a public and a private key). The rule is that data encrypted using the private key can only be decrypted using the public key. This type of encryption provides better security, but requires much more computing power. Few of the popular public-key algorithms are RSA, Diffie-Hellman, Digital Signature Algorithm, ElGamal, ECDSA, XTR. RSA, which stands for Ron Rivest, Adi Shamir and Leonard Adleman – its creators – is probably the most popular one.

In order to bypass the limitation described in the previous section, a combination of both methods is actually used in SSL. Having that in mind, the process becomes something like this:

First, a TCP connection is build by performing a three-way-handshake. The client then sends a number of configuration parameters including the exact version of SSL/TLS being used, information regarding the specific algorithms and compression methods. Next, the server checks the highest version of every of the components on both sides and decides which one to choose. The server then sends its certificate so the client can be sure of its identity. Then if everything is ok, the exchange of keys begins.

Now you are probably wondering what this certificate is for. And the question is quite relevant, because without the certificate HTTPs/SSL/TLS can easily be cracked by most of the Man in the middle attacks. Sniffing the traffic, the attacker can intersect both client’s and server’s requests, relaying the channel and effectively impersonating both of them. In that situation, the client thinks he’s talking to the server, and the server thinks he’s talking to the client. Here’s where the Certification Authority (CA) comes.

Certification Authorities (CA)

In order to truly verify the server’s identity (on machine level), a third party needs to be introduced.

In SSL, this is called a Certification Authority (CA). Every security critical domain should register itself with a CA so it can receive a certificate. Simply said, the Certification Authority creates a certificate, encrypts it with its private key and sends it to the server. After that, every time a client connects the certificate signed from the CA is send as part of the initial handshake process. The client can then try to decrypt the certificate using a public key provided by the certification authority, or send a direct request to check if the identity of the server is intact.