HTTP vs. HTTPS

Introduction

HTTP is the framework that the web (and networked mobile apps) is built on. Nearly every file delivered on the web and in mobile applications uses HTTP for the transport. However, data sent via HTTP is not sent securely, meaning that if it is intercepted, it can be read by anyone.

This Best Practice looks at the benefits of using HTTPS, a highly secure version of HTTP, to help prevent intercepted data from being read.

Background

When your mobile app or website is transmitting data to your server (or to a device), you have no control over the network being used by your customer. They may have connected to a "free Wi-Fi" hotspot that is surreptitiously collecting all of the data transmitted across it.

For images of cats, or videos of 80's pop stars never letting you down, HTTP is probably adequate – as this data is not sensitive, nor does it reveal any potential private information.

However, there is a lot of information that should remain private. Data like passwords, credit card numbers, or e-mail are private information that should be kept in an encrypted container during transport across the internet. For this sort of data, your application should utilize HTTPS. Essentially, adding that "S" at the end means that all of the data you send will be encrypted from the device to the server (and vice versa).

AT&T Video Optimizer will tell you how much of your data is sent via HTTPS on the best practices page:

As you can see, the Total Data Transferred is 7 MB (3rd line), but the top line shows that 66% (or 4546KB) is HTTPS and was not analyzed.

In a future version of Video Optimizer, we expect to be able to decrypt HTTPS for analysis, but for now, this is a good benchmark to see how much data sent by your application is HTTPS.

But what data is sent HTTP and what is sent HTTPS?

Video Optimizer can tell you this as well (to a degree). HTTP traffic generally is sent over port 80, and HTTPS traffic is sent over port 443. The Video Optimizer diagnostics tab can show you which TCP flows are HTTP vs HTTPS:

In the middle chart, each TCP or UDP flow is listed. The following screenshot shows 5 flows. The first 3 travel from the remote port 80 (and therefore are HTTP), and the 4th and 5th flows are on port 443 – HTTPS.

If we look at the requests and responses for an HTTP flow, we can see what the requests and responses are, in this case, a number of images for a news app:

On the HTTPS flow, the data is encrypted, so Video Optimizer cannot tell us what was sent over the network:

All we know is the size of the files sent (because we know the amount of data sent across the network).

If you are looking for private data (and you know your app is sending it), but you do not see it in the ARO logs, it is likely being sent via HTTPS.

What is the performance Hit to using HTTPS?

When a HTTPS connection is set up, there is one additional round trip to share the key. So, there is potential for a short delay on the connection set up.

How about decryption?

For many years, there was a concern on using too much HTTPS due to the decryption overhead. When Google rolled out Gmail as HTTPS, their servers had a 1% jump in CPU. So adding HTTPS is no longer computationally restrictive.

The Issue

If your application is sending data solely through HTTP, your customer's data (or perhaps even your company's data) might be at risk. Therefore, when it comes to delivering content more securely to mobile devices, we recommend that you use HTTPS.

Best Practice Recommendation

The Best Practice recommendation is to use HTTPS for as much traffic as possible. By encrypting your customer's data, you are protecting accidental leaks, which can cost your customer (and your company) money.