ATS and SSL pinning, Override Hostname - own CA

Hi,
We are developing a smart home application which is communicating with our own devices (like smart socket plug) via HTTPS.
Devices use our own CA, and iOS application set this certificate as a trusted by calling 'SecTrustSetAnchorCertificates' and override hostname according to: (https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/NetworkingTopics/Articles/OverridingSSLChainValidationCorrectly.html)
with ATS fully enabled (NSAllowsArbitraryLoads set to False).

And everything works just fine.
I read this topic: https://forums.developer.apple.com/message/169269

and according to it, we shouldn't be able to accomplish communication because:
"When ATS is enabled for a server you still get server trust authentication challenges (

NSURLAuthenticationMethodServerTrust
) and you can use that to increase security. However, you can’t use this to decrease security, that is, ATS provides a minimum level of security for a domain."

User eskimo said that this is a bug:

This is a bug in the interaction between ATS and the NSURLSession delegate callback (r. 27866669).

It was 2 years ago and it still works, so i'm wondering if our approach is correct and will be approved in App Store or not?
We can't use CA trusted by Apple because we will have like thousand of devices and it will be just to expensvice even more expensive than device itself.

Up vote post of TomaszTrela Down vote post of TomaszTrela
1.8k views
Posted by
TomaszTrela
Reply
Add a Comment

Accepted Reply

… despite using IP address. Did I misunderstand something?

Yes. There’s two levels of HTTPS server trust evaluation in the system:

  • All TLS connections implement default (RFC 2818) TLS server trust evaluation.

  • High-level HTTPS APIs, most notably 

    NSURLSession
    , also implement App Transport Security.

Disabling ATS, either explicitly or implicitly because you’ve connected to an IP address, has no impact on default TLS server trust evaluation. To override that you need to handle the 

NSURLAuthenticationMethodServerTrust
authentication challenge.

And it works great, but the question is, whether I will pass App Store Review?

The only folks who can give you definitive answers about what will or won’t be allowed on the store is App Review; I don’t work for App Review and can’t speak on their behalf. However, I’m not aware of any major roadblocks here. The ATS changes we made for local networking in iOS 10 — including this IP address change and 

NSAllowsLocalNetworking
— were specifically designed to help in situations like yours.

Because there is a lot of rumors …

That’s probably folks being confused by our WWDC 2016 announcement about App Review and ATS. You can find the latest news on that front in the App Transport Security and App Review section of my App Transport Security pinned post.

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

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Replies

And why it works even when I don't override host verification? Connection is estabished by IP Address and CA certificate added to trusted by "SecTrustSetAnchorCertificates" has CommonName set as a String. but the is no error like "common name mismatch"

Posted by
TomaszTrela
Up vote reply of TomaszTrela Down vote reply of TomaszTrela
Add a Comment

In iOS 10 we made a bunch of ATS tweaks and, as part of that, we disabled ATS checking for connections made to an IP address. That’s why your connections aren’t being blocked by ATS even though it’s fully enabled.

Note If you still support iOS 9 then I recommend that you test this there because it may not work!

With regards the second half of this, why default trust evaluation works, it’s hard to say without more details. For example, if the certificate that your CA issued to the accessory has a Subject Alternative Name extension that includes the IP address, you don’t need to override the host name. Specifically, I’d like to see:

  • The code you’re using to handle the server trust authentication challenge

  • The leaf certificate using by the accessory

  • The root certificate of the CA that issued that leaf

For the second two, please post either a PEM or a hexdump of the DER.

Alternatively, if you want to discuss this in private, open up a DTS tech support incident and we can pick things up in that context.

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

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Thaks for your answer!
I made a mistake, indeed default trust evaluation return 'recoverableTrustFailure' when hostnames don't match. So we can ignore my second post (May 16, 2018 6:52 AM)


In sum, we need to use IP address in communication which don't match hostname in certificate and our own CA which isn't trusted by Apple. We have implemented urlSession( didReceive challenge: completionHandler: ) accroding to: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/NetworkingTopics/Articles/OverridingSSLChainValidationCorrectly.html

(Listing 1 and Listing 2). And it works great, but the question is, whether I will pass App Store Review? Because there is a lot of rumors in the internet that this approach can be used to Test/Development environment only.
btw.
"In iOS 10 we made a bunch of ATS tweaks and, as part of that, we disabled ATS checking for connections made to an IP address."
If I don't implement urlSession( didReceive challenge: completionHandler: ) (URLSession.delegate = nil)
I still receive "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “192.168.1.***” which could put your confidential information at risk." despite using IP address. Did I misunderstand something?
Thanks!

Posted by
TomaszTrela
Up vote reply of TomaszTrela Down vote reply of TomaszTrela
Add a Comment

… despite using IP address. Did I misunderstand something?

Yes. There’s two levels of HTTPS server trust evaluation in the system:

  • All TLS connections implement default (RFC 2818) TLS server trust evaluation.

  • High-level HTTPS APIs, most notably 

    NSURLSession
    , also implement App Transport Security.

Disabling ATS, either explicitly or implicitly because you’ve connected to an IP address, has no impact on default TLS server trust evaluation. To override that you need to handle the 

NSURLAuthenticationMethodServerTrust
authentication challenge.

And it works great, but the question is, whether I will pass App Store Review?

The only folks who can give you definitive answers about what will or won’t be allowed on the store is App Review; I don’t work for App Review and can’t speak on their behalf. However, I’m not aware of any major roadblocks here. The ATS changes we made for local networking in iOS 10 — including this IP address change and 

NSAllowsLocalNetworking
— were specifically designed to help in situations like yours.

Because there is a lot of rumors …

That’s probably folks being confused by our WWDC 2016 announcement about App Review and ATS. You can find the latest news on that front in the App Transport Security and App Review section of my App Transport Security pinned post.

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

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Thanks eskimo, it's all i wanted to know!

Posted by
TomaszTrela
Up vote reply of TomaszTrela Down vote reply of TomaszTrela
Add a Comment