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

HOW HTTPS WORKS

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?

HOW SEACAT WORKS

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 www.teskalabs.com/products/seacat-mobile-secure-gateway.

Reference

1. https://www.teskalabs.com/blog/golden-age-of-black-hats
2. http://searchsecurity.techtarget.com/answer/What-are-the-differences-between-symmetric-and-asymmetric-encryption-algorithms
3. https://www.teskalabs.com/blog/protect-mobile-app-and-prevent-man-in-the-middle-attack
4. http://www.scmagazine.com/study-find-carelessness-among-top-human-errors-affecting-security/article/406876/
5. https://www.teskalabs.com/blog/cost-of-https

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.