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.

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:

• SPDY Whitepaper
• A comparison of SPDY and HTTP performance - from Microsoft

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.

Tl;dr

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.