NEW Game developers: check out PacketZoom Mobile Connect
Date By Stan Hu, Tim Doyle Tags iOS / HTTPS

HTTPS

With the release of iOS 9, Apple has pushed developers to use HTTPS by default. While HTTPS provides an additional level of security, this change to HTTPS comes with some cost. This post discusses the implications for app developers and PacketZoom users.

Why HTTPS?

Most developers use HTTPS to protect sensitive information, such as credit card data, from being intercepted over the network. But we've also seen less obvious reasons to use HTTPS for non-sensitive content. For example, developers also enable HTTPS to prevent intermediaries from examining their static content and downsampling images unbeknownst to them. Some carriers do this to reduce bandwidth and save costs. Since regular HTTP traffic comprises a large amount of Internet traffic, even a 10% reduction can have a big impact. While most people may not notice these behind-the-scenes changes, game developers do: images that have been "optimized" can look blotchy on high-resolution devices. Switching on HTTPS prevents any intermediaries from interfering with their content. In this case, no sensitive information is being exchanged, but maintaining file integrity is paramount.

Other developers say they just enable HTTPS to avoid warnings displayed on their Web views. For these users, HTTPS is just a means to show a solid padlock:

HTTPS padlock

iOS Developers

With iOS 9, developers have to allow HTTP explicitly, as Apple is pushing HTTPS to be used all the time. Using HTTPS in your app will not only make it harder for a malicious user to snoop, but it also makes it more difficult for mobile carriers to alter static assets without your knowledge.

If you are an iOS developer, iOS 9 requires you to do one of two things to your app:

  1. Switch all the URLs used in your app from http:// to https://
  2. Add domain(s) that can be accessed via standard HTTP in your Info.plist

As an app developer, you may choose option 2 if your Web server doesn't support HTTPS. You may also have other reasons why you don't want to use HTTPS (e.g. cost issues, firewall constraints, religious grounds), which is why Apple has provided a way to whitelist certain domains via the NSExceptionDomains key. See this document for more details. You can also disable HTTPS enforcement completely by adding the NSAllowsArbitraryLoads key and setting the value to true.

If your app currently uses standard HTTP URLs and you don't implement either option, the App Transport Security module in iOS will fail when it attempts to retrieve the URL with a scary error message, such as the following:

2015-09-23 12:48:23.428 MyApp[76464:14245919] con did fail with error: Error Domain=NSURLErrorDomain Code=-1022 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection

PacketZoom Users

PacketZoom has supported HTTPS for a while, but we've disabled it by default to prevent developers from accidentally configuring the SDK to send sensitive data (e.g. user information, credit card details, etc.) over the PacketZoom protocol. While PacketZoom encrypts all communications with its servers to prevent casual snooping, the current protocol is not yet intended to provide SSL-level security. It does, however, speed up downloads for static assets.

Because of the change in iOS 9, we have now activated HTTPS for all new PacketZoom developers. The PacketZoom dashboard provides regular expression controls to whitelist URLs to be routed through PacketZoom.

Here's an easy litmus test: if your file can be downloaded via a publicly-accessible URL (e.g. on Cloudfront, Akamai, etc.), then PacketZoom will work fine with HTTPS.

We have many customers that use PacketZoom for this today. In fact, we have seen an additional performance boost using PacketZoom for HTTPS assets over HTTP-based ones. Mobile clients are quite sensitive to additional round-trips and setup times. Since the PacketZoom service proxies assets betwen the Web server and the client, it removes the HTTPS setup times from the equation.

Does HTTPS Really Come for Free?

Most users don't realize that there is no such thing as a free lunch when it comes to HTTPS. CDNs generally charge more for handling HTTPS links than they do with HTTP. For example, Amazon's Cloudfront charges 30% more for each HTTPS download. This can add up quickly.

In addition, consider the cost of maintaining SSL certificates. App developers can buy a low-cost SSL certificate option for anywhere from $150-300 a year, but many companies pay CDNs to host their domains and certificates. For example, Fastly customers pay a one-time setup fee between $500-$2000. There is a $500-$1,200 charge for each new domain or domain change, and then an additional $100-$1500 monthly recurring fee.

The most hidden expense from HTTPS comes from the cost of maintaining some semblance of operational security. OpenSSL holes have been discovered with increasing frequency over the last few years, with such colorful attacks as Heartbleed, BEAST, CRIME, and POODLE. Each hole sets off a scramble by OS and package maintainers to fix the bugs. System administrators have to be vigilant about watching for these critical fixes, and then they have to be thorough in applying them for all affected software. It's hard to be sure all packages have been patched, as many embedded devices have software that still run old versions of OpenSSL.

Financial costs aside, using HTTPS also incurs a performance penalty to the average user. Consider the following diagram of a typical SSL setup flow:

SSL handshake

The top portion covers the TCP connection setup, which is common to both HTTP and HTTPS. However, notice the additional round-trips in the green for SSL. The number of steps can increase, depending on what ciphers and certificates need to be negotiated between the client and the server. On a low-latency connection between the two parties, this setup time is negligible, but it becomes a bigger deal on mobile networks, where latencies can easily spike over 400 ms. A mobile user on a lossy network may fail to establish a session just because of the SSL verification step.

Conclusion

In short, Apple's update in iOS 9 will cause all developers either to use HTTPS going forward or force them to override the App Transport Security module. Switching to HTTPS has both financial and performance costs that developers should consider. It makes sense to continue using HTTPS to protect sensitive data, but for non-sensitive data, developers will need to decide for themselves whether it really is worth cost.

Starting today, PacketZoom users will now be able to use HTTPS by default, with the caveat that only static content should still be routed through PacketZoom. We think it will be worth your while.


Share On:


Comments

comments powered by Disqus