Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > News > Mac News > Google advises developers on how to weaken iOS 9 app security

Google advises developers on how to weaken iOS 9 app security
Thread Tools
NewsPoster
MacNN Staff
Join Date: Jul 2012
Status: Offline
Reply With Quote
Aug 31, 2015, 07:05 AM
 
Google has advised app developers of a way to weaken the security of iOS 9, in order to serve ads to users. A post on the Google Ads Developer Blog offers code to help get around App Transport Security (ATS), a feature in iOS 9 that forces apps to use HTTPS to encrypt data sent over the Internet, with the code disabling ATS so that the apps comply with third-party advertising networks and are able to run some "custom creative code" from Google's own ad servers.

Developers creating iOS 9 apps using Xcode 7 that do not disable ATS will see log message issues where certain content has been blocked for insecurity, such as a cleartext HTTP resource, something that could break the advertisements. Google advises that a "short term fix" to an issue that appears in iOS 9 is to add an exemption to their code that disables ATS, allowing the potentially insecure ad code to run in the app. The fix itself is just five lines long, and adds an exemption to Info.plist, allowing the app to bypass ATS, but keeping other apps secure.

In the post, Google claims it is "committed to industry-wide adoption of HTTPS" in its products and services. It also recommends that developers use HTTPS exclusively when creating a new app, or for existing apps, using it as much as possible and plan to migrate the remainder towards ATS compliance.

Recode notes that, after security-minded experts and developers complained, Google updated the post to clarify its position. An extra paragraph explains the post came about because "developers asked us about resources available to them for the upcoming iOS 9 release," and that they should only disable ATS if "other approaches to comply with ATS standards are unsuccessful." It is also noted that Apple has offered a tech note describing ways to selectively enable ATS for specific HTTPS sites.
     
s219
Fresh-Faced Recruit
Join Date: Aug 2015
Status: Offline
Reply With Quote
Aug 31, 2015, 07:50 AM
 
I am normally a bit wary of Google and their lackadaisical invasion of privacy, but I think in this case, the article's headline has been sensationalized to make something out of nothing, and to purposely make Google seem evil. All they are doing is summarizing an Apple Tech note, already out there, on how to handle http communications in an app compiled under the iOS 9 SDK. I would need to do the same thing in my app to allow connections to an http server (not within my control), in a case where security isn't even a concern. If someone described that as "weakening" iOS 9 security, I'd say they were idiots.

Apple ATS is a new feature in iOS 9 that enforces some strict security protocols on http, but Apple has put a mechanism in place for exceptions in cases where it's not possible to follow those protocols (say for instance, if the server the app connects to can't use those protocols for any one of a thousand reasons). The Google-cited reasons are exactly why these exceptions are possible. It's not about weakening security, it's about reverting to iOS 8 protocols in situations where the iOS 9 protocols can't be used. I think the real article title should be "Google advises developers on how to revert to iOS 8 http protocols".
     
pairof9s
Senior User
Join Date: Jan 2008
Status: Offline
Reply With Quote
Aug 31, 2015, 07:58 AM
 
s219, that's a nice summary of the issue and I tend to agree. My bigger concern is the advertising; it greatly diminishes my viewing/consuming of web pages if only due to waiting so long due to ad loading.

Now ads have been the necessary evil of "free" media, but the trash is getting out of hand. I'd like the compromise be that each and every web page is available in reader mode (which can also be a default mode option in mobile browser).
     
I-ku-u
Junior Member
Join Date: Aug 2011
Location: Cambridge, MA
Status: Offline
Reply With Quote
Aug 31, 2015, 08:13 AM
 
Given the reaction to Google's original posting and the fact that there are malicious ads out there (I've seen the fallout from one of them, it wasn't pretty), I have to disagree with s219.

Yes, that information is directly available from Apple, but Google took that information and initially removed the context of when it is reasonable to consider disabling the feature. That is hypocritical of Google given their position on the publication of 3rd party security flaws. Only after Google received numerous complaints did they restore some of that context, and that is the story.
     
Grendelmon
Senior User
Join Date: Dec 2007
Location: Too F'ing Cold, USA
Status: Offline
Reply With Quote
Aug 31, 2015, 09:00 AM
 
LOL, yeah... nice headline.
     
prl99
Senior User
Join Date: Mar 2009
Location: pacific northwest
Status: Offline
Reply With Quote
Aug 31, 2015, 09:40 AM
 
From Recode website:
"We've received important feedback about this post and wanted to clarify a few points. We wrote this because developers asked us about resources available to them for the upcoming iOS 9 release, and we wanted to outline some options. To be clear, developers should only consider disabling ATS if other approaches to comply with ATS standards are unsuccessful. Apple has provided a tech note describing different approaches, including the ability to selectively enable ATS for a list of provided HTTPS sites.
We’ve strongly advocated for HTTPS protection for many years and we continue to roll it out across our products."

What Google has done is take the easy way out and simply do a thermonuclear act on all of ATS instead of selecting the proper exception. I don't see this as helping their ad providers, I see it as enabling bad behavior.

Google's code:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>

Google simply took the easy way out to turn everything off so they could continue to collect ad revenue. How can anyone support Google on this action?
     
prl99
Senior User
Join Date: Mar 2009
Location: pacific northwest
Status: Offline
Reply With Quote
Aug 31, 2015, 09:42 AM
 
Sorry, should have previewed comment to see how many special characters are removed. Go here, http://googleadsdeveloper.blogspot.com/2015/08/handling-app-transport-security-in-ios-9.html, to see code.
     
DiabloConQueso
Grizzled Veteran
Join Date: Jun 2008
Status: Offline
Reply With Quote
Aug 31, 2015, 10:30 AM
 
So much misinformation and FUD in these comments -- pardon my bluntness.

A malicious ad is a malicious ad, whether it's served over an unencrypted HTTP connection or an encrypted HTTPS connection. The method of connection has very little to do with whether an ad itself is malicious or not or what that ad is capable of doing.

This is not some kind of attack by Google to weaken iOS security. In fact, system-wide restriction of outside/3rd party content to HTTPS connections is something that doesn't even exist on anyone's iPhone right this very minute (unless you're running iOS 9 beta). This is something that's planned for iOS 9 -- an OS that isn't even released yet.

This is not some kind of "easy way out" for Google. Some of the services that serve 3rd party ads don't have HTTPS support yet, so this is a way for apps that serve ads from those providers to keep serving those ads until the service adds HTTPS support.

We are currently in the midst of an internet-wide transition from unencrypted content to encrypted content. In bygone days, everything was served over HTTP save for the stuff that was deemed sensitive (like logins to websites, financial institutions, etc.) which was served over HTTPS, and now we're shifting to a paradigm where the entirety of the internet is served over HTTPS (or other secure connections) by default. This will take some time. To the end-user or casual surfer, it may seem as simple as, "Why don't the developers just change everything that says 'HTTP' to 'HTTPS'?" but in reality, it's not that simple a lot of times. There might be only a letter's difference between the initialisms "HTTP" and "HTTPS" but it's far more complex than that from a developer's standpoint.

This is not a "hack" in any way, shape, or form. This is something that Apple explicitly provides to developers for use in this and similar scenarios. It's not "Google's code," it's "Apple's code." Don't like it? Get mad at Apple, not Google.

Give the flippin' developers (yes, even the developers at the companies serving advertisements) some time to switch their entire system over to HTTPS, for crying out loud. This is simply a stop-gap solution so that they have time to do this without their service being disrupted (even though we all agree ads are not really a service that we like), not some kind of nefarious act on Google's part to undermine, sandbag, or otherwise weaken the security of iOS. Hell, it's not even a flaw or an exploit -- it's something that Apple specifically, explicitly, implicitly, and overtly allows developers to do for precisely this reason.
     
Mike Wuerthele
Managing Editor
Join Date: Jul 2012
Status: Offline
Reply With Quote
Aug 31, 2015, 10:35 AM
 
Okay - look. The point of this ENTIRE ARTICLE is Google paraphrased Apple's guidance (and code) for bypassing HTTPS support, without context, and in a self-serving context. Google did EXACTLY what the headline said, and wide implementation of the bypass (which won't work forever, I'm sure) will do EXACTLY what the headline says it will.

We pointed out Google's clarification from the get-go, even before the article went live. It's still not enough. What this should have been from the start is a point to the Apple guidance on this matter, and not a Google "clarification." I'm not upset about the Apple-provided code, I'm displeased at Google's "nuke the site from orbit because it will impact our bottom line" stance on it.

On HTTPS. It is FAR from simple to throw a HTTPS switch. We're still working on it here, because we've got 20 years of codebase to update.
     
just a poster
Forum Regular
Join Date: Jun 2004
Status: Offline
Reply With Quote
Aug 31, 2015, 12:48 PM
 
A switch from http to https is a switch from a transparent protocol to an encrypted protocol for data transfers. It is akin to switching from a non-password protected wireless access point to using WEP (although the WEP cypher is weaker than SSL). While I concur doing it properly may not be a "simple throw", it's also not as complicated as suggested. A server operator needs to create and purchase a verified keyfile (about $10-$250/year per domain) and, in the case of a web server, the web server software (apache, nginx, lighttpd) needs to be configured to use port 443 with the verified keyfile.

Other considerations include redirecting http traffic to https, a three to four-line code change in apache webserver configuration files, per domain. This exposes the url request via http during the transport (so it is not entirely secure), but at least the data sent back is encrypted.

There is some overhead with switching from http to https traffic: about 15% increase in network and server resource utilization, but this should not be a problem for most delivery infrastructures or websites.

Finally, in the case of a content management system for public-facing use, it may be necessary to update some code from http:// to https:// urls, but that is also not rocket science.

Because urls for ads do not pose a significant threat to privacy of users (eg, a fetch for googleads.com/ad/increase_penis_size_ad.jpg doesn't exactly reveal you are a client of chase bank or read http://macnn.com ), the right security-minded approach respectful of apple's iOS protections would use redirections from https-based ad server proxies to fetch data from google's existing http-based ad servers, an even higher cost for google.

As far as Google, I can certainly understand why a large infrastructure like theirs does not find interest in switching ad server traffic to https. After all, google doesn't care much for the additional resource use just to serve viagra, penis enlargement or boob augmentation ads. The more sinister motive, however, may be that google is no longer relying only on cookies to track users but is also using ip addresses and address requests. Once address requests are entirely encrypted, google cannot sniff traffic for cleartext urls to find out what online media is being consumed from a particular endpoint.
     
s219
Fresh-Faced Recruit
Join Date: Aug 2015
Status: Offline
Reply With Quote
Aug 31, 2015, 03:10 PM
 
This just in: All apps compiled and built before the iOS 9 SDK (i.e., the majority of the App Store) weaken iOS 9 app security!!! When will the madness end!!!

I'll go out on a limb and give another way to bypass the new ATS system on iOS 9 -- just compile with Xcode 6.4 or below, which is something many developers have to do for other reasons (one could be that we can't release code from a beta SDK, so if you want to have an app on sale in the App Store, you don't have a choice). Please don't accuse them of weakening iOS 9 app security.
     
   
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 11:11 PM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,