Transport Layer Security

Transport Layer Security is used to protect against man in the middle attacks. HTTPS (also called HTTP over SSL/TLS) is a protocol for secure communication over a computer network which is widely used on the Internet. HTTPS consists of communication over Hypertext Transfer Protocol (HTTP) within a connection encrypted by Transport Layer Security or its predecessor, Secure Sockets Layer. The main purpose of HTTPS is to authenticate the server and protection of the privacy and integrity of the exchanged data.

What Is TLS/SSL and how it works?

Transport Layer Security(TLS) and its predecessor Secure Sockets Layer(SSL) both are a standard security protocols for establishing a secure connection between a server and a client typically used for web server and mobile device/browser. The most common use of SSL is to provide protection for confidential data, such as personal details or debit/credit card information sent by any client.

The TLS/SSL layer has following main purposes:
  • Verifying that you are talking to the server which you want to talk.
  • Ensuring that only the server can read what you send to it and only you can read what it sends back.



What is Digital Certificate?

A digital certificate is an electronic document use to exchange information securely over the internet using the public key infrastructure (PKI). It is also known as public key certificate or identity certificate.
It contains the name of certificate holder, expiry date and serial number, certificate holder's public key and digital signature of the Certificate Authority (CA).

Versions of TLS/SSL 

SSL 1.0, 2.0 and 3.0
Because of security flaws in the protocol all the SSL version are deprecated
SSL 2.0 was deprecated in 2011 by RFC 6176.
SSL 3.0 was deprecated in June 2015 by RFC 7568.

TLS 1.0
TLS 1.0 was defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0

TLS 1.1
TLS 1.1 was defined in RFC 4346 in April 2006 as an upgrade of TLS version 1.0. 

TLS 1.2
TLS 1.2 was defined in RFC 5246 in August 2008. It is based on the earlier TLS 1.1 specification. 

TLS 1.3(draft)
As of July 2016, TLS 1.3 is working draft and details are provisional and incomplete. It is based on the earlier TLS 1.2 specification. 


How TLS/SSL connection established?

The secure connection is established by a handshake. The goal of this is -

·         To ensure the integrity of data means the data is not altered in between communication. Each message which is transmitted over network includes a message integrity check using a message authentication code (MAC). 
·         Authenticates the communicating parties using public-key cryptography. For each connection validate the certificates presents on both the parties (Server and client).

·         To ensure that only the valid server is able to decrypt the sent data. To make the connection private (or secure) symmetric key cryptography is used to encrypt the transmitted data. For each connection a unique key, algorithm etc. are shared secretly at the start of the session. 

Once the connection is established, both client and server can use the agreed algorithm and keys to send the data securely to each other.

To elaborate the handshake, we can break this into 3 main processes -

1. Hello Message

Client sends a Hello message to initiate the handshake. During this process client also sends all the required information which server needs to create a SSL connection along with various cipher suites (key algorithm) and maximum SSL version that it supports.
Based on client’s preferences server takes the decision on cipher suite (key algorithm) and version of SSL and sends the response to the client with Hello message. This response also contains similar information required by the client.

2. Certificate Exchange
Now both the parties have to prove themselves. First server has to prove its identity to the client. To achieve this server shares its certificate to the client. The client validates the server certificate either via one of self signed certificate or via one of several Certificate Authorities (CAs) that implicitly trusted.
Similarly client also proves itself to the server.

3. Key Exchange
The encryption of the actual exchanged data will be done using a symmetric algorithm which was already agreed in process 1(Hello Message). The client generates a random key. It encrypts this key using the algorithm which agreed during Hello process and server’s public key (From certificate received during certificate exchange). Client sends this encrypted key to server. Server decrypted the key using the server its private key and the handshake process completed.

Now both the parties established secure HTTPS connection and all the data exchange is in encrypted format so no man in middle can understand the data transfer over network.

 Below are the image displaying the flow of SSL handshake-


To find more interesting topics on Software development follow me at https://medium.com/@ankit.sinhal

You can also find my Android Applications on play store
https://play.google.com/store/apps/details?id=com.app.ezynote

https://play.google.com/store/apps/details?id=shakenlock.app.com.shakenlock

Comments

  1. seravina danniella18 October 2017 at 01:50

    Thank you for sharing such an informative article. I really hope I can see other interesting posts. Keep up the good work!


    Melbourne SEO Service

    ReplyDelete

Post a Comment

Popular posts from this blog

Android O: Impact On Running Apps And Developer Viewpoint

Image
It’s been just about a year since Google released Android Nougat. In the next version of its Android operating system, it revealed the first developer preview of Android O (Hoping it’ll named Android Oreo) on 21 March 2017. In this article, we are going to discuss all the important features and changes of Android O from developer’s perspective. The Android O release will be known as Android 8.0. The final version of Android 8.0 will be out sometime in Q3 of 2017 and before that Google has plan to rollout DP #4. Based on DP #1, here are list of major behavioral changes which will impact on all currently running applications when run on Android O platform. ·        Background execution limits ·        Background location limits ·        Handles identifiers(Android ID) differently ·        Account Access ·     ...
Read more

Android Performance: Avoid using ENUM on Android

Image
What and why we use ENUM? Enum in java is a data type that contains fixed set of constants. When we required predefined set of values which represents some kind of data, we use ENUM. We always use Enums when a variable can only take one out of a small set of possible values. For example: public enum Season {   WINTER, SPRING, SUMMER, FALL } Instead of using Integer or String constants, we generally use ENUM to increase compile time checking and avoid errors from passing in invalid constants. Drawback of using ENUM Each value in an ENUM is an object and each declaration will take some runtime memory simply to reference the object. So ENUM values will take more memory then Integer or String constant. Even in old android devices (<=2.2), there were some performance issue related to ENUM which were solved in JIT compiler. Adding a single ENUM will increase the size (13x times than the Integer constant) of final DEX file. It also generates th...
Read more

Local Broadcast, less overhead and secure in Android

Image
Broadcast receiver is an Android component which allows you to send or receive Android system or application events. All the registered application are notified by the Android runtime once event happens. It works similar to the publish-subscribe design pattern and used for asynchronous inter-process communication. For example, applications can register for various system events like boot complete or battery low, and Android system sends broadcast when specific event occur. Any application can also create its own custom broadcasts. Basics of broadcast Let’s discuss some basic concepts of broadcast receiver. Register Broadcast There are two ways to register broadcast receiver- Manifest-declared (Statically) : By this receiver can be registered via the AndroidManifest.xml file. Context-registered (Dynamically): By this register a receiver dynamically via the Context.registerReceiver() method. Receive Broadcasts To be able to receive a br...
Read more