TLS network security
iOS, iPadOS, and macOS support Transport Layer Security (TLS v1.0, TLS v1.1, TLS v1.2, TLS v1.3) and Datagram Transport Layer Security (DTLS). The TLS protocol supports both AES-128 and AES-256, and prefers cipher suites with forward secrecy. Internet apps such as Safari, Calendar, and Mail automatically use this protocol to enable an encrypted communication channel between the device and network services. High-level APIs (such as CFNetwork) make it easy for developers to adopt TLS in their apps, while low-level APIs (Network.framework) provide fine-grained control. CFNetwork disallows SSLv3, and apps that use WebKit (such as Safari) are prohibited from making an SSLv3 connection.
In iOS 11 or later and macOS 10.13 or later, SHA-1 certificates are no longer allowed for TLS connections unless trusted by the user. Certificates with RSA keys shorter than 2048 bits are also disallowed. The RC4 symmetric cipher suite is deprecated in iOS 10 and macOS 10.12. By default, TLS clients or servers implemented with SecureTransport APIs don’t have RC4 cipher suites enabled, and are unable to connect when RC4 is the only cipher suite available. To be more secure, services or apps that require RC4 should be upgraded to use modern, secure cipher suites. In iOS 12.1, certificates issued after October 15, 2018, from a system-trusted root certificate must be logged in a trusted Certificate Transparency log to be allowed for TLS connections. In iOS 12.2, TLS 1.3 is enabled by default for Network.framework and NSURLSession APIs. TLS clients using the SecureTransport APIs can’t use TLS 1.3.
App Transport Security
App Transport Security provides default connection requirements so that apps adhere to best practices for secure connections when using NSURLConnection, CFURL, or NSURLSession APIs. By default, App Transport Security limits cipher selection to include only suites that provide forward secrecy, specifically ECDHE_ECDSA_AES and ECDHE_RSA_AES in GCM or CBC mode. Apps are able to disable the forward secrecy requirement per-domain, in which case RSA_AES is added to the set of available ciphers.
Servers must support TLS v1.2 and forward secrecy, and certificates must be valid and signed using SHA-256 or stronger with a minimum 2048-bit RSA key or 256-bit elliptic curve key.
Network connections that don’t meet these requirements will fail, unless the app overrides App Transport Security. Invalid certificates always result in a hard failure and no connection. App Transport Security is automatically applied to apps that are compiled for iOS 9 or later and macOS 10.11 or later.
Certificate Validity Checking
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 and macOS 10.13 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 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 is not available, the trust evaluation will fail.