What is Private Relay?
At WWDC21, Apple announced a neat new feature called Private Relay. Twitter lit up and called it a VPN, but that’s not what it is at all. In fact, it behaves more like an application-specific TOR (The Onion Router).
We are thrilled that Apple is privacy focused, where we’ve lived for a number of years already. Naturally, we wanted to do a deep dive on it, so here we are:
How does it work?
Current limitations:
- In our testing, Private Relay needs some TLC when dual-stacked with IPv4 and IPv6. The IPv6 traffic would sometimes be relayed, and the IPv4 would not be. Considering this is developer beta at the time of writing, I’m sure this will be fixed shortly.
- US-based iCloud accounts currently offer this feature during beta. In our testing, Canada-based iCloud accounts do not offer this option yet.
Observed Layers
Private Relay is intended to operate in two layers.
- The first layer/relay is to Apple’s data centre. This does not appear to be an anycast network because from Toronto we get about a 100-200ms latency.
mask-api.icloud.comis reached first, where presumably only iOS devices can provision the current source IP. Next, iOS contactsmask.icloud.comfor the actual TCP port 443 connection to complete the first layer. - The second layer is from Apple to a network partner. At this time we’re only observing CloudFlare as a network partner. This is where CloudFlare WARP gets used for the secondary layer.
This two-layer connection has these interesting results:
- iOS15 Safari traffic runs over the Private Relay connection
- Apple knows you, the customer, but has no idea where your browser is connecting to
- CloudFlare knows where the connection is going, but has no idea who you are
- VPN exit traffic no longer vulnerable to just a visibility shift (a traditional VPN just shifts all your visibility from one provider - typically your ISP - to another, typically your VPN provider)
So on the surface, this seems pretty neat, and we’re thrilled about Apple’s push for privacy. However, there are some artifacts as a result of this behaviour:
- The privacy is limited to the public IP address only
- Other tracking mechanisms are not blocked at this time, including trackers such as Doubleclick and the Facebook pixel (this may be a future function of a network partner, and, for all we know, may offer additional features in the future)
- Your performance takes a hit (just run a speedtest that also measures your latency - both before and after, to measure the performance hit you’re experiencing), but the impact is much less severe than that of TOR, for example
The complete picture
Apple is always careful to introduce solid building blocks, so limiting it to iOS Safari for now is understandable. So it is important to understand that:
- Private Relay works only in Safari, not Chrome or other apps
- Private Relay obfuscates only your IP address from Safari traffic, not that of apps, etc
- If you enjoy any gateway security, content filter or even open source tools like Pihole, Private Relay unintentionally removes that protection
Actual Results
The power of modern tracking technology is so extensive that your IP address matters less than it used to. Modern tech that powers location-specific services discounts your IP address in most cases these days.
For individuals on iOS devices that had absolutely no other protection before, Private Relay is an immediate win. It obfuscates your IP address and slows you down a little.
However, for those that do have systems in place to protect their own devices from reaching out to trackers and ad networks and phishing links and malware, this Private Relay can be turned off completely on your iCloud+ account, or on a per-network basis. If you previously had proactive privacy/security managed through a gateway and make no changes, this will be the result:
- You win on privacy (although just the IP address)
- You lose on security (smishing, phishing, malware accessible)
- You lose on content filtering (adult content, for example, is not blocked)
How to prevent Private Relay from connecting, even if iOS has it enabled
These steps are for an adam:ONE® gateway.
In our testing, we tried two methods of blocking:
- With a blocklist that includes
mask-api.icloud.comandmask.icloud.combut this has some unintended consequences: The device just sits and waits for an answer, so the end-user gets nothing at all for about 30 seconds. Eventually the traffic of the existing destination site goes through, without the privacy relay and about a minute later the whole cycle starts over again. So it’s a bad end-user experience. - The second method we tried was with NXDOMAIN for DNS answers which worked much better:
ADAMnetworks’ DNS server at 34.74.71.110 will respond with NXDOMAIN on all queries. With that Forwarding rule created and enabled, iOS immediately pushes a notification to let you know that Private Relay isn’t working right now but will resume automatically. When it can, obviously.
When Private Relay is enabled, as soon as the device leaves a network that isn’t blocking Private Relay, it will reconnect.
For adam:ONE® and adam:GO™ managed clients, this mitigation step will be done automatically prior to iOS15 public release, without any action required on our clients’ part.
Additional Observations
- Even if Private Relay is disabled on iCloud+ account, after reboot it is auto-enabled again.
- If Private Relay is enabled, and an MDM-pushed VPN payload/profile is delivered, it overrides Private Relay. This makes sense as corporate VPNs are often used in conjunction with ACLs. Apple clearly recognizes this.
Updates
Since the original posting, Apple has released the following support article for network system’s administrators:
For environments that wish to disable Private Relay at the network layer, Apple recommends DNS-based filtering on these two domains:
mask.icloud.com
mask-h2.icloud.com
Accordingly, our clients can subscribe to a special rule here which will offer NXDOMAIN responses to queries to the above two domains.
After subscribing to the rule, make sure it is enabled on all of your policies like this:
