At WWDC 2020, Apple announced numerous measures in the area of ​​data communication related to iOS 14 and iPadOS 14. Here is an overview of the activities in various areas such as performance, security or data protection.

IPv6 is the latest Internet protocol that has been supported in the Apple ecosystem for years. This is not surprising, after all, Apple checks for submissions in the AppStore for IPv6 compatibility. However, IPv6 is not yet as widespread as Apple stated in a WWDC session: 54 percent of the TCP connections still take place in an IPv4-only environment. After all, 26 percent of the connections are active in a pure IPv6 environment. In the remaining 20 percent, only the addressed server does not support IPv6 and therefore only IPv4 connections.

So that iOS devices can use IPv6 in the app, it is sufficient for developers to access URLSession and Network.framework. In the server environment, the server itself has to deal with IPv6 independently. The connection during communication is also relevant here. The network operators have also been helping with the transition between IPv4 to IPv6 for years. This is how support is offered worldwide for:

• DNS64: synthesizes an IPv6 address for an IPv4-only server

• NAT64: takes over the translation of an IPv6 to an IPv4 address

The effort is worth it, as IPv6 offers lower latency and higher performance than IPv4, among other things. According to Apple, IPv6 is 1.4 times faster on average than IPv4.

Another step towards more performance is HTTP / 2. This technique uses multiplexing over a single connection to increase performance. This means that a client does not have to wait until one request is completed before the next one can be started. In other words, several requests can be processed in parallel. Since connections to the same server are recognized and already established connections are used more efficiently, this saves “time” for a constant connection / disconnection. With header compression, valuable bytes are saved in both the request and the response.

According to Apple, 70 percent of the connections in Safari already use HTTP / 2 connections. And here, too, a noticeable performance success was measured: The connections were on average 1.8 times more efficient than simple HTTP. For iOS devices, it is also sufficient for developers to access URLSession and Network.framework. In the server environment, the server itself must have activated HTTP / 2.

Apple does not stop at HTTP / 2. With HTTP / 3, which is based on the new Internet transport protocol QUIC (Quick UDP Internet Connections), the next generation of HTTP is in the starting blocks. This transport protocol has integrated the security of TLS 1.3 and offers the same support for multiplex streams as HTTP / 2. In contrast to conventional TCP and TLS connections, QUIC can shorten the loading times and buffering of a website, since less communication between client and server is required. HTTP / 3 also offers built-in mobility support so that network transitions do not cause ongoing operations to fail. Instead, they can continue seamlessly and without interruption with a new network connection.

Since HTTP / 3 is still in the specification at the IETF, users / developers can only activate compatibility using the developer settings. You can also try the same HTTP / 3 support in Safari through experimental settings.

Almost every app exchanges data with a kind of backend server. This data can be user-specific and sensitive, which means that a user may have to authenticate to the service with a user name and password. In order to increase security, (perceived) performance and (perceived) reliability, Apple has been making special demands since iOS 9 – both for app development and the associated backend systems. With this specification, also known as Application Transport Security (ATS), iOS / iPadOS prevents unencrypted HTTP connections and interrupted or weak HTTPS connections. The requirements also apply to other areas of data communication. Only state-of-the-art crypto-algorithms like AES-128 and the hash functions SHA-224, SHA-256, SHA-384 and SHA-512 can be used.

Apple also addresses the reliability that communication is secure with the right server. SSL certificates play a crucial role here. Your original job is to make sure that a client communicates with the right server. For this purpose, the server receives a certificate from a corresponding registration authority (CA). These certificates now cryptographically confirm the correctness of the server address. With ATS, Apple is also pushing the use of the Certificate Transparency process. This process, originally launched by Google, allows SSL certificates to be logged and checked at a neutral location, and thus to be monitored for correctness.

Another method to check the validity of an SSL certificate for data communication is the support for OSCP stacking when dealing with OCSP responders (Online Certificate Status Protocol): All SSL certificates already contain a URL to go through themselves to make the certification body verifiable. Such an URL can be used by an app to check whether the SSL certificate is valid or has been blocked in the meantime. With OCSP stacking, this does not have to be requested by the app per element, but the web server itself regularly receives an OCSP response from the OCSP responder about the SSL certificate it uses. The server packs this answer in a cryptographically signed, independent TLS handshake with the client.

Here is a summary of the security features requested by Apple for secure data communication.

However, there are still some very specific exceptions. These are not to be maintained as a general release in a PLIST file, but represent exceptions within the app code. Exceptions are offered for developers wh
en it comes to AVFoundation and WKWebView access.

Even if ATS does not yet require TLS 1.3 connections, this is technically supported by iOS. TLS 1.3 allows a faster handshake and increases the security in the connection. Here, too, Apple has offered standard use since iOS 13.4. According to Apple, 51 percent of all connections still use TLS 1.2, but the rest still use TLS 1.3. And even if we have already left the performance chapter: TLS 1.3 also has a positive effect on the Internet connection. Communication connections are established 1.3 times faster than with TLS 1.2. For iOS devices, it is also sufficient for developers to access URLSession and Network.framework. In the server environment, the server itself must have activated TLS 1.3. If you are already configuring your server on this matter, I would like to recommend a few more configurations:

• Activate HTTPS-Only -> Deactivate HTTP without TLS

• remove old protocol versions

• disable weak cipher suites

• activate Forward Secrecy

It is always worthwhile here to ensure that it is up to date. If you want to check whether a server meets the requirements of ATS, you can do this externally and internally with tools such as Examine ATS Diagnostic.

Multipath TCP enables an app to get a more stable connection across network interfaces. This means that an app does not have to re-establish a connection when the network connections change. For iOS devices, developers must activate the multipathServiceType property for the URLSessionConfiguration (for URLSession) and / or for NWParameters (for Network.framework). There are two modes for apps, but the prerequisite is that the apps use data sparingly.

• Handover mode: This mode allows apps to switch connections during data transfer via the network interface (WLAN-> mobile phone-> WLAN-> …). It is therefore suitable for long-lasting connections with high availability requirements. This mode is suitable for apps with all types of connections that cannot simply be set up again. This mode is not intended for downloading large files (in the background).

• Interactive mode: In this mode, the connections via the available network interfaces are opened in parallel and are therefore suitable for short-lived data connections with the need for lowest latency. If a connection breaks down, the connection established in parallel continues to exist. If WiFi and GSM / LTE connections are available, this mode always prioritizes the WiFi connection for data transmission. This mode is suitable for apps with high latency requirements. IOS has been using this mode within the system since version 7. This mode is also not suitable for (background) downloads of any kind.

However, developers also have access to the aggregation mode, which enables bundling of access bandwidths. This means, for example, that mobile communications with 1 Mbit / s bandwidth and DSL with 6 Mbit / s can be combined to create Internet access with 7 Mbit / s throughput. The mode is only available on developer devices and cannot be transferred to end customer devices. Apple has called on the app developers to identify use case scenarios for this mode. In the server environment, this is somewhat more complex to implement. Instructions and help can be found here.

In connection with the term Reliable Network Fallback (“WLAN support”), the WiFi assistant in iOS was previously mentioned, which was supposed to solve a similar-sounding problem. This function was originally implemented to support the connection of an app. If the user was in an area at the time the communication was established that did not ensure sufficient WLAN coverage, the connection was established via mobile radio. Unfortunately, this function was only active at this time. The connection (NSURlSession) with the fastest answer had won here (Flow Creation Time). However, the connection to the WiFi network also remained intact when communicating via mobile radio if the WiFi connection responded more efficiently for later requests. Support during data traffic was not included. If the connection to the WiFi network was lost completely, iOS first had to search for a new network using a WiFi scan.

With iOS 13, the WLAN support was renewed as follows: If a connection that has already been established causes problems, the system can re-establish it (Improved Flow Recovery). This functionality has been centrally available to the high-level APIs (URLSession, Network.framework) since iOS 13. However, developers are asked by Apple not to carry out an independent network quality check – for example with SCNetworkReachability. The system now “learns” WiFi availability automatically. If an app works with mass data, developers should notify the system using allowExpensiveNetworkAccess = false. This prevents the mass data (if the connection is lost) from being transmitted via mobile radio.

Apple also introduced “Low Data Mode” with iOS 13. This offers the user the opportunity to inform the system that it should handle the data to be transmitted very sparingly. The mode can be defined for WLAN as well as mobile radio. This function should help especially in situations where a weak WLAN signal or an (almost) throttled cell phone flat rate slows down the data traffic. If the user activates this feature, iOS reduces his own network access to the bare essentials and all background activities of third-party apps are deactivated. The whole thing only works if the developers have adapted their apps accordingly.

With iOS / iPadOS 14, data protection-related issues are also finding their way into data communication. For example, the user has to give extra access to the local network through apps that are looking for hardware (multicast, broadcast, …). “Fingerprinting” of the user is to be avoided or at least made more difficult.

Apple also addresses the issue of protecting privacy against a Domain Name System (DNS). The background: When your app accesses a website, the system starts a DNS query to convert the URL (www.apple.com) of a website into a number of addresses (23.15.137.53 or also 2600: 1406: 5800: 0592: 1A) to transform. DNS communication usually takes place via an unencrypted transport (UDP). This means that other devices in the network could see which addresses the user is interested in. DNS queries reveal a treasure trove of metadata, from which, for example, DNS resolver operators can read something about the behavior of a user. This includes, for example, which pages he visits on the Internet, which mail server he uses and from whom he currently obtains the key for the subsequent encrypted communication.

This point is also important for companies with their own VPN. As a rule, the domain name system is the culprit, even when it comes to data leaks in VPN connections: In order to be able to navigate through the Internet, your computer normally automatically uses the DNS servers of your Internet provider. If this also happens when using a VPN tunnel, criminals could tap exactly this data. That is why most VPN providers also redirect their customers’ traffic via DNS servers that are not connected to their Internet providers.

To remedy this problem, Apple offers app developers these two possible methods using system-wide encrypted DNS access

• DNS over TLS (DoT)

• DNS over HTTPS (DoH)

Both methods use TLS to encrypt DNS messages. DoH also uses HTTPS to improve performance in data communication.

There are two ways to activate an encrypted DNS connection. The first option is to configure a single DNS server as the default resolver for all applications on the system. This requires connecting an app with a network extension (NEDNSSettingsManager). The use of a mobile device management system can also help to configure system-wide use.

Using encrypted DNS for just one app to a dedicated server is another option for app developers. It
is possible for an app to use encrypted DNS on its own, even if the rest of the system is still using unencrypted DNS. But be careful: Even if you have Encrypted DNS enabled to make name resolution more private, every TLS handshake that you perform with a server contains a plain text display of the server name or SNI, which can be observed by a third party on the network.

Apple is currently working with the IETF to standardize methods for further encryption of the TLS handshake so that third parties cannot spy on this data traffic. In the future, this will be an important additional step to enable network communication between an app and the associated server to be secured, especially in combination with encrypted DNS. (mb / fm)