Some enterprise networks (and sometimes whole countries, but that’s a topic for another blog…) implement an outbound/client proxy through which all traffic exiting a network must flow. Usually an outbound proxy sits between an enterprise network and the internet, but they could be positioned between subnets, or even intercept every network connection the clients initiate, regardless of the destination.
In some cases, the proxy does not decrypt the traffic but it can still log information about the traffic’s source/destination and other characteristics that may be useful for spotting security problems before they occur or for forensics after the fact. Other proxies require that a trust certificate be installed on network clients so the proxy can decrypt server responses and then re-encrypt the content before passing it along to the client. When decrypting proxies are used, the proxy can scan the contents of network messages to look for security problems, like known malware patterns or to implement data loss protection. The proxy can log and/or block traffic when it detects a problem.
In “Transparent Proxy” setups, network routing makes sure traffic goes through the proxy without the clients even knowing about it. Explicit proxies require that clients have the proxy url and port (or the path to a PAC file) entered into the client’s network settings. If a client tries to bypass the proxy, the traffic will be blocked by a firewall unless the source/destination combination has been granted special permission to do an end-run around the proxy.
As the world goes increasingly mobile, newer technologies like ZTNA will replace more traditional approaches like VPN and outbound proxies.
Some client applications implement “certificate pinning”. This technique involves a setting on the client that says, “any time you connect to system X, you should expect this particular certificate to come back from the server.” If any other certificate is used the connection will fail. It’s not enough that the server certificate is trusted on the basis of the root trust chains that have been pre-installed on the client. This is an excellent protection against “man-in-the-middle” attackers so you may see it implemented on sensitive connections. If there’s any TLS interception in the communications chain, the connection breaks, and that means no decrypting proxy.
Apple implements pinning on much of their device management infrastructure so TLS on that traffic cannot be intercepted by a third party or by your own decrypting proxy systems unless the clients have been configured to accept an alternative certificate infrastructure used by your organization.
Client Connections to Jamf Pro running on Jamf Cloud
ALL administrator, API, and managed device connections to Jamf Pro running on Jamf Cloud are TCP to an endpoint on your Jamf Pro URL, for example, “https://my.jamfcloud.com:443”.
Apple’s MDM and Jamf’s client apps (the Jamf macOS agent, Self Service, the admin apps, Setup, Reset, etc.) all send their traffic to an endpoint on a single Jamf Pro base URL and port to accomplish their tasks. They may also send analytics traffic like any other web client, but you can turn that on or off/allow or block that as you like. It doesn’t make any functional difference.
One other requirement, though this has more to do with the requirements of the networking stacks built into operating systems than with anything an application would implement… if you have a proxy or outbound firewall that strictly limits network egress to only a small set of specific services, for example, from an unprivileged device enrollment network, you should also allow access for certificate revocations checks.
Communications with Apple Systems
In most device management setups, it’s not enough for a managed device to just have a connection to Jamf Cloud. A complete management framework requires that devices can talk to Apple systems too. There are two key Apple references your network admins will need to understand:
If your Apple devices aren’t getting Apple push notifications: https://support.apple.com/en-us/HT203609
Use Apple products on enterprise networks: