On other threads I see that in the past there was no way to tell a URLSession to check for a particular hostname during TLS. Is this still true? It seems like an omission that it wouldn't take much to fix.

Our problem is basically that at one specific point in our connection process we're using URLSession with an IP address instead of an FQDN. Before that we use FQDNs, after that we use NWConnection, but at that specific point we need to connect by IP address. With the stricter security checking on the beta versions of the OSes we can no longer programmatically override the trust when we validate the host name internally. This means that we need to get the OS to do it for us. It looks like sec_protocol_options_set_tls_server_name will work for the NWConnections (although we still need to do more testing on that), but we have no solution for the case of a URLSession connecting by IP address. Hostname support for TLS: https://developer.apple.com/forums/thread/708005 - "NWConnection TLSParameters does not provide API to set SNI" https://developer.apple.com/forums/thread/680012 - "Set SNI using nw_endpoint_t or nw_parameters_t?" No support on URLSession https://developer.apple.com/forums/thread/82179 - "Setting SNI hostname for URLProtocol with URLSession" https://developer.apple.com/forums/thread/105057 - "NSURLSession's SNI Support"

Yes. NSLocale *enUSPOSIXLocale = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"]; [dateFormatter setLocale:enUSPOSIXLocale]; [dateFormatter setDateStyle:NSDateFormatterMediumStyle]; [dateFormatter setTimeStyle:NSDateFormatterLongStyle]; NSString* dateString = [dateFormatter stringFromDate:[NSDate date]]; And the string will have a non-ASCII space character. But only on the beta OSes.

Also with Swift, if I put this in a playground: import Cocoa var formatter = DateFormatter() var locale = Locale(identifier: "en_US_POSIX") formatter.locale = locale formatter.dateStyle = .medium formatter.timeStyle = .long var dateString = formatter.string(from: Date.now) var data = dateString.data(using: .utf8) print("\(dateString)") print("\([UInt8](data!))") We can see that on a beta OS it's got the non-ASCII space, and on Ventura it's got 0x20.

My understanding was that the NSExceptionDomains value had to be set in the info.plist file, and thus at build time as mentioned in https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity We don't know which domains need to be handled differently at that point. Each customer could have multiple domains configured about which we know nothing. We could turn ATS off, but that seems extreme (-ly unsafe). What we're looking to do is validate by hostname when we're connecting to an IP address for which we know the hostname. We can't just connect by hostname at certain stages, because it will break in the case of load-balanced hostnames which can resolve to multiple IPs.

I've been amending the feedback issues mentioned earlier in the thread, but I suppose this should be created as a new feedback. The behavior of write() still seems wrong as well. No matter what I'm trying to write, the file size & contents shouldn't be changing if there's a failure return. It looks like write is updating the file size and then trying to write data, so when there's a problem at that stage we still see a modified file. Should be checking for data to write first.

We don't know the IP address in advance either. The domain name(s) and the IP address(es) are all dynamic--customers configure all of those. I see no way in the documentation to say "don't apply ATS to connections made by any IP address" in the general case, just ways to configure either Exceptions for specific domains/IP addresses Bypass ATS altogether Are you thinking of NSAllowsLocalNetworking? The description of its behavior in the documentation is really unclear, and sounds like it contradicts the ATS changes and observed behavior in the betas when it speaks about .local domains, unqualified domains, and IP addresses ("In iOS 10 and macOS 10.12 and later, ATS allows all three of these connections by default, so you no longer need an exception for any of them").

I did know that. It's still a compile time setting, and we don't know what needs to be excepted at compile time. The only way to make that work would be to specify 0.0.0.0/0, which is pretty close to turning ATS off.

Thanks. I'll take a look. What we need to validate is whether adding all IP addresses to the exception domains means that no cert validation will be done. If so, then that's not quite what we want. Prior to iOS 17 we'd get a callback with a recoverable trust failure check to see that it was a hostname issue see if the host name that we know is in the certificate, and continue if so, cancel if not.

Well, 0.0.0.0/0 does not work. Specifying a specific subnet or IP address works. This is true with a lot of other Network Extension APIs. 0.0.0.0/0 isn't treated as an address, it's treated like a flag. You can't specify exclusions on the default subnet for example. If you define both 128.0.0.0/1 and 0.0.0.0/1, which effectively covers the same address space, it works as expected. Someone really dropped the ball on default network handling in the Network Extension code though--if it can be specified as a CIDR address it should be treated as a CIDR address, and it's not.

Thanks for the response. Hope it's fixed soon, because we're trying to test for day 0 compatibility with the new releases, and if the fix doesn't come out soon that won't work very well. We have enough tests that manually running through each of them every time is impractical.

Cool. Sounds like I don't need to file another issue about that, unless it would help with finding out when the problem is fixed. I hope they're looking at fixing this issue throughout the Network Extension code, not just for the ATS exclusions. Kevin kjbrock icloud com

If the defaultRoute is set in IPv4Settings.includedRoutes then exclusions don't work. In the documentation it says that defaultRoute is "A convenience method for creating the default IPv4 route", which of course is 0.0.0.0/0. Any addresses set in excludedRoutes continue to be tunneled. If we set 1/1 & 128/1 in IPv4Settings.includedRoutes things work, and excludedAddresses are excluded properly. This is similar enough to the behavior with ATS that I'd suspect similar underlying logic.

Can we just add the SystemExtension entitlement to the current App ID for the network extension, update the profile, and continue with the same ID, or will we need to define a new ID? This question doesn’t make sense. An App ID has capabilities which flow into the entitlement allowlist in your provisioning profile. When you create a profile from an App ID with the Network Extension capability enabled, you get different results depending on the type of provisioning profile: Most profiles end up with the standard NE values in the allow list. Developer ID profiles end up with values that have the -systemextension suffix. The App ID configuration has an entry which is "System Extension". I shouldn't have used the term "Entitlement" since on the web site it talks about "Capabilities"... In the case of an App Store distribution, which we'd like to keep doing, it wouldn't be a Developer ID profile, so this is really asking about that case and whether we can just add the System Extension capability to the ID & update the App Store distribution profile. I understand that we'd need a new profile for the out-of-app-store distribution. The file and keychain answers are pretty much what we expected--we expect that we're likely to need to do some XPC to talk between the two modules.

I've narrowed down the problem a little bit. It appears that the issue occurs when the tunnel shutdown is initiated from the extension rather than by the system, as in cases of timeouts or server disconnects. Starting the extension is pretty standard. We create the connection to the server, set up the network settings, and end up calling the completion handler passed in to startTunnelWithOptions. Stopping the extension is largely common code for system/user (stopTunnelWithReason:completionHandler) initiated shutdown or extension-initiated shutdown. For shutdowns initiated by stopTunnelWithReason:completionHandler our final call is to the completion handler passed in, while for shutdowns initiated in the extension we end up calling cancelTunnelWithError.