Data privacy: How to ensure security in Connected Business Systems

Harsha Kodnad

As the world increasingly moves towards connected applications, security and privacy of data becomes extremely critical and must take centre-stage. This is especially critical for business systems, as the data in them is extremely sensitive. With an increasing concern over security of data and quite a few instances of data breaches in the recent past with the biggest of tech giants, let’s see what exactly it takes to build a highly safe connected business application.

Understanding HTTPS Communication:

It is important to understand how a HTTPS communication happens to understand secure connected technology.

When we look at HTTPS communication, which is typically between a browser and a ‘web server’, it goes through different stages

• Handshake: Browser and web server agree on the TLS (Transport Layer Security) versions, cipher suits supported and so on, including the web server sending its SSL (Secure Sockets Layer) certificate to the browser.


• Authentication: The browser validates the certificate for its authenticity that it is talking to the right web server as intended. With this the browser knows that it is talking to whom it is supposed to!


• Session establishment: A session is established using a pre-master key and later agreeing on the session keys to encrypt the communications. With this, a secure symmetric encryption is achieved between the browser and the web server


• Application Layer communications: With the established session and security, application layer communication starts. i.e. asking for certain data to server and server responding with the data and so on.

How can the technology be designed?

Typically, any web application works in a ‘Client Server’ model. i.e. browser being the client and a server application running on the cloud. The browser reaches the right server via the URL (say www.myapplication.com) and does required handshake and authentications. There are mainly three constraints here:

• Each customer need not have a domain name purchased


• They need not have a static IP address


• Their data/app need not run on the cloud for security and privacy reasons. Hence, the application as a ‘Web Server’ will have to run on the customer’s premise location

Now, we need a central cloud application, to which on one side, the application can register their availability and the data / information published, and on the other hand the browsers can talk to them. Making it act as a ‘Proxy’ server to mediate b/w the Browser and application.

• You connect your business application to make it available for browser access

The application running on the desktop acts as a ‘HTTPS client’ and connect to the ‘Browser Proxy Service’ on the cloud.  It is done using the above HTTPS based communication. The system establishes a dual channel communication (one for client’s requesting things to server, and other for the Server to respond back to client on events)

• You access HTTPS Web server via any browser on any device and complete user authentication

Here, browser acting as a HTTPS client, talks to the application’s cloud backend to authenticate the user and post that, listing the data that is accessible to the logged in user.

• You access data that is available online via browser

Browser acts as a HTTPS client. The browser establishes connection with the Browser Proxy Service.

This is where the interesting things happen. The browser does the initial handshake, authentication (as in the HTTPS stages above), with the ‘Browser Proxy Service’. Here, the browser being HTTPS client, and the Browser Proxy Service on cloud acting as a HTTPS web server.

With successful handshake and authentication and after validating the ‘user / company’ being accessed, the browser proxy service, short-circuit the connection with the browser and application (right instance which had the company data and the browser), itself acting as ‘Proxy’ as the name suggests.

With this, the further steps of session establishment and application layer communication happens between the browser and application. Yes, here while browser continuous to acts as the ‘HTTPS client’, the application on the customer premise/desktop, acts as the HTTS web server.

Making session establishment and providing REST protocol-based application communication to access data.

How is the data Secure?

• The Browser Proxy Service on Cloud only need to decrypt the meta data (some headers) to identify the routing request responses to right Tally application instances and back. It passes the encrypted request - response as is across browser and the application not decrypting user data. Giving customers the promise of data security, that, even the creators of the software do not access or keep to their data!


• While user authentication (occasionally as per the session rules), happens with backend systems, the Authorisation / access control of the data access to any given authorized user is in your hands at the application level. Every request is validated against this and hence, at any moment, it is possible to stop giving access to an authorized user.


• You have complete control over things. i.e. when you want your data to be available over internet, when you want to disconnect it from being available online, who all can access at what point of time and so on.


• Zero data is stored on the device from where browser access is done

The author is Director- Technology at Tally Solutions.