Disabling App Transport Security for http only?

Question

Created Aug ’15

Replies 2

Boosts 0

Participants 2

Our app (an email client) needs to be able to display arbitrary web content within emails and so has to turn on NSAllowsArbitraryLoads as otherwise nothing http-based will display.

But we also talk to our own server API via https and would like to be able to take advantage of any additional security that ATS provides for those requests.

I was hoping that I'd be able to use NSExceptionDomains alongside NSAllowsArbitraryLoads=YES to specify that our server[s] are complient with ATS, but have hit a problem.

As part of the login process, the server will send back the domain of another server to use for further https communication. The possible domains returned to us are not (and cannot be) known to the client app at build-time.

So given the above the best I can do to make any use of ATS's additional security is to add an exception domain for the inital https request's domain but nothing else.

It seems to me that there should have been an NSAllowsArbitraryHTTPLoads key which specifies the default handling of http requests while leaving https un-exposed.

Just wanted to verify what I want to do is not currently supported before filing a radar.

Boost

Answer 1

DTS Engineer OP

Apple

Aug ’15

Just wanted to verify what I want to do is not currently supported before filing a radar.

You should definitely file an enhancement request describing your use case. Please post your bug number, just for the record.

As part of the login process, the server will send back the domain of another server to use for further https communication. The possible domains returned to us are not (and cannot be) known to the client app at build-time.

And yet you’re sure that this other server complies with ATS’s other requirements. Interesting.

Given the current state of ATS, it seems like solving this on the server side might make more sense. For example, if you put all of these redirected-to servers ‘inside’ your domain, this problem would go away. The DNS side of doing that is easy, although the digital identity provisioning is likely to be less so.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 2

Wellington OP

Aug ’15

As part of the login process, the server will send back the domain of another server to use for further https communication. The possible domains returned to us are not (and cannot be) known to the client app at build-time.

And yet you’re sure that this other server complies with ATS’s other requirements. Interesting.

In the end its a moot point. Since I'd forgotten that any web content we display in the emails could also link to arbitrary https as well as http, the only thing I can really do is set NSAllowsArbitraryLoads=YES and add an exception for our own domain that sets NSExceptionAllowsInsecureHTTPLoads=NO.

0