iOS Network Communication

Overview

Almost every iOS app acts as a client to one or more remote services. As this network communication usually takes place over untrusted networks such as public Wi-Fi, classical network based-attacks become a potential issue.

Most modern mobile apps use variants of HTTP-based web services, as these protocols are well-documented and supported.

iOS App Transport Security

Starting with iOS 9, Apple introduced App Transport Security (ATS) which is a set of security checks enforced by the operating system for connections made using the URL Loading System (typically via URLSession) to always use HTTPS. Apps should follow Apple’s best practices to properly secure their connections.

Watch ATS Introductory Video from the Apple WWDC 2015.

ATS performs default server trust evaluation and requires a minimum set of security requirements.

Default Server Trust Evaluation:

When an app connects to a remote server, the server provides its identity using an X.509 digital certificate. The ATS default server trust evaluation includes validating that the certificate:

• Isn’t expired.
• Has a name that matches the server’s DNS name.
• Has a digital signature that is valid (hasn’t been tampered with) and can be traced back to a trusted Certificate Authority (CA) included in the operating system Trust Store, or be installed on the client by the user or a system administrator.

Minimum Security Requirements for Connections:

ATS will block connections that further fail to meet a set of minimum security requirements including:

• TLS version 1.2 or greater.
• Data encryption with AES-128 or AES-256.
• The certificate must be signed with an RSA key (2048 bits or greater), or an ECC key (256 bits or greater).
• The certificate’s fingerprint must use SHA-256 or greater.
• The link must support perfect forward secrecy (PFS) through Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

Certificate validity checking:

According to Apple, “evaluating the trusted status of a TLS certificate is performed in accordance with established industry standards, as set out in RFC 5280, and incorporates emerging standards such as RFC 6962 (Certificate Transparency). In iOS 11 or later, Apple devices are periodically updated with a current list of revoked and constrained certificates. The list is aggregated from certificate revocation lists (CRLs), which are published by each of the built-in root certificate authorities trusted by Apple, as well as by their subordinate CA issuers. The list may also include other constraints at Apple’s discretion. This information is consulted whenever a network API function is used to make a secure connection. If there are too many revoked certificates from a CA to list individually, a trust evaluation may instead require that an online certificate status response (OCSP) is needed, and if the response isn’t available, the trust evaluation will fail.”

When does ATS not apply?

• When using lower-level APIs: ATS only applies to the URL Loading System including URLSession and APIs layered on top of them. It does not apply to apps that use lower-level APIs (like BSD Sockets), including those that implement TLS on top of those lower-level APIs (see section “Using ATS in Apple Frameworks” from the Archived Apple Developer Documentation).

• When connecting to IP addresses, unqualified domain names or local hosts: ATS applies only to connections made to public host names (see section “Availability of ATS for Remote and Local Connections” from the Archived Apple Developer Documentation). 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)

• When including ATS Exceptions: If the app uses the ATS compatible APIs, it can still disable ATS for specific scenarios using ATS Exceptions.

Learn more:

• “ATS and iOS enterprise apps with private networks”
• “ATS and local IP addresses”
• “ATS impact on apps use 3rd party libraries”
• “ATS and SSL pinning / own CA”

ATS Exceptions

ATS restrictions can be disabled by configuring exceptions in the Info.plist file under the NSAppTransportSecurity key. These exceptions can be applied to:

• allow insecure connections (HTTP),
• lower the minimum TLS version,
• disable Perfect Forward Secrecy (PFS) or
• allow connections to local domains.

ATS exceptions can be applied globally or per domain basis. The application can globally disable ATS, but opt in for individual domains. The following listing from Apple Developer documentation shows the structure of the NSAppTransportSecurity dictionary.

NSAppTransportSecurity : Dictionary {
    NSAllowsArbitraryLoads : Boolean
    NSAllowsArbitraryLoadsForMedia : Boolean
    NSAllowsArbitraryLoadsInWebContent : Boolean
    NSAllowsLocalNetworking : Boolean
    NSExceptionDomains : Dictionary {
        <domain-name-string> : Dictionary {
            NSIncludesSubdomains : Boolean
            NSExceptionAllowsInsecureHTTPLoads : Boolean
            NSExceptionMinimumTLSVersion : String
            NSExceptionRequiresForwardSecrecy : Boolean   // Default value is YES
            NSRequiresCertificateTransparency : Boolean
        }
    }
}

Source: Apple Developer Documentation.

The following table summarizes the global ATS exceptions. For more information about these exceptions, please refer to table 2 in the official Apple developer documentation.

The following table summarizes the per-domain ATS exceptions. For more information about these exceptions, please refer to table 3 in the official Apple developer documentation.

Justifying Exceptions:

Starting from January 1 2017, Apple App Store review requires justification if one of the following ATS exceptions are defined.

• NSAllowsArbitraryLoads
• NSAllowsArbitraryLoadsForMedia
• NSAllowsArbitraryLoadsInWebContent
• NSExceptionAllowsInsecureHTTPLoads
• NSExceptionMinimumTLSVersion

This must be carefully revised to determine if it’s indeed part of the app intended purpose. Apple warns about exceptions reducing the security of the apps and advises to configure exceptions only when needed and prefer to server fixes when faced with an ATS failure.

Example:

In the following example, ATS is globally enabled (there’s no global NSAllowsArbitraryLoads defined) but an exception is explicitly set for the example.com domain (and its subdomains). Considering that the domain is owned by the application developers and there’s a proper justification this exception would be acceptable, since it maintains all the benefits of ATS for all other domains. However, it would be always preferable to fix the server as indicated above.

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>example.com</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <true/>
            <key>NSExceptionRequiresForwardSecrecy</key>
            <true/>
        </dict>
    </dict>
</dict>

For more information on ATS exceptions please consult section “Configure Exceptions Only When Needed; Prefer Server Fixes” from the article “Preventing Insecure Network Connections” in the Apple Developer Documentation and the blog post on ATS.

Server Trust Evaluation

ATS imposes extended security checks that supplement the default server trust evaluation prescribed by the Transport Layer Security (TLS) protocol. Loosening ATS restrictions reduces the security of the app. Apps should prefer alternative ways to improve server security before adding ATS exceptions.

The Apple Developer Documentation explains that an app can use URLSession to automatically handle server trust evaluation. However, apps are also able to customize that process, for example they can:

• bypass or customize certificate expiry.
• loosen/extend trust: accept server credentials that would otherwise be rejected by the system, e.g. to make secure connections to a development server using self-signed certificates embedded in the app.
• tighten trust: reject credentials that would otherwise be accepted by the system.
• etc.

References:

• Preventing Insecure Network Connections
• Performing Manual Server Trust Authentication
• Certificate, Key, and Trust Services

iOS Network APIs

Since iOS 12.0 the Network framework and the URLSession class provide methods to load network and URL requests asynchronously and synchronously. Older iOS versions can utilize the Sockets API.

Network Framework

The Network framework was introduced at The Apple Worldwide Developers Conference (WWDC) in 2018 and is a replacement to the Sockets API. This low-level networking framework provides classes to send and receive data with built in dynamic networking, security and performance support.

TLS 1.3 is enabled by default in the Network framework, if the argument using: .tls is used. It is the preferred option over the legacy Secure Transport framework.

URLSession

URLSession was built upon the Network framework and utilizes the same transport services. The class also uses TLS 1.3 by default, if the endpoint is HTTPS.

URLSession should be used for HTTP and HTTPS connections, instead of utilizing the Network framework directly. The URLSession class natively supports both URL schemes and is optimized for such connections. It requires less boilerplate code, reducing the possibility for errors and ensuring secure connections by default. The Network framework should only be used when there are low-level and/or advanced networking requirements.

The official Apple documentation includes examples of using the Network framework to implement netcat and URLSession to fetch website data into memory.