I have read portions of this doc and searched through forum posts here and still have some questions about ATS regarding local (non-public/web) networks and apps for enterprise customers which only use those local private networks.
We have an app which is used by enterprise customers and only makes connections to local servers. Based on best practice recommendations, those servers will connect via HTTPS using TLS 1.2 and private CA generated root certificates which will be installed into the iOS devices using MDM. What I'm not clear on is the following:
- Does ATS only come into play on local connections if making an HTTP (non secure) connection or is it still activated/enforced even when making a TLS/HTTPS connection?
- To make a secure TLS/HTTPS connection to a private local server, ex: https://MyServerNameHere:9000/SomePathHere , will ATS require anything in the plist to be set, like NSAllowsLocalNetworking? I ask because the language of this section of the doc seems a little contradictory, stating that ATS does not provide protection for local connections and "ATS is unenforced for connection to local hosts", but then stating if you want to make a local connection you must enable NSAllowsLocalNetworking. Note this also gets to the heart of question #1 - does ATS come into play at all if the local connection is over HTTPS?
- If NSAllowsLocalNetworking is used and a TLS/HTTPS connection is made, does the certificate used, (again, in this case, said certificate is a private self-signed root certificate installed on the device), still need to follow ATS cipher suite certificate creation guidelines or not? This gets to the question of what it means to use NSAllowsLocalNetworking, is it disabling ATS for local connections or simply not rejecting them because they are local but still enforcing other guidelines like cipher suite rules?
- Assuming the answer to question #2 is yes you must use NSAllowsLocalNetworking; For apps that still support iOS9 is the only way to allow the same local connection in question #2 to use the NSAllowsLocalNetworking along with NSAllowsArbitraryLoads keys?
- Assuming the answer to question #4 is yes; is it a correct understanding that for iOS9 ATS would effectively be completely disabled and for iOS10 ATS would be still active for public domain server connections but disabled for local private connections?
OK. I’m going to tackle your specific questions first and then come back with some more queries:
1. Does ATS only come into play on local connections if making an HTTP (non secure) connection or is it still activated/enforced even when making a TLS/HTTPS connection?
ATS applies to both HTTP and HTTPS, regardless of whether the connections are local or not. In fact, one of the main goals of ATS is to force folks to use HTTPS or statically declare, in their
Info.plist
, that their app is insecure.
2. To make a secure TLS/HTTPS connection to a private local server, ex:
, will ATS require anything in the plist to be set, likehttps://MyServerNameHere:9000/SomePathHere
?NSAllowsLocalNetworking
That depends on whether the server meets ATS’s security requirements. There are two types of requirements here:
Standard TLS trust evaluation (per RCF 2818)
ATS security enhancements — These include no HTTP, the minimum TLS version, the cypher suite, the server key length, and so on.
When talking about local servers things normally fail the first requirement, and thus you need
NSAllowsLocalNetworking
regardless of the second requirement. In your case, however, your server’s certificate is installed on the client device by MDM, which muddies the waters a bit. I’ll get back to this below.
3. If
is used and a TLS/HTTPS connection is made, does the certificate used, (again, in this case, said certificate is a private self-signed root certificate installed on the device), still need to follow ATS cipher suite certificate creation guidelines or not?NSAllowsLocalNetworking
No.
NSAllowsLocalNetworking
disables all of ATS’s enhanced security requirements for local connections. You still have to worry about RFC 2818 trust evaluation and the system’s default TLS requirements. For example:
RFC 2818 trust evaluation on your server must succeed. Of course, with ATS disabled you can override this trust evaluation as discussed in Technote 2232 HTTPS Server Trust Evaluation.
Modern systems will not allow you to connect via SSLv3.
4. Assuming the answer to question #2 is yes you must use
; For apps that still support iOS 9 is the only way to allow the same local connection in question #2 to use theNSAllowsLocalNetworking
along withNSAllowsLocalNetworking
keys?NSAllowsArbitraryLoads
Yes.
5. Assuming the answer to question #4 is yes; is it a correct understanding that for iOS 9 ATS would effectively be completely disabled
Yes.
and for iOS 10 ATS would be still active for public domain server connections but disabled for local private connections?
Yes.
This is a recommended setup, yielding compatibility with iOS 9 and best practice security on iOS 10.
The one source of confusion in the above relates to your server’s certificate. You wrote:
private CA generated root certificates
which makes no sense to me. A root certificate is, by definition, not CA generated, that is, not issued by a CA. What do your certificates actually look like?
If I were in your shoes I’d get around this whole problem by:
Putting your servers in a domain of your choosing
Setting up a custom CA
Installing that CA’s root certificate on your client devices
Have that CA issue certificates for the servers in question
At that point you don’t need to do anything on the RFC 2818 front; your server will simply pass the RFC 2818 checks. You still need to handle ATS’s enhanced security checks, but most of those are relatively easy to deal with (and you should be doing them anyway to get best practice security).
If you want to pursue this path you should take a look at Technote 2326 Creating Certificates for TLS Testing and QA1948 HTTPS and Test Servers.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"