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 (LetsEncrypt.org) 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.

TESTING THE OVERHEADS OF DIFFERENT NETWORK 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.

RESULTS FROM THE TEST

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

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.