After reading the Apple Docs and numerous Apple Developer forum posts I am still unclear on if you need any ATS exemptions for making a secure (TLS/HTTPS) call to a local network machine (unqualified domain ex: https://MyServer:9000). Part of this doc states the following:
Availability of ATS for Remote and Local Connections App Transport
Security (ATS) applies only to connections made to public host names.
The system does not provide ATS protection to connections made to:
Internet protocol (IP) addresses
Unqualified host names
Local hosts employing the .local top-level domain (TLD)
To connect to an
unqualified host name or to a .local domain, you must set the value of
the NSAllowsLocalNetworking key to YES.
Note: Although ATS is unenforced for connection to local hosts, Apple
strongly recommends using Transport Layer Security (TLS) for any local
connection, along with the use of a self-signed certificate to
validate the local IP address
So do I need to add NSAllowsLocalNetworking even to make an already ATS-compliant (forward secrecy, TLS 1.2 etc) secure connection to an unqualified host name (private local server)? Or is NSAllowsLocalNetworking only required for unsecure local calls?
The NSAllowsLocalNetworking key is used to request an ATS exception for local network calls. If your local servers are ATS compliant, you should not need to add the exception. It's simple enough to verify. Simply run your app on an iOS 10 device without that exception in your Info.plist. If the connection is successful on the device, you know that there is no ATS violation that are causing issues. If it doesn't work, you are likely in violation of one of the ATS requirements (although it seems like you've verified some of the high level requirements for ATS compliance).
If you do have a failure, you can test the URL for ATS compliance with the following: use the nscurl --ats-diagnostics <url> command on your Mac. You can find out more about ATS in general, as well is how to use / interpret the results of the nscurl command above in this post.
As a note, the NSAllowsLocalNetworking exception was added in iOS 10, so including it in a build and running on an iOS 9 device will result in no change. If you end up needing it, and you need to support iOS 9, you'll want to add both NSAllowsLocalNetworking and NSAllowsArbitraryLoads in your Info.plist. On iOS 10, it will only disable ATS for local connections, but on iOS9 devices (which don't support the NSAllowsLocalNetworking entry), ATS will be disabled across the board.
Related
what does mean by All apps submitted to the App Store must support IPv6-only networking
is it something to do with HTTP addresses and HTTPS addresses
also should I have to change API URLs
And please don't tell me to read the difference between IPV4 AND IPV6 Because I already did that
There is no thing to do with http/https/apis , you have to enable IPV6 in your server
Hello I'm working with an hardware team to a really nice device that we can connect through with an iOS application. Currently we are using an ip address to perform calls on this device and it is working perfectly. Since we read about the new ATS specifics by Apple, we are trying to move the connection to a .local domain instead of using an IP address, so that we can configure domains exceptions in the App Transport Security Settings. We are experiencing a lot of problems trying to connect to the .local domains from the App... it seems that the DNS is never resolved. Are there any known bug related to .local domain? I seen some very old bugs... but nothing related to iOS 10/9.
Note: Currently to connect to the device we have to put the device in Access Point mode and from iOS settings we choose it as "wi-fi" router.
You're looking for Zero configuration networking, specifically DNS Service Discovery, an industry standard that Apple markets as Bonjour. That's what allows a device to list its services for DNS discovery through the .local top-level domain.
"Publication: An Example" in Apple's Bonjour guide is a good place to start for understanding what you'd need to do to implement this as a hardware vendor.
i am a newbie whom developing an app for iOS (and also android i have talked it also for google play) which implemented a socket connection and had to allow all host in order to work with our self-signed certificate installed on server by editing the plist file (NSAllowsArbitraryLoads true) or i need define NSExceptionDomains ?..
in 2016 and before apple still accept it ( i have deployed 1 before ), but i heard there is new regulation for 2017.
Will App Store accept self signed certificate connection for 2017 ? Thank you..
Only high level API's (e.g. NSURLSession, NSURLConnection, etc.) require app transport security.
Low level stuff like POSIX sockets do not use ATS.
We have existing iPhone/ipad application and currently we are consuming HTTP soap and Rest services.
As per the new rules and regulations of Apple, do We need to Convert our existing HTTP services to HTTPs?
Can We user Self signed certificate in the server to make the service SSL enables one?
Is there any problem for the apple if we are using the self signed certificate? or Do we need to purchase new SSL certificate ?
Also currently I am accessing the webservices through the ipv4 address.
Do I need to change it to ipv6?
when will apple start reviewing these conditions? I want to release the updated version of my app on next month. Do I need to follow these rules on the next build onwards?
In terms of ATS (App Transport Security), yes it is a new requirement for all iOS 9 devices running apps built with Xcode 7.
https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/
All connections using the NSURLConnection, CFURL, or NSURLSession APIs
use App Transport Security default behavior in apps built for iOS 9.0
or later, and OS X v10.11 or later. Connections that do not follow the
requirements will fail.
BUT your application can specifically opt-out if needed by adding exceptions to your Info.plist, at least until Apple changes that, assuming sometime in the future they will enforce 100% compliance, maybe the iOS 10 release(?), maybe earlier(?)...
Opt-out Example:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
Via: Google Ads Developer :http://googleadsdeveloper.blogspot.ch/2015/08/handling-app-transport-security-in-ios-9.html
Note: You can use "nscurl --ats-diagnostics" via OS-X 10.11 installation to test for ATS compliance on the URLS that your app will use. I would highly recommend doing that before app (re)submission to insure that you do not need to request exceptions via the Info.plist.
Self-signed certs will not work unless you add the signing CA details and trust it, or again disable ATS via an Info.plist exception. Save yourself the trouble and just purchase a compliant SSL cert.
Also currently I am accessing the webservices through the ipv4
address. Do I need to change it to ipv6?
No, your servers do not need to run IPv6, they should but that is up to you and your hosting provider as some mobile operators have moved to IPv6 only due to lack of IPv4 addresses, but, of course, they are providing NAT translation to IPv4.
But your app HAS to be IPv6 enabled/ready in order to work with those providers otherwise you will get an app rejection. I highly recommend reading the Apple doc on this.
Several situations can prevent an app from supporting IPv6 and these get rejected:
IP address literals embedded in protocols. Many communications protocols, such as Session Initiation Protocol (SIP), File Transfer Protocol (FTP), WebSockets, and Peer-to-Peer Protocol (P2PP), include IP address literals in protocol messages. See Use High-Level Networking Frameworks and Don’t Use IP Address Literals.
IP address literals embedded in configuration files. Configuration files often include IP address literals. See Don’t Use IP Address Literals.
Network preflighting. Many apps attempt to proactively check for an Internet connection or an active Wi-Fi connection by passing IP address literals to network reachability APIs.
Using low-level networking APIs. Some apps work directly with sockets and other raw network APIs such as gethostbyname, gethostbyname2, and inet_aton. These APIs are prone to misuse or they only support IPv4—for example, resolving hostnames for the AF_INET address family, rather than the AF_UNSPEC address family.
Using small address family storage containers. Some apps and networking libraries use address storage containers—such as uint32_t, in_addr, and sockaddr_in—that are 32 bits or smaller.
See for more details and how to workaround/resolve the above items:
https://developer.apple.com/library/prerelease/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW1
iOS9 requires the server to only support TLSv1.2 and support perfect forward security.
Also must required is for the app to support IPV6 including not using hard-coded IP addresses.
Certificate at the server must be signed by an authorized CA.
New security feature that blocks non-HTTPS traffic in your app. However, this is a new feature that is only enabled for apps building with X Code 7 and iOS 9 SDK today. It will not break existing apps.
For app in non production environment and debug you can disable ATS from plist.
Thanks.
I'm afraid the answer to this is No, but I'm hoping someone can provide a definitive answer as it is not documented in the current iOS SDK documentation.
We're seeing a case where NSURLConnection is able to connect to https://mysite.com via an HTTP proxy but, because of the way the local DNS is setup in this case, DNS lookups for mysite.com will fail. In this case, it appears that SCNetworkReachability is trying to perform a DNS lookup for mysite.com and failing. Meanwhile, NSURLConnection is able to connect.
We have incorporated the Apple Reachability sample code into our app and are calling SCNetworkReachabilityCreateWithName with mysite.com.
I can't provide a definitive answer, but I can provide more empirical evidence, and some justification, that the answer is NO. I have an app that uses SCNetworkReachabilityGetFlags to check whether a particular host is reachable (e.g.: www.mysite.com). Depending on that reachability check, it then uses [NSMutableData dataWithContentsOfURL:] to download the data.
The app has always worked fine, but recently I've been doing some coding at work where network access is via the corporate HTTP proxy. When running the app in the iOS Simulator (which uses the proxy settings configured on my Mac) the reachability check fails. At first I thought that perhaps the iOS Simulator wasn't using the Mac's proxy settings, but Mobile Safari in the simulator worked fine. So I removed the reachability check in my app and the call to [NSMutableData dataWithContentsOfURL:] worked fine. This would appear to indicate that SCNetworkReachability does not respect the proxy settings.
Having thought about it, this is probably the correct behaviour if you view SCNetworkReachability as running at the TCP/IP level, not at the HTTP level, in the same way that ping google.com on a Mac/PC behind a corporate firewall doesn't work either. The HTTP proxy (as the name implies) is for the HTTP protocol, not the whole TCP/IP stack.
Having read the answers to this question on Reachability I'm inclined to bin my reachability check altogether. Even though it's only been a problem in the simulator until now, it could be problematic in other situations (e.g. public WiFi hotspot that requires authentication).