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).
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://database.seacat/query?n=31&l=10 and SeaCat transports and translates that for you, physically maintaining one encrypted SPDY connection with a server.
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.
You are getting well-tested compact and complete solution.
It gives you a set of components that you will build for months.
It handles all SSL/TLS details for you transparently.
Most Recent Articles
- How big Log Management or SIEM solution does your organization need
- And the winner is...Go!
- Case Study - TeskaLabs SIEM for large Czech government organization
- TeskaLabs helps LINET with cyber security compliance for medical devices
- TeskaLabs and University hospital in Pilsen launches a pilot of zScanner - open source mobile app for medical photo documentation
You Might Be Interested in Reading These Articles
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.
Published on September 27, 2016
What compiled language for a backend development is the right one to move our technological stack to the next level? We've started to look around for a compiled computer language that will enable us to build microservices with higher performance. Now, don't get me wrong, we don't depart from Python at all. It is the extension of the portfolio.
Published on November 01, 2021
As the market with Cloud Computing and Mobile devices is getting bigger, there is another specific option available. It's called (Mobile)Backend-As-A-Service (BAAS) and it is extremely useful in situations we want to subscribe a complex backend service (alongside the core backend solution, there is usually a lot of additional functionality and statistics) and primary focus on development of client part of mobile apps for instance.
Published on January 31, 2015