Is There A Network Protocol for Your Mobile Apps That Offers A Higher Security Level While Consuming Less Bandwidth Than HTTPS? Yes, There Is

First of all, you want to consider whether you need secure communication. Only very few people do such as those working with customers, your company or whoever works with your data sources, e.g. mobile apps, mobile application backends, web services will help you with the decision.

It is good to know that secure communication costs data bandwidth and performance. Fortunately, certificates required to secure communication are free and there is no inherent technical struggle.

For mobile apps or websites that don’t have logins, forms or features to extract data, you don’t need secure access. For banking websites, mobile apps and mobile banking services, without a doubt, secure communication is a must. But nothing is ever black and white. There are many web pages, mobile apps and web services that deserve protection even if they are not related to banks or money. [1] Surprisingly though, banking websites or banking apps are often not the most secure.

Information systems that are used by the military or used to control power plants, industrial engines in factories and manufacturing plants need the ultimate in security protection. These systems are usually designed with restricted access. Only granted users from allowed endpoint devices with the proper configuration can connect to these systems.

If you agree that your application backend needs encryption, you have several options. Choosing a particular security technique depends on the type and the recipients of the data source. If you have one file and one recipient, you need symmetric encryption [2] which implements a shared secret (password).

Remember that this approach is useless for web pages, applications or application backends that transfer sensitive data and require usernames/passwords.

We need something smarter.

Asymmetric cryptography


Every user has a private and a public key. A Certification Authority creates a certificate by signing the user’s certificate which is bounded to the private key. If you trust the Certification Authority, then you can trust the user certificate. Many Internet users don’t have certificates. This is not a problem because the web browser or the mobile application that wants to connect to a secured backend resource simply generates an ad-hoc certificate to enable access to the backend system. The communication channel is then secure.

Ad-hoc certificates however have their disadvantage. You don’t know who is accessing the application backend until they provide their credentials, and you expose your backend to everyone and pray that bad guys will never want to attack it.

Let’s imagine that someone gets in the middle of the communication between the real mobile user (the victim of the cyber attack) and the application backend that is supposed to read everything sent by this user. The backend doesn’t know if it is communicating with an attacker or a legitimate user. The hacker receives the data and forwards it to the victim. Sometimes the victim notices that the application is trying to inform him about a certificate mismatch, but how often do you ignore the certificate mismatch warning and continue browsing? The attack is now successful, and the hacker can read everything. [3]

Not quite secure, huh?


Most users do not know that if they ignore the warning about the security risk and continue with their Internet activities, they effectively allow a Man-in-the-Middle attack, as explained above. They expose all transferred data to everyone. The weakest point in the communication is a user who is not aware of security risks. According to SCMagazine, human error is cited as a leading contributor to breaches. [4] A well-programmed application that has security incorporated from the beginning protects the users from making wrong decisions.

Identifying both the client and the server is more important than it appears.

Just think - what makes military or SCADA systems secure, assuming that they were designed with security in mind given the sensitive data they gather and process and the environments they operate in? The application backend “knows” the parties on the other side of the communication even before the user/client provides their credentials. The backend can refuse the connection to anyone who doesn’t have access rights and a trusted certificate. The backend simply limits access to the server prior to any user authentication. Thus, the attacker has no way to perform Man-in-the-Middle types of attacks.

SeaCat verifies both sides of the communication. No one without a trusted certificate can connect to the data resource. After successfully verifying the user certificate, SeaCat allows the establishment of the connection and a secure communication channel, followed by the user authentication using their username and password, for example.

Let’s look at HTTPS and SeaCat

Now you have an idea on the overheads in time and bandwidth for secure and encrypted connections, let’s examine the differences between HTTPS and SeaCat in more detail.

In both protocols, SeaCat and HTTPS start every connection/session by verifying the server certificate and establishing a secure connection. SeaCat has one extra user certificate validation to identify the user that requires additional data. This approach is compensated by ensuring the communication channel persistency. An HTTPS session usually ends after 5 seconds of user inactivity. After that, the certificate verification has to be repeated.

HTTPS is not well-suited for typical user behaviors. Who clicks every 5 seconds? Is 5 seconds enough to read the requested information? Not really. You might want to read this article “The Huge Cost of HTTPS and the Impact on Mobile Apps” to see why HTTPS consumes a lot of your bandwidth and lowers the application’s performance. [5]

For this reason, SeaCat session lasts 2 minutes, requesting only occasionally new certificate verification, consuming less data and speeding up the communication. The smaller the size of the data being sent to/from the application backend, the more visible the effectiveness of SeaCat.

We mention the size of the data because a typical data package exchanged between the client and the data source is very small; around 1KB or less.

Secure or not secure, the choice is entirely up to you.

If you transfer sensitive data like credit card numbers, bank accounts, personal records, trade secrets, etc. and decide that having secure connections is necessary, you have two options.

You can use the slower and less secure HTTPS protocol if you are not concerned about the repetitiveness of the certificate validation which slows down the communication or the lack of client identification which creates opportunities for hackers to hijack your communication and steal important information.

You can see that it’s no brainer to choose a faster and more secure protocol like SeaCat.

If you'd like to get a true assessment of the architecture and security of your mobile application, please request a FREE Demo. Or, to learn more about TeskaLabs’ SeaCat Mobile Secure Gateway and how we can help you with the security of your mobility solutions, please visit



About the Author

Jiri Kohout

TeskaLabs’ VP of Application Security, Jiri Kohout, brings years of experience in ICT security, having served as the Chief Information Security Officer for the Ministry of Justice and Chief Information Officer for Prague Municipal Court. He cooperated with the Czech National Security Agency to prepare the Czech Republic cyber security law.

You Might Be Interested in Reading These Articles

Why Developers Are Boosting Up Their Mobile Application Security?

Mobile application security is a significant issue for developers. Most try their best to make mobile apps secure and safe for their users. Here are some of the other reasons why developers are boosting up their mobile application security.

Continue reading ...

security development

Published on April 14, 2015

You Can Build Apps for the Apple TV, But Do You Know How to Do It Securely?

Apple will want to dominate the market for TV apps. To achieve this objective, it’s understandable that Apple makes it easy for app developers to create apps and games for the Apple TV platform using tvOS and profit from them just as they have already done so for the iPhone and iPad devices. Developers can leverage similar frameworks and technologies since tvOS is just a modified version of the iOS. They can even retrofit the apps that were previously developed for iOS to support the Apple TV’s tvOS.

Continue reading ...

mobile security

Published on June 29, 2016

The 8th version of the European Certificate Trust List (ECTL) for C-ITS has been released

The Joint Research Centre of the European Commision (EC JRC) released the eight edition of the European Certificate Trust List (ECTL) used in Cooperative Intelligent Transport Systems (C-ITS). L0 ECTL v8 contains five new Root CA certificates and one re-keyed Root CA certificate. Three out of five newly inserted Root Certificates are installations that run on the TeskaLabs SeaCat PKI software for C-ITS.

Continue reading ...

press automotive c-its v2x security

Published on September 16, 2021