In the current version of macOS, Monterey, on every system update on a system containing an M1 chip, such as all the new shiny/fast ARM (“Apple Silicon”) macs, the update process phones home to Apple to obtain a special boot signature, known in Apple jargon as a “ticket”.

It does this in a totally unencrypted fashion, over standard plaintext port 80 HTTP (the exact same protocol they banned for use by third party app developers in the App Store when transmitting private data like unique identifiers that serve as PII) to the host gs.apple.com. The HTTP request includes unchangable hardware unique identifiers (chip serial numbers known as ECIDs) that function as a supercookie, and it is visible to your local LAN, your ISP (or hotel or coffee shop), anyone monitoring the network backbones, and of course Apple.

This permits anyone listening to see the approximate location of the device, even if they are not proximate to it, because they can observe the client IP (which is equivalent to approximately city-level geolocation) and the serial number of the device.

Anyone watching the internet backbones and internet exchanges can see in which city each chip serial number (ECID) is located, and can see where they travel, as these updates are released several times per quarter. A new request is made on each system update, and users are prompted to enable automatic updates, enabling unattended tracking.

The requests are transmitted to a server called gs.apple.com which is an API run by Apple that provides a service called TSS which has been in use since the old iOS days to provide “tickets” (boot signatures) to allow Apple-designed ARM processors (like the Ax and Mx series) to boot.

Here’s what it looks like doing an update the last week of Jan 2022 on a MacBookPro18,2 (M1 Max 16” MacBook Pro, 2021):

Note that this is the request sent to the server, and that this is sent totally unencrypted.

POST /TSS/controller?action=2 HTTP/1.1
Host: gs.apple.com:80
Content-Type: text/xml; charset="utf-8"
Proxy-Connection: Keep-Alive
Pragma: no-cache
User-Agent: com.apple.MobileSoftwareUpdate.UpdateBrainService/1 CFNetwork/1327.0.4 Darwin/21.2.0
Content-Length: 15xxx
Connection: close

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>@ApImg4Ticket</key>
	<true/>
	<key>@BBTicket</key>
	<true/>
	<key>@Baobab,Ticket</key>
	<true/>
	<key>@HostPlatformInfo</key>
	<string>mac</string>
	<key>@SE,Ticket</key>
	<true/>
	<key>@VersionInfo</key>
	<string>libauthinstall-850.0.2</string>
	<key>ANE</key>
	<dict>

--- some lines redacted ---

	<key>ApBoardID</key>
	<integer>10</integer>
	<key>ApChipID</key>
	<integer>24577</integer>
	<key>ApECID</key>
	<integer>REDACTED UNIQUE APPLICATION PROCESSOR EC ID (a 16 digit integer)</integer>
	<key>ApNonce</key>
	<data>
	base64 data redacted
	</data>
	<key>ApProductionMode</key>
	<true/>
	<key>ApSecurityDomain</key>
	<integer>1</integer>
	<key>ApSecurityMode</key>
	<true/>

--- additional lines redacted ---

If you block this connection, or you block the (also unencrypted) insecure OCSP connections made by the mac (previously reported on here) during the update process, the update will fail and your computer will remain out of date and vulnerable to security vulnerabilities.

You can be insecure to everyone, or you can be insecure to Apple. There’s no third choice.

Apple does not seem to be interested in any way whatsoever in providing you security from malicious acts undertaken by Apple (either willfully, or acts which they are compelled to undertake). This is a huge risk, given that Apple is in the same jurisdiction that earnestly tried to assassinate Julian Assange for doing a journalism. You’d think they’d know better by now. (Or, maybe, given that the CCP has forced them to maintain backdoors for all iCloud users in China, they’ve just decided that you don’t need a weatherman to know which way the wind blows.)

This insecurity exists in the latest/current version of macOS, macOS Monterey 12.3.1. I assume without verification that it exists on iOS as well.

Apple, please stop transmitting tracking identifiers in plaintext across the network. You’ve already maintained the backdoors in your end-to-end encryption for the FBI; you’re well past the line where someone may reasonably suspect you of preserving tracking ability for the US military intelligence community as well. There’s no excuse for using plaintext any longer, you even banned its use by developers in the App Store under the whole App Transport Security initiative. Shape the fuck up.

You’ve even built a (premium, paid) service (called iCloud Private Relay) specifically for concealing client IPs from advertisers and email tracking services for precisely this reason. It’s not like you can claim ignorance of the privacy issue. For some reason you don’t use this same service for protecting some of your users’ most security sensitive (and potentially life safety critical) information (their location) during a critically important and frequent/routine operation (operating system updates) that nobody should be skipping.

Continued transmission of plaintext identifiers will be assumed as malicious intent. Fix it.