The Outrageous Cost of HTTPS - Why?

I encountered a recurring concern during meetings with developers and technical people about network protocols such as HTTP, HTTPS and SeaCat. Their mobile application used HTTP communication between the application backend and the clients. Because of the demand for higher level of security, they implemented HTTPS by setting up certificates issued by LetsEncrypt Certification Authority ( in their application backend server. The shift between non-secure HTTP connections to HTTPS connections leads to a significant increase in the amount of data being transferred from/to the clients. “Our customers complain that the application consumes a lot of data. How can this be possible?” they asked.

Let me shed light on this topic and provide you with an explanation about the traffic at the server side.

HTTPS is a popular protocol used for securing the communication between clients and data sources such as web pages, application backend servers or web services. Its usage and growth are due to the demand for a high level of security requirements from security-conscious companies and users. Moreover, from April 12, 2016, HTTPS is free to use thanks to LetsEncrypt, a free, automated and open certificate authority that offers certificates for free.

So it is up to IT administrators to start using HTTP, and there should not be any barriers for adopting a higher security standard and implement HTTPS.

The downside of HTTPS protocol

Despite all the advantages, HTTPS is slow and consumes a lot of bandwidth. Let's have a look at the overhead statistics of HTTPS in comparison to HTTP and SeaCat protocols.


There is no straightforward way to test the protocol overhead because there are many dependent factors. We performed tests using different sizes of payload, ranging from 128 bytes to 64 kilobytes.

HTTPS and SeaCat protocols use the same certificates for comparison purposes so that we had the same parameter values. The type of request affects the amount of data consumption, for example, a GET request is smaller while a POST is slightly bigger. The speed of the request is another factor which can dramatically affect the payload.

When users are browsing the Internet or using a mobile application, they naturally follow a similar pattern: request data, wait for the data, read it, and continue to another web page or try another functionality of the app and repeat the process. HTTP/1 allows multiple requests in one connection, but this connection usually times out after 15 seconds. After the connection times out, it is necessary to repeat the certificate negotiation between the two sides of the communication. This recurring process consumes bandwidth.

In our comparison, we defined the following behaviors:

  • 5 times POST request (to send the payload)
  • 5 times GET request (to download the payload)
  • 10 second pause
  • Repeat step 1 to 3 10 times
  • Do step 1 to 4 for each payload size (10 sizes)

We kept the same headers for all requests, intercepted the traffic with Wireshark and TCPDump utilities and used the RAW sizes (in bytes) of the TCP packets for calculation.


We had results for every payload size: 128B, 256B, 512B, 1kB, 2kB, 4kB, 8kB, 16kB, 32kB and 64kB. The overhead for HTTPS was bigger because of the certificate exchange described above. For smaller payloads, the certificate exchange was the biggest portion of transmitted data. This proportion decreased as the payload size got bigger.

The overheads of different protocols:

The impact of HTTPS on mobile apps

The payload for a typical mobile application is 1kB. Mobile applications are designed to consume as little data bandwidth as possible. In comparison to browsing the internet from a desktop or laptop, browsing on a mobile device requires fewer graphics.

Mobile apps exchange smaller data payloads; thus, are significantly affected by HTTPS bandwidth and time overheads because if the application has to exchange certificates often, the bandwidth consumption gets higher which slows down the application overall.

This overhead impairs the user experience, and of course, they will complain about it. It’s worth thinking more about the protocol that we implement into the mobile application. We have various options from HTTP, which is not secure to HTTPS, which is more secure but dependant on many other factors which we will discuss in this article. If you wonder if there is a network protocol for your mobile apps that offers a higher security level while consuming less bandwidth than HTTPS? Yes, there is.

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

SeaCat tutorial - Chapter 1: Hello World (iOS)

This is the first practical tutorial in our tutorial series to demonstrate the strength and capabilities of SeaCat secure access solution. Our goal is to develop several sample applications and uncover the best practices you might be interested in.

Continue reading ...

tech tutorial ios osx

Published on August 18, 2014

SeaCat Mobile Secure Gateway Architecture

SeaCat Mobile Secure Gateway is built using the SeaCat Application Security Platform. It provides strong protection against multiple types of cyberattacks by securing all application components, including the mobile application, network paths, which present an entry point to the enterprise network and application’s backend servers. It reduces an administrator's workload with easy PKI administration of distributed large-scale mobile applications. SeaCat Security Platform has been carefully designed to be flexible, fast, and highly secure.

Continue reading ...


Published on May 18, 2014

SeaCat Mobile Secure Gateways' Performance Test

We decided to perform this test to validate our architectural, design and implementation decisions in regards to SeaCat performance. Our goal was to build the best-in-class product using the most advanced techniques to deliver highest possible throughput yet not compromising the security of the communication. Results of the test have been fed back into our development team to improve further overall performance characteristics of the solution.

Continue reading ...


Published on July 21, 2014