Should I Restrict iCloud Private Relay for Managed Devices?

Written by Pam Lefkowitz on November 9, 2021

Share This Article

Private data is private. Personal data is private. Apple takes great pains to ensure that their users’ data remains in control of the user and nobody else. To that end, with the release of iOS 15 and macOS Monterey, Apple has created a new feature called iCloud Private Relay. 

It allows iCloud users, while using Mail.app or Safari, to shield their own traffic from prying eyes. This is great for the user, but it could cause issues when active on your company’s internal network. While it’s not a VPN, it does do some similar things: 

  • It obscures your web browsing
  • It sends your data through a pair of relays, effectively hiding your IP or your exact location; and, 
  • It masks the contents of your browsing 

As a user, all you need to do is turn it on in your iCloud settings. It is built into iOS 15 and macOS Monterey and requires no advanced computer or programming skills to enable. And therein lies the problem: IT admins are often required (by compliance regulation or internal policy) to maintain a certain degree of visibility across the network. When end users can prevent that from happening, using native features built into their devices, compliance is at risk. 

Whether BYOD or corporate-owned (COD), the clash of B2C and B2B features can create headaches or, worse, fines and undue auditing. This article highlights how iCloud Private Relay works, why an admin may need to restrict it, and how.

How Does it Work?

When using Safari, Apple takes your traffic and splits up the information into two pieces: your IP address (where you are) and your DNS request (what you’re looking for). Private Relay encrypts the DNS request and sends it, along with your IP address, to an Apple proxy server. Apple, in the meantime, has handed over encryption keys to a third party (educated speculation is that this third party is either Cloudflare, Fastly, Akamai, or some combination of them), which runs a second proxy. Apple assigns an anonymous IP to the encrypted DNS request. 

This means that Apple knows your real IP but not your DNS request. And the proxy knows your DNS request but not your real IP. Safe-safe – no single party knows your full browsing story.

Why Restrict Private Relay?

While this feature may be great for direct consumers of Apple products, it might not be great for administrators who use those same products in a corporate setting. There are reasons (e.g. compliance, disclosure, company policy) why an organization may want to restrict access to the Private Relay feature. As an example, companies or educational institutions might be required by policy to audit all traffic or to implement parental controls. In other cases, admins may want a higher degree of visibility on the network due to the sensitive nature of their organization’s business, and ensure employees cannot pass data off the network they shouldn’t and go unnoticed.

You can’t audit or protect what you can’t see, even if what you see is that there’s a proxy on the network. 

How to Restrict Private Relay

As admins, you can use DNS and MDM restrictions to help limit Private Relay.

The most expeditious way to block Private Relay is to edit your DNS resolver. To avoid resolution timeouts – which can be frustrating for users – configure your DNS resolver to return a negative answer rather than just silently dropping packets. The Private Relay(s) to restrict are:

mask.icloud.com

mask-h2.icloud.com

If you don’t have an on-premises DNS resolver and your network equipment isn’t managing your DNS resolution, your next option is to restrict Private Relay via MDM. Configure a payload with the following keys: 

The screenshots below highlight how this payload can be configured and deployed using JumpCloud MDM:

Within the Policy Management tab of the JumpCloud Admin Console, create a new Policy and add the code below, replacing your unique UUID’s and Identifiers as necessary.
This is a snapshot of the code from the mobileconfig file. You may download this file (in the sidebar) for use with your JC MDM; be sure to customize any UUIDs in the file for your situation.
Once deployed, a new profile will appear on the end user’s computer to reflect the new policy. 

Bottom Line

New technologies need to be evaluated on release. As admins, you should, in a perfect world, evaluate these technologies throughout the beta process and again upon release, so that you are prepared to answer user questions and requests on Day 1. Existing technologies, such as  iCloud, should be reviewed periodically to be sure they haven’t broken (or broken something) along the way. 

It’s important to recognize that one size does not fit all and while some features are harmless, others can be detrimental. Every company needs to look at features (old and new) with their company policies in mind. Admins are responsible for informing the key stakeholders of the risk-reward of all features and are responsible for being ready for or making ready the solution to reduce the risk.

JumpCloud recently hosted a webinar with Mac experts Pam Lefkowitz, Tom Bridge, and Bradley Chambers discussing this and the many new features of macOS 12 Monterey, which was recently released as a free major OS update. You can view this on demand webinar to learn about macOS Monterey and some of the coolest new features for IT admins everywhere, including how to speed up return-to-service workflows with Monterey’s erase all content and settings feature, the ability to enroll machines that were purchased outside of standard methods into Apple Business Manager, security improvements for the file system, a discussion around Pluggable Authentication Modules (PAM) that’s controllable with TCC Profiles, and more.

Pam Lefkowitz

Continue Learning with our Newsletter