App Transport Security: changes in iOS/tvOS 17

Question

felix paul OP

Created Feb ’24

Replies 1

Boosts 0

Views 1.1k

Participants 2

Hello!

I'm working on VLC, that is a multimedia playback app available for any platform.

Among many things, we support discovery of servers on the local network using Bonjour, UPnP and NETBIOS with consecutive connections to those servers for media playback purposes. Additionally, we allow connections to unicast and multicast streams based on any domain name or IP (i.e. "rtsp://207.254.***.***"). Discovery of the mentioned services works very well with the Multicast entitlement along with NSLocalNetworkUsageDescription also on iOS 17.

According to documentation, iOS 17 prohibits any IP based connections by default, which breaks the entire functionality mentioned above that was previously enabled by including the NSAllowsArbitraryLoads key with the value TRUE in Info.plist. We amended the Info.plist with the following configuration and still fail to connect to hosts in that IP range.

<key>NSAllowsLocalNetworking</key>
<true/>
<key>NSExceptionDomains</key>
        <dict>
        <key>192.168.0.0/24</key>
                <dict>
                <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
                <true/>
                <key>NSIncludesSubdomains</key>
                <true/>
                <key>NSExceptionRequiresForwardSecrecy</key>
                <false/>
                <key>NSExceptionAllowsInsecureHTTPLoads</key>
                <true/>
                <key>NSExceptionAllowsLocalNetworking</key>
                <true/>
        </dict>
</dict>

Additionally, there does not seem to be a viable, publicly documented solution to connect to any server on the internet based on an IP address. Further, the process for IPv6 seems unclear.

Any help how to solve this so we can transition to the iOS/tvOS 17 SDK in time would be very much appreciated.

Boost

Answer 1

DTS Engineer OP

Apple

Feb ’24

iOS 17 prohibits any IP based connections by default

Yes and no. ATS only applies to URLSession and things layered on top of that. If you’re using lower-level APIs, like Network framework or BSD Sockets, ATS is not a concern. Specifically, you mentioned RTSP URLs, and those are not supported by URLSession so, if you’re having problems with those, that’s some other issue.

When it comes to HTTP requests issued by URLSession, you are correct that you need to add NSExceptionDomains for the IP addresses in play. You wrote:

We amended the Info.plist with the following configuration and still fail to connect to hosts in that IP range.

That’s not my experience. But…

Additionally, there does not seem to be a viable, publicly documented solution to connect to any server on the internet based on an IP address.

I am aware of a problem with the IP address support in NSExceptionDomains, namely that you can’t use a single entry to cover all IP addresses. There’s a bug on file about that somewhere… oh yeah, here it is… Check out this post. It seems that we fixed this bug recently. If you need to support older iOS 17 releases — which is something I generalyl recommend against — the posts earlier on that thread describe a workaround.

Further, the process for IPv6 seems unclear.

I’m not sure what you find unclear. The dictionary key is in standard CIDR notation, which has both IPv4 and IPv6 flavours. Have you actually tried this for IPV6 and encountered a problem? If not, please give it a whirl and lemme know what you see.

Anyway, coming back to the big picture, keep in mind that our TLS implementation does RFC 2818-style checking in addition to the checks done by ATS. So disabling ATS is not sufficient to handle these scenarios; you also have override this default server trust evaluation. For URLSession, that means handling the NSURLAuthenticationMethodServerTrust authentication challenge.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0