With the introduction of iOS 9 apple has tighten up security level of the iOS apps. Some of your already developed apps may face this issue as obvious all of us have almost used insecure HTTP connections for those apps.
Apple now requires secure HTTP connection (i.e. HTTPS) from iOS 9. No app can run with insecure HTTP connection (i.e. HTTP). Otherwise, it’ll throw an error for ATS. You may find it in your console log. Or if you’ve enabled error display to user (i.e. Alert -> [error localizedDescription]) then user may also prompt like this:
Console log :
App Transport Security has blocked a cleartext HTTP (http://) resource load since it is insecure. Temporary exceptions can be configured via your app’s Info.plist file.
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.” UserInfo={NSUnderlyingError=0x7f9681718f10 {Error Domain=kCFErrorDomainCFNetwork Code=-1022 “The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.” UserInfo={NSErrorFailingURLStringKey=http://api.website.net, NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection., NSErrorFailingURLKey=http://api.website.net}}, NSErrorFailingURLStringKey=http://api.website.net, NSErrorFailingURLKey=http://api.website.net, NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.}
However they have provided some exception for this policy as written in above warning.This guide may help you to try some of the options provided as an temporary configuration. you may look into it and configure it according to your requirement.
Here is the link for Apple’s Official Tech note for Application Transport Security (ATS) :
Official Application Transport Security (ATS) technote form Apple
Please note, If your app’s server is configured for HTTPS connection also, then only replace your HTTP:// with HTTPS:// to resolve the ATS error.
One of the geek around the world has posted some good points which you may try to resolve your error. You may find the post here.
Below are examples of different scenarios developers may encounter.
Example A: ATS for all
This is the easiest one. The only thing you need to do is use NSURLSession, NSURLConnection, or CFURL. If you’re targeting iOS 9 or OS X El Capitan or later, ATS’s best practices will apply to all of your NSURLSession, NSURLConnection, and CFURL traffic.
Example B: ATS for all, with some exceptions
If you expect all of your domains to work with ATS, except a few that you know will not work, you can specify exceptions for where ATS should not be use, while leaving all other traffic opted in. For this scenario, you’ll want to use anNSExceptionDomains to specify the domains for which you wish to override ATS’s default settings. To opt-out an entire domain or sub-domain, create a dictionary for the URL you want to opt-out of ATS, then setNSExceptionAllowsInsecureHTTPLoadsto true. You can also specify more specific rules you wish to override withNSExceptionRequiresForwardSecrecy and NSExceptionMinimumTLSVersion if you don’t want to completely disable ATS on those domains.
Example C: ATS disabled, with some exceptions
Conversely, you may only want ATS to work on domains you specifically know can support it. For example, if you developer a Twitter client, there will be countless URLs you may want to load that may not be able to support ATS, though you would want things like login calls, and other requests to Twitter to use ATS. In this case you can disable ATS as your default, then specify URL which you do wish to use ATS.
In this case you should set NSAllowsArbitraryLoads to true, then define the URLs that you want to be secure in yourNSExceptionDomains dictionary. Each domain you wish to be secure should have its own dictionary, and theNSExceptionAllowsInsecureHTTPLoads for that dictionary should be set to false.
Example D: Downgraded ATS
In some cases you may want ATS on all, or some, or your URLs, but are not ready to fully support all of ATS’s best practices. Perhaps your servers support TLS1.2, but don’t yet support forward secrecy. Rather than completely disabling ATS on the affected domains, you can leave ATS enabled, but disable forward secrecy. In this scenario you would create anNSExceptionDomains dictionary, a dictionary entry for each domain you need to override settings for, then set theNSExceptionRequiresForwardSecrecy value to false. Similarly, if you wish to have forward secrecy enabled, but need the minimum TLS version to be lower, you can define your supported TLS version with the NSExceptionMinimumTLSVersionkey.
Example E: NSA-friendly Mode
If you want to opt-out of ATS entirely (which you really shouldn’t do unless you fully understand the implications), you can simply set NSAllowsArbitraryLoads to true in your Info.plist.
Third-party keys
You may have noticed a few keys that appear to be duplicates of others keys with the addition of “ThirdParty” in the name.NSThirdPartyExceptionAllowsInsecureHTTPLoads
NSThirdPartyExceptionMinimumTLSVersion
NSThirdPartyExceptionRequiresForwardSecrecy
Functionally these keys will have the same result as the keys that don’t have “ThirdParty” in them. The actual code being invoked behind the scenes will be identical regardless of whether you use the ThirdParty keys or not. You should probably use whichever key best fits your exceptions, but no need to overthink it.
Certificate Transparency
While most security features for ATS are enabled by default, certificate transparency is one you must opt-in to. If you have certificates which support certificate transparency, you can enable certificate transparency checks with theNSRequiresCertificateTransparency key. Again, if your certificates don’t yet support certificate transparency, by default this check will be disabled.
If you need help debugging issues that arise from having App Transport Security enabled, setting CFNETWORK_DIAGNOSTICSto 1 will log all NSURLSession errors including the URL that was called and the ATS error that resulted. Be sure to file radars for any issues you encounter so that ATS can be improved and flexibility expanded.
All of the above information was provided in Apple’s Networking with NSURLSession session at WWDC 2015. Finally, Apple emphasized in the talk to report any issues that you run into and keep any eye out for any changes that may be coming in future betas.
iOSCuriosity 