Updated to make it clear that using port 80 does not mean that Apple's software is insecure. Thanks to Jeffrey Paul for pointing out that this could be misconstrued.

At WWDC this week, Apple announced the App Transport Security feature for iOS and OS X. Apple is strongly encouraging developers to use HTTPS exclusively on new apps, and to make plans to migrate old apps to HTTPS in the near future. While encryption is not yet a requirement, it is the new default. Apps that want to continue to use plaintext HTTP on port 80 will need to explicitly disable the feature in their app manifests.

Apple has removed this whitelist completely, allowing third-party firewalls like Little Snitch to reliably monitor and filter any network traffic. Up until macOS 11.1 the whitelist inlcudes the following macOS processes. UPDATE 2: The traffic of some Apple processes isn’t shown in Little Snitch 5. UPDATE 3: Enabling Little Snitch 4.6 kext under Big Sur. UPDATE 4: Tweet by Apple developer Russ Bishop: 'Some system processes bypassing NetworkExtensions in macOS is a bug, in case you were wondering.' And some replies.

Com.apple.geod.xpc Assetcachelocatorservice.xpc Little Snitch Song nsurlsessiond UserEventAgent Also, I noticed descriptions on some locked LS rules which I would prefer to be denied, if I deny them, do they affect other OSX services? Apple has removed this whitelist completely, allowing third-party firewalls like Little Snitch to reliably monitor and filter any network traffic. Up until macOS 11.1 the whitelist inlcudes the following macOS processes. Since the announcement on Monday, I've been monitoring these requests using a firewall called Little Snitch. Funny enough, even Little Snitch didn't use HTTPS for its initial download or software updates until very only a few months ago. So far I've encountered 9 separate OS X services or first-party apps that are still relying on plaintext HTTP.

The ideas behind App Transport Security are great. It's essentially HTTP Strict Transport Security for apps, making it much harder for developers to inadvertantly disclose private user information. The feature that will benefit the privacy and security of millions of Apple customers. The writing is also on the wall that Apple intends to make this feature mandatory at some point, essentially deprecating plaintext HTTP altogether.

Apple, however, has yet to take their own advice. There are many OS X components and Apple apps that still do not use encryption exclusively, relying on HTTP over port 80. Here's an example from the brand new Photos app, communicating with AWS S3 over port 80:

Since the announcement on Monday, I've been monitoring these requests using a firewall called Little Snitch. Funny enough, even Little Snitch didn't use HTTPS for its initial download or software updates until very only a few months ago.

So far I've encountered 9 separate OS X services or first-party apps that are still relying on plaintext HTTP:

• nsurlsessiond via S3 / and Akamai

Disclaimer: It's worth noting that although some HTTP requests are happening over plain HTTP on port 80, this does not mean that Apple's apps are insecure. Most of the apps using port 80 still encrypt or or sign their content. Even if Apple's apps are not insecure, using plain HTTP does mean that they leak at least some extra metadata (HTTP headers) and that they are not following the rules they're pushing 3rd party developers to follow.

As an aside, it's fascinating just how many different CDNs Apple makes use of, and how heavily they rely on S3 for Photos and iMessage content.

When I first discovered that Photos communicates with AWS S3 without encryption, I submitted a security report to Apple. At the time, they did not consider it an issue and replied with the following:

Follow-up: 622218711

Hello Blake,

Thank you for contacting the Apple Product Security team. We take every report of a potential security issue seriously. This message is being sent to you by a security analyst who has reviewed your note.

Photos are encrypted at rest within iCloud, and are uploaded and downloaded to/from iCloud using an encrypted transport channel.

For more information on iCloud security, please see https://support.apple.com/en-us/HT202303

Regards,

Apple has tons of talented crypto engineers, so I don't doubt that Photos and iCloud store photos with at-rest encryption, or that they are encrypted in the HTTP payloads during transfer. Using plain HTTP does leak at least some additional metadata, though it may not be enough to compromise anybody's privacy in this specific case. But if Apple is asking all 3rd party developers to use HTTPS exclusively, they should be willing to do the same.

In summary, Apple's new App Transport Security feature is a great step towards enhancing the privacy and security of Apple customers around the globe. I look forward to the day when it is a mandatory feature. In the mean time, though, Apple should lead by example by avoiding plaintext HTTP in their own apps and services.

tinyapps.org / blog

Patrick Wardle highlighted a tweet by Maxwell ('Some Apple apps bypass some network extensions and VPN Apps. Maps for example can directly access the internet bypassing any NEFilterDataProvider or NEAppProxyProviders you have running'), sparking an extensive HN discussion on Apple's ham-fisted tactics (not unlike Google's recent behavior).

A search for 'NEFilterDataProvider' turned up David Dudok de Wit's post fingering the ContentFilterExclusionList key in /System/Library/Frameworks/NetworkExtension.framework/Versions/A/Resources/Info.plist as the culprit. The default list includes 56 Apple apps and daemons like App Store, MusicLibrary, softwareupdated, etc.: