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.
Data encryption tool for GDPRMore information
Most Recent Articles
You Might Be Interested in Reading These Articles
The previous tutorial introduces several concepts and helps you understand the basic of REST API integration with iOS client written in Swift. There are several limitations, with data storage being the most important. This article provides instructions on how to work around this restriction.
Published on November 25, 2014
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. 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.
Published on April 16, 2014
SeaCat requires to specify one TCP port that is eventually used for client-gateway communication. Clients connect to this port to establish TLS channel that is used to exchange requests and related responses. SPDY-based communication protocol is used for traffic in this channel.
Published on May 23, 2014