Software architect's point of view: Why to use SeaCat

I've recently received an interesting question from one software architect: Why should he consider embedding SeaCat in his intended mobile application? This turned into a detailed discussion and I realised that not every benefit of SeaCat technology is apparent at first glance.

High-level architecture
Typical deployment scheme of SeaCat

Let me discuss the most common challenges of a software developer in the area of secure mobile communication and the way SeaCat helps to resolve them. The initial impulse for building SeaCat was actually out of frustration of repeating development challenges linked with implementation of secure mobile application communication. So let's talk about the most common challenges and how SeaCat address them.

HTTPS doesn't not equal 'secure' HTTP

HTTPS is probably the most widely used application of SSL/TLS protocol. It adds encryption to good old HTTP and it is broadly available. Despite its name, however (Hypertext Transfer Protocol Secure), HTTPS doesn't provide instant communication security.

You can of course implement extremely secure communication over HTTPS, but it will require relevant, non-trivial effort coupled with detailed knowledge of computer cryptography. Very often a development team decides to implement a 'basic' HTTPS and leave the details for later. You can guess what happens next: business functionality commonly gets top priority, no one really bothers with security requirements anymore because it is working, and there are no complaints from users.

Incorrectly configured or used SSL/TLS will likely not produce bugs. Well, black hats are not exactly known for filing bug reports. A common application bug can be fixed, a patch can be deployed and the relevant bug report is closed. An exploited security issue can be indeed closed too, but damage is usually linked with significant loss of credibility or confidence of users or sponsors. This is not so easy to repair retrospectively.

The major benefit of SeaCat is that it provides an already implemented secure channel that is ready to be plugged into your application. It consists of a properly implemented server and client, respecting all required and recommended cryptographic practices. The server and client are tuned to interact with each other in the most secure way, saving long weeks of effort that are required in implementing, configuring and testing custom-built HTTPS components.

Enabling HTTPS in the mobile application is easy; the difficulty is to build it really secure.

HTTPS is a proven, reliable standard

Yes, I agree. We don't want to introduce anything new or proprietary. SeaCat is actually using SPDY as a transport layer; this is Google innovative protocol that is designed to move HTTPS to the current century. If you are using, for example, Google Chrome, you are using SPDY already. HTTP has some non-optimal features; it was not particularly designed for latency and mobile devices. SPDY addresses these quite nicely and it is truly an innovative way forward, maintaining backward compatibility and established paradigms. Actually the initial draft of HTTP/2.0, the future of the web, is based on SPDY. SPDY holds great potential for mobile devices, for which latency is more of an issue, and the market is catching on.

You, as a software developer, are still working with HTTP requests; SeaCat will transport your requests effectively over SPDY and return normal HTTP response to you. You don't need to change anything on the client, server or design. On top of that, you will get a nice performance kick for free. SeaCat SPDY implementation is optimised for mobile devices; it reduces number of SSL/TLS handshakes on one side, keeping connection with the server for only as long as needed, saving mobile device battery power.

HTTP indeed provides you with Keepalive and Pipelining which can be surely beneficial. However, the developer needs to make sure that the server or reverse proxy handles them properly, adding more effort to a project. Both of these technologies are difficult to debug and test.

SeaCat uses a newly available innovation of HTTP to gives you benefits while sticking with traditional ways of interacting with remote APIs. There is much more that can be archived by this approach, for example, message-oriented communication or push (I plan to write a dedicated blog post about these).

More informations:

Multi-target gateway and load balancing

SeaCat server can be understood as a reverse HTTP proxy that uses SSL/TLS and SPDY on a transport layer. This is essentially correct simplification; however, practically you get much more. SeaCat represent a secure gateway to an internal IT infrastructure and you can configure as many endpoint targets as you need or wish. Does your application need to access two HTTP APIs and download reference data from a static HTTP server? No problem, you can configure your SeaCat server to provide access to all three targets.

You can deploy more than one SeaCat server to remove the risk of single point of failure and/or to provide load balancing ability. This whole is transparent to a developer; there is no need for explicit connection management as it is handled transparently for you. You can just consume HTTP traffic as you are used to already today.

Every target has it's logical name that is used to address a particular target. In the application, you are using URLs like https://main-api.seacat/resource.json or https://database.seacat/query?n=31&l=10 and SeaCat transports and translates that for you, physically maintaining one encrypted SPDY connection with a server.

Certificate management

SeaCat manages the whole PKI infrastructure needed to support a really secure channel. It generates private keys on mobile devices, and transports Certificate Signing Requests to a server for an approval. It distributes CA, server and devices certificates in a trusted way over a presumably hostile network.

It also handles renewal procedure with no extra effort. It also allows to revoke certificates of particular device, effectively disabling access for given device to protect a network completely.

These all are mandatory requirements for secure and reliable communication between a mobile application and its backends. A typical HTTPS client doesn't give you any of these, leaving implementation completely with you. SeaCat includes all of these, implemented properly and thoroughly tested.


SeaCat is:

  • safer
    You are getting well-tested compact and complete solution.

  • faster
    It gives you a set of components that you will build for months.

  • easier
    It handles all SSL/TLS details for you transparently.

Data encryption tool for GDPR

More information

You Might Be Interested in Reading These Articles

Save the Day and Do the Impossible - Business Intelligence Community Stays Tuned

Let us share with you fresh news from the SeaCat kitchen. A few weeks ago we had a workshop with one potential customer who was currently working on a mobile application which should access Oracle Business Intelligence (BI) suite, basically Oracle Business Intelligence Mobile HD based solution. We piloted Oracle BI SDK & SeaCat integration.

Continue reading ...

tech video kitchen-news BI

Published on November 30, 2014

Streaming Data from Various Sources

One of the main research and development topics nowadays is data processing and analysis, which can help companies discover relevant information about their customers or technologies using reports, visualizations, dashboards, and other business intelligence outputs.

Continue reading ...

startup development

Published on June 01, 2018

What Is Mobile Application Containerization or Wrapper, and Why It Needs to Go?

Containerization is an alternative for full machine virtualization. You probably know well-known containerization technology from Docker or Rocket. However, this article addresses the pros and cons of mobile “containerization” or wrapper used to isolate the mobile app from the mobile operating system or other applications installed on the same device. These type of “containerization” work in a different way.

Continue reading ...

tech security

Published on September 27, 2016