An investigation into Apple’s new Relay network

At the WWDC 2021, Apple introduced iCloud Private Relay, a privacy-preserving proxy service. This service allows Apple devices to proxy unencrypted traffic and all Safari traffic to be securely proxied through the Private Relay. The system should protect its users in public networks (especially open Wi-Fi networks) and from their Internet Service Providers (ISPs). Apple states that a main feature of the system is that no single party — not even Apple — can see both the client and the server address.

My fellow researchers from the Technical University of Munich and I set out to analyse this goal, the architecture, and the behaviour of Private Relay from the network point of view to provide insight into the system and what to expect when service adoption gains traction.

Figure 1 — Architecture of iCloud Private Relay. 

The service uses a two-layer proxying structure to achieve this goal (see Figure 1). The connections with the different relays use the newly defined MASQUE proxying techniques. MASQUE operates on top of QUIC as a secure transport protocol. Apple runs the relays in the first, specifically, the ingress layer. The relays in the second, the egress layer, are operated by third-party entities. Currently, these are Akamai, Cloudflare, and Fastly. Apple claims to open the service in the future for other operators. 

In Figure 2 we visualized the difference in path visibility between a connection with and without using Private Relay. When Private Relay is not used, the source and destination tuple are observable on each point on the path. In contrast, with Private Relay, the entities on the path to the ingress can only see the client’s address, and on the egress to server path, only the server’s address is observable.

We identified three major affected stakeholders:

Figure 2 — The difference in path visibility between a connection with and without using Private Relay.

• ISPs: They experience a traffic shift towards the networks where ingress relays are located.
• Web/content servers: The servers will not be able to track users by their client IP address. Their networks will also receive more traffic from egress operators. Moreover, services making use of Content Delivery Networks (CDNs) that are part of iCloud Private Relay can benefit from reduced latency for users as the request is already in the correct network.
• Tools relying on passive network data: Intrusion Detection Systems (IDS) and firewalls need to consider this new type of traffic as the real communication partners are hidden from passive observers.

As an initial look at Private Relay, we focused on understanding the boundaries of the relay system, specifically, the relay nodes themselves. Apple provides a list of egress IP addresses and the associated location. These can be used to handle traffic from these addresses accordingly, especially for systems preventing malicious user activity.

We found entries for 20k IPv4 subnets of variable prefix length and 202k /64 IPv6 subnets.

	IPv4					IPv6
	Subnets	BGP prefixes	IP adresses	Subnets	BGP prefixes
Akamai-PR (AS36183)	9,890	301	57,589	142,826	1,172
Akamai-Est. (AS20940)	1,602	1	5,100	23,495	1
Cloudflare (AS13335)	18,218	112	18,218	26,988	2
Fastly (AS54113)	8,530	81	17,060	8,530	81

Table 1 — Comparison of egress subnets for the operating ASes.

While IPv4 Cloudflare entries are always for /32s, Akamai has fewer entries but more available addresses. Akamai uses two different Autonomous Systems (ASes): Akamai-PR is a stub AS connected to Akamai-Est. only. According to multiple BGP collectors, Akamai-PR has only announced prefixes since July 2021, and we could not find any indicators of other services making use of this AS.

In order to complete our external view, we also had to obtain ingress addresses. These are important to understand how the service can be reached and how distributed its deployment is. Apple’s white paper on Private relay mentions two domain names to resolve ingress addresses: mask.icloud.com for QUIC connections and mask-h2.icloud.com as a fallback domain for TLS over TCP connections.

The name servers of these domain names use the EDNS0 Client Subnet (ECS) extension to receive the client’s subnet and to provide prefix-scoped DNS responses. We use this extension to perform ECS walking, a technique by which we send all prefixes in the announced address space to the authoritative name server. This approach gives us a global view from a single vantage point.

In October, our ECS walking scan retrieved 1,725 IP addresses in total. 1,713 of these are uncovered by the QUIC-based domains. For the TCP fallback domain, we obtain 1,537 addresses. Followup QUIC scans also find the addresses unique to TCP. Therefore, we assume this small unique set is only present due to the later time when the TCP scan is performed.

	Default (QUIC)							Fallback (TCP)
	Apple			Akamai-PR			Apple			Akamai-PR
Jan	365	30.60%	823	69.40%	-	-	-	-
Feb	355	29.50%	845	70.50%	356	100.00%	-	-
Mar	347	26.90%	945	73.10%	334	93.00%	25	7.00%
Apr	349	22.00%	1,237	78.00%	336	24.00%	1,062	76.00%
…				…
Oct	475	27.70%	1,238	72.30%	462	30.10%	1,075	69.90%

Table 2 — The ASes of ingress relays and their proportional distribution.

The ingress addresses are in two ASes: Apple’s own AS and the Akamai-PRAS. This is the same AS also present in the egress address collection and appears only to be used for Private Relay. We used a laptop with an active Private Relay session to prove that the ingress and egress address can be within the same AS and that both addresses were reachable behind the same last hop router address. Therefore, we could show that a single entity can observe both ingress and egress traffic and use techniques similar to The Onion Router (TOR) attacks to combine ingress client addresses with server addresses. This issue breaks Apple’s promise to prevent a single party from seeing both addresses on the network level.

You can check out our paper to get an in-depth analysis, and we published our measurement data on GitHub.

Patrick Sattler is a Research Associate at the Technical University interested in large-scale Internet measurements with a focus on security, privacy, and DNS analysis.

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

from Hacker News https://ift.tt/Q4rghy9