Evaluating the censorship resistance of Apple's iCloud Private Relay #87
Comments
iCloud Private Relay is an onion routing proxy available in some versions of iOS, iPadOS, and macOS. Apple's advice to network operators who want to block access to Private Relay is to configure the DNS server to respond negatively for queries for the two names added in this commit, mask.icloud.com and mask-h2.icloud.com. https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay Heading "Allow for network traffic audits". Some caveats to adding these domain names to test-lists: * We really only care to test a DNS resolution for these names, not actually attempt to fetch a web page. A similar situation applied with use-application-dns.net (citizenlab#504). * The documented protocol of Private Relay is anyway UDP+QUIC (HTTP/3), not TCP+TLS. I am guessing, purely based on the name, that mask-h2.icloud.com may be an HTTP/2-based fallback for mask.icloud.com. * Apple clients reportedly send not only A queries for these names but also HTTPS (RR type 65) queries. net4people/bbs#87 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07#section-14.2 Being able to resolve mask.icloud.com and mask-h2.icloud.com does not guarantee that Private Relay will actually work. Apple self-censors the service in certain geographic regions. I don't know how Apple's own restrictions are enforced. Various other domain names may be involved in a Private Relay connection. This commit includes only the ones that are documented by Apple to use for blocking access. * mask.apple-dns.net: mask.icloud.com is a CNAME for this name. * mask-t.apple-dns.net: mask-h2.icloud.com is a CNAME for this name. * mask-api.icloud.com: Apple clients were seen to make queries for this name in experiments. * mask-api.fe.apple-dns.net: mask-api.icloud.com is a CNAME for this name.
Is this a typo for mask.icloud.com? An incorrect SNI may explain why you did not get any responses.
There are posts about Apple clients querying for the HTTPS RR type even in iOS 14. That type of query may just be a part of their HTTPS stack. https://support.opendns.com/hc/en-us/community/posts/360074584612-iOS-14-issuing-Type-65-RR-HTTPS-requests-which-OpenDNS-does-not-handle- Besides the CNAME aliases you mentioned (mask.icloud.com→mask.apple-dns.net and mask-api.icloud.com→mask-api.fe.apple-dns.net), there is also mask-h2.icloud.com→mask-t.apple-dns.net.
What was the ALPN of legitimate clients? You may be able to get a text dissection of Client Hellos with the following command (works for TLS, not sure about QUIC): A CNET story (archive) of 2021-09-19 contains a tweet (archive) by @letoams of 2021-06-08 that says Private Relay uses MASQUE:
The overall purpose of MASQUE is to enable various forms of proxying over HTTP, especially HTTP/3 (which uses QUIC). You may be able to understand more about what is going on by reading the MASQUE specifications. Perhaps someone from ietf-wg-masque can help shed light on how MASQUE is used in Private Relay. I have not followed MASQUE in the past year, and as I understand it the project's scope has evolved somewhat, but the early MASQUE drafts call for fallback to HTTP/2 when HTTP/3 is not available. My educated guess is that the mask-h2.icloud.com and mask-t.apple-dns.net endpoints are for HTTP/2 fallback. This would explain why mask-h2.icloud.com was not observed in your experiments—as a fallback, it would only be used if the QUIC endpoint were unavailable. More evidence is the fact that TCP port 443 is closed on mask.icloud.com but open on mask-h2.icloud.com:
|
Interesting, what's the point then? Making life hard for firewalls?
Doesn't a public directory of proxies give them away? MASQUE is supposed to be about probe resistance. |
Good catch! It is indeed a typo. However, we still couldn't get a response after using the correct SNI First we used the following script to compile curl that supports Script to compile curl that supports http3.#!/bin/bash
# This script is used to compile curl that supports HTTP3.
# It is a slightly modified version of:
# https://github.com/curl/curl/blob/master/docs/HTTP3.md
# The compiled curl binary will be at: ./curl/src/curl
set -x
set -e
cd "$(dirname "$0")" || exit
ROOT_DIR="$(pwd)"
INSTALL_DIR_OPENSSL=$(readlink -f "./installdir_openssl")
INSTALL_DIR_NGHTTP3=$(readlink -f "./installdir_nghttp3")
INSTALL_DIR_NGTCP2=$(readlink -f "./installdir_ngtcp2")
# For Debian-based:
sudo apt update && sudo apt install -y dh-autoreconf pkg-config perl
# For Fedora:
# sudo dnf install -y dh-autoreconf pkg-config perl-core
# Build OpenSSL
function build_openssl() {
cd "$ROOT_DIR"
git clone --depth 1 -b OpenSSL_1_1_1k+quic https://github.com/quictls/openssl
cd openssl
./config enable-tls1_3 --prefix="$INSTALL_DIR_OPENSSL"
make
make install_sw
cd "$ROOT_DIR"
}
# Build nghttp3
function build_nghttp3() {
cd "$ROOT_DIR"
git clone https://github.com/ngtcp2/nghttp3
cd nghttp3
# had to use -I ./m4
autoreconf -i -I ./m4
./configure --prefix="$INSTALL_DIR_NGHTTP3" --enable-lib-only
make
make install
cd "$ROOT_DIR"
}
# Build ngtcp2
function build_ngtcp2() {
cd "$ROOT_DIR"
git clone https://github.com/ngtcp2/ngtcp2
cd ngtcp2
autoreconf -i
./configure PKG_CONFIG_PATH="${INSTALL_DIR_OPENSSL}/lib/pkgconfig:${INSTALL_DIR_NGHTTP3}/lib/pkgconfig" LDFLAGS="-Wl,-rpath,${INSTALL_DIR_OPENSSL}/lib" --prefix="$INSTALL_DIR_NGTCP2" --enable-lib-only
make
make install
cd "$ROOT_DIR"
}
# Build curl
function build_curl() {
cd "$ROOT_DIR"
git clone https://github.com/curl/curl
cd curl
autoreconf -fi
LDFLAGS="-Wl,-rpath,${INSTALL_DIR_OPENSSL}/lib" ./configure --with-openssl="$INSTALL_DIR_OPENSSL" --with-nghttp3="$INSTALL_DIR_NGHTTP3" --with-ngtcp2="$INSTALL_DIR_NGTCP2"
make
cd "$ROOT_DIR"
}
build_openssl
build_nghttp3
build_ngtcp2
build_curl
# https://github.com/cloudflare/quiche/issues/319#issuecomment-782152550
sudo ldconfig -v
# show the compiled version
./curl/src/curl -VSecond, check the version of ./curl/src/curl -VThird, open Forth, the following command should successfully fetch a normal HTTP3 supported website: curl --http3 https://nghttp2.org:4433/Fifth, the ingress Private Relay will not respond anything, though the curl will try sending initial packets several times: curl --http3 https://mask.icloud.com
Thank you for sharing how to get a text dissection of ClinetHellos. It turned out a newer version of tshark can extract the ClientHellos in QUIC with exactly the same command above. It seems that the ALPN offered by both clients were very similar: one is The ALPN sent by curl was: ALPN Protocol
ALPN string length: 5
ALPN Next Protocol: h3-29The ALPN sent by the legitimate client was: ALPN Protocol
ALPN string length: 2
ALPN Next Protocol: h3I am not sure if this small difference was the reason why the ingress Private Relay did not respond to curl. I have not found a way to control the ALPN value, except crafting the packets manually. Below are the text dissections of the QUIC payload sent by I compared the extensions and the corresponding values of these two payload. It turns out that there are at least two major differences. I don't know which or any of these differences causes the different reactions from the ingress Private Relay. First, the Quic versions sent by Second, the key_shared values sent by
|
Great question. The doc explains that:
My understanding is that before a shared secret is negotiated by the TLS handshake, there is no way to "completely" encrypted the initial packets.
My imagination is that this seemingly easy to defeat encryption trick will actually raise the cost for censor to analyze and block QUIC traffic.
|
Since you're compiling curl from source, you can probably just change the value there: https://github.com/curl/curl/blob/e7416cfd2bd58d256b8524f31ef22a43aa23a970/lib/altsvc.c#L53-L59 It may not actually work beyond the handshake, but you're only trying to get a response anyway. You may be able to change the QUIC version with similar hacking. You can also try working in the other direction: start with an initial packet that is known to get a response, and change bytes in it until it stops working. But you'd have to undo and redo the initial packet encryption before and after making your changes. Of course, Apple could conceivably implement whatever requirements they want, such as an exact TLS fingerprint match, or something steganographically encoded into the connection ID. But I'm not seeing any obvious overt authentication in the ClientHello. The curl packet is padded to 1200 bytes, and the Apple packet is padded to 1350 bytes. It's a long shot, but that packet length is a possibility. It's worth checking if the PADDING frame actually contains all zeroes. |
It could be that they only use MASQUE as a convenient and reasonable proxy protocol, not really caring about anti-blocking and indistinguishability features. After all, they publish instructions for how to block Private Relay using DNS. Anyway, I think the focus of MASQUE has changed over last couple of years. In July 2019, phw summarized:
In July 2020, I asked for comment on a summary of MASQUE for the Turbo Tunnel paper, and David Schinazi replied:
|
Great tips! I tried to change the values of ALPN and QUIC version. It turns out that changing the QUIC version value to To quickly find where the value grep --color -ir "0xff00001d"ngtcp2/lib/includes/ngtcp2/ngtcp2.h:#define NGTCP2_PROTO_VER_DRAFT_MIN 0xff00001duReplace the value sed -i 's#NGTCP2_PROTO_VER_DRAFT_MIN 0xff00001du#NGTCP2_PROTO_VER_DRAFT_MIN 0x00000001u#g' ngtcp2/lib/includes/ngtcp2/ngtcp2.hNote that changing the following two blocks of code from
There is actually another place in the code the determines the ALPN value. We can change it by: sed -i 's#\\x5h3-29#\\x2h3#g' ngtcp2/lib/vquic/ngtcp2.cAlthough the server responded, the QUIC handshake failed. The decoded QUIC message is: CONNECTION_CLOSE (Transport) Error code: CRYPTO_ERROR (Missing Extension)
Frame Type: CONNECTION_CLOSE (Transport) (0x000000000000001c)
Error code: CRYPTO_ERROR (365)
TLS Alert Description: Missing Extension (109)
Frame Type: 0
Reason phrase Length: 0
Reason phrase:What could be the possible "missing extension"(s)? Below are the lists of the extensions included: $ tshark -V -2 -R ssl.handshake.ciphersuites -Tfields -e tls.handshake.extension.type -r legit_client.pcap
39578,0,10,16,5,13,18,51,45,43,57,27,20,35466
$ tshark -V -2 -R ssl.handshake.ciphersuites -Tfields -e tls.handshake.extension.type -r curl.pcap
0,11,10,35,16,22,23,13,43,45,51,65445Another dirty but more informative way to compare the lists of extensions: tshark -V -2 -R ssl.handshake.ciphersuites -r legit_client.pcap | grep " Type:"
tshark -V -2 -R ssl.handshake.ciphersuites -r curl.pcap | grep " Type:"The legitimate clients sent the following four TLS extensions that curl does not send (excluding the Extension: status_request (len=5)
Type: status_request (5)
Length: 5
Certificate Status Type: OCSP (1)
Responder ID list Length: 0
Request Extensions Length: 0
Extension: signed_certificate_timestamp (len=0)
Type: signed_certificate_timestamp (18)
Length: 0
Extension: compress_certificate (len=3)
Type: compress_certificate (27)
Length: 3
Algorithms Length: 2
Algorithm: zlib (1)
Extension: server_certificate_type (len=2)
Type: server_certificate_type (20)
Length: 2
Certificate Type List Length: 1
Certificate Type List (1)
Certificate Type: Raw Public Key (0x02)In addition, the legitimate clients sent extension |
After removing all files and recompiling from source, curl does not send any Turning off a bit was sufficient to let curl send sed -i 's#SSL_set_quic_use_legacy_codepoint(qs->ssl, 1)#SSL_set_quic_use_legacy_codepoint(qs->ssl, 0)#g' lib/vquic/ngtcp2.cHowever, neither other HTTP3 supported websites, nor the ingress Private Relays would respond. This is the extension sent by curl: Extension: quic_transport_parameters (len=55)
Type: quic_transport_parameters (57)
Length: 55
Parameter: initial_source_connection_id (len=20)
Parameter: initial_max_stream_data_bidi_local (len=4) 102400
Parameter: initial_max_stream_data_bidi_remote (len=4) 262144
Parameter: initial_max_stream_data_uni (len=4) 262144
Parameter: initial_max_data (len=4) 1048576
Parameter: initial_max_streams_bidi (len=1) 1
Parameter: initial_max_streams_uni (len=1) 3
Parameter: max_idle_timeout (len=1) 0 msThis is the extension sent by legitimate client: Extension: quic_transport_parameters (len=60)
Type: quic_transport_parameters (57)
Length: 60
Parameter: max_idle_timeout (len=4) 30000 ms
Parameter: max_udp_payload_size (len=2) 1472
Parameter: initial_max_data (len=4) 2097152
Parameter: initial_max_stream_data_bidi_local (len=4) 131072
Parameter: initial_max_stream_data_bidi_remote (len=4) 131072
Parameter: initial_max_stream_data_uni (len=4) 131072
Parameter: initial_max_streams_bidi (len=1) 8
Parameter: initial_max_streams_uni (len=1) 8
Parameter: active_connection_id_limit (len=2) 64
Parameter: initial_source_connection_id (len=8)
Parameter: max_datagram_frame_size (len=4) 65535
Agreed. There isn't much to do even if the handshake succeed. |
iCloud Private Relay is an onion routing proxy available in some versions of iOS, iPadOS, and macOS. Apple's advice to network operators who want to block access to Private Relay is to configure the DNS server to respond negatively for queries for the two names added in this commit, mask.icloud.com and mask-h2.icloud.com. https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay Heading "Allow for network traffic audits". Some caveats to adding these domain names to test-lists: * We really only care to test a DNS resolution for these names, not actually attempt to fetch a web page. A similar situation applied with use-application-dns.net (#504). * The documented protocol of Private Relay is anyway UDP+QUIC (HTTP/3), not TCP+TLS. I am guessing, purely based on the name, that mask-h2.icloud.com may be an HTTP/2-based fallback for mask.icloud.com. * Apple clients reportedly send not only A queries for these names but also HTTPS (RR type 65) queries. net4people/bbs#87 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07#section-14.2 Being able to resolve mask.icloud.com and mask-h2.icloud.com does not guarantee that Private Relay will actually work. Apple self-censors the service in certain geographic regions. I don't know how Apple's own restrictions are enforced. Various other domain names may be involved in a Private Relay connection. This commit includes only the ones that are documented by Apple to use for blocking access. * mask.apple-dns.net: mask.icloud.com is a CNAME for this name. * mask-t.apple-dns.net: mask-h2.icloud.com is a CNAME for this name. * mask-api.icloud.com: Apple clients were seen to make queries for this name in experiments. * mask-api.fe.apple-dns.net: mask-api.icloud.com is a CNAME for this name. Co-authored-by: David Fifield <david@bamsoftware.com> Co-authored-by: Arturo Filastò <arturo@openobservatory.org>
|
In December 2021, Apple published "iCloud Private Relay Overview" that clarifies some details. https://www.apple.com/privacy/docs/iCloud_Private_Relay_Overview_Dec2021.PDF (archive) Use of MASQUE:
Proxy authentication uses TLS:
Client device authentication is custom:
Use of Oblivious DoH to avoid DNS leaks:
Egress proxies try to maintain the client's approximate geographic region. The client tells the egress proxy the client's own geohash or country and time zone:
The client's partial IP address is also leaked to the ODoH resolver for EDNS client subnet:
|
|
Cloudflare published a blog post stating officially that they are (one of?) the providers of egress nodes for iCloud Private Relay. The ingress nodes are operated by Apple. https://blog.cloudflare.com/icloud-private-relay/ (archive).
I may be wrong, but it seems like the fact that Private Relay chooses an egress node located close to the user means that it won't be useful for many forms of circumvention. Any network restrictions that apply to you likely also apply to the egress node, which is located in the same country. |
|
On Wed, 2 Mar 2022, wkrp wrote:
In most parts of the world, Private Relay supports geolocation to the nearest city by default. If users prefer to be
located at more coarse location granularity, the option to locate based on country and timezone is available in Private
Relay settings.
I may be wrong, but it seems like the fact that Private Relay chooses an egress node located close to the user means that it won't
be useful for many forms of circumvention. Any network restrictions that apply to you likely also apply to the egress node, which is
located in the same country.
Yes, Private Relay is about breaking a one to one link of IP address to
a specific user/device. It is not about total anonymization or network
block avoidance or anti-censorship or anti-geolocation.
It's a feature, not a bug.
Paul
|
That's a good point. Incidentally, Private Relay can actually help bypass censorship in China. This is probably because Apple and those CDNs do not deploy ingress or egress servers in China, and connections from China thus have to go through some foreign ingress and egress servers. |
|
To make Private Relay work in China, one needs to:
It appears that the ingress servers do not restrict connections from Chinese IP address. Once the IP-checking server sees a non-Chinese IP address, users are reportedly able to use the Private Relay in the next ten minutes. Some users (archive) first connected to a proxy to enable Private Relay, then disabled the proxy to only use Private Relay for circumvention. A better way as suggested in this tutorial (archive) is configuring some routing rules to proxy traffic to Apple's IP-checking server. Going through all the steps above is not easy, but the setup may be useful in some cases. For example, the proxy that connects to Apple's IP-checking servers can have low bandwidth, high latency, and limited traffic volume. But as long as the IP-checking is passed, users can use the fast Private Relay for circumvention. |
Authors: Anonymous, David Fifield, Amir Houmansadr
Date: Friday, September 24, 2021
中文版：评估苹果的iCloud Private Relay的抗封锁能力
This report first appeared on Net4People. We also maintain an up-to-date copy of the report on GFW Report and ntc.party.
On September 20, 2021, Apple released iCloud Private Relay (archive) as a new service on iOS 15, iPadOS 15, and macOS Monterey.
Although Apple does not introduce Private Relay as a censorship circumvention tool, in this post, we attempt to understand the potential value of iCloud Private Relay for censorship circumvention. We first introduce how private relay works based on Apple's documents and our measurement. We then present our empirical observation on its censorship resilience, supported by our measurements in China. As of September 23, 2021, we haven't found any evidence of censorship against it in China. We also discuss its blocking resistance against common censorship methods, including DNS hijacking, SNI filtering, IP blocking, active probing, as well as self-censorship. Finally, we present some important but unanswered questions about the Private Relay.
We do not intend to make this a comprehensive report. Instead, we hope to start off discussions by presenting our thoughts, observations and measurement methods, encouraging more censorship measurement and circumvention enthusiasts to study it.
Main Findings
Introduction
Below is an introduction based on our measurement and our understanding of Apple's documents. In summary, the Private Relay has a two-hop structure, consisting of an ingress relay and an egress relay:
AandHTTPSformask.icloud.comormask-api.icloud.comto a DNS resolver, asking for the IP addresses of ingress relays.Capture traffic between an iPhone and relays
To capture and analyze the traffic from a mobile device, one intuitive way is to set up a VPN that works at the network layer, tunneling all the traffic at the transport layer and above to a (local) server, where
tcpdumporwiresharkcan be run. However, the iCloud Private Relay feature appears to be disabled when a VPN is used.As an alternative, we set up a WiFi hotspot from the desktop and let the iPhone connect to it. We then captured and analyzed the traffic from the laptop. Below is the script we used to setup the hotspot, which was borrowed from this tutorial.
When observing the DNS and initial QUIC traffic, we find the following Wireshark filter helpful:
Measure current censorship and evaluate potential censorship cost
In this section, we measure current censorship in China, and discuss the cost for a censor to detect and block Private Relay using commonly used censorship methods.
DNS hijacking
As introduced above, the client needs to get an IP address of the ingress relay before initiating QUIC connections to it. Since these DNS queries are (possibly intentionally) sent in plaintext, it is vulnerable to the DNS poisoning attack. Actually, Apple suggests DNS hijacking as "[t]he fastest and most reliable way" to block Private Relay:
In practice, we observed two ways for the client to get an IP address of the resolvers. The first way is:
AandHTTPSformask.icloud.com. The responses include a typeCNAMEanswermask.apple-dns.net, along with many typeAanswers.CNAMEone. The client thus has to send another two DNS queries of typeAandHTTPSformask.apple-dns.net.The second way is:
AandHTTPSformask-api.icloud.com. The responses include a typeCNAMEanswermask-api.fe.apple-dns.net, along with many typeAanswers.CNAMEone. The client thus has to send another two DNS queries of typeAandHTTPSformask-api.fe.apple-dns.net.Note that we did not observe any query of the documented
mask-h2.icloud.com. This observation aligns with the finding in this post.Measuring current DNS censorship in China
Although it is trivial for the GFW to poison the domains mentioned above, we have not been able to observe any DNS poisoning against these domains yet. Specifically, we tested by sending DNS queries from China to the outside, and also from outside to China. You can also test it yourself from the outside of China, exploiting the bi-directional characterisitc of the GFW. It is worth noting that
digdoes not support typeHTTPSqueries yet; be careful thatdigwill fall back to typeAqueries without a blocking warning for a query like this:dig @1.1.1.1 mask.icloud.com -t HTTPS +timeout=2.We thus used the follwing script with Scapy. Since
104.193.82.0is a Chinese IP address without a DNS service running, we would have received responses injected by the GFW if any of the queries were censored.SNI filtering
As explained in this answer, although clienthello messages are encryped in QUIC, the secrets are derived from a fixed salt and the Destination Connection ID field. The Initial packets can thus be easily decrypted. Actually, a newer version of the Wireshark can automate the decryption process for you.
It is therefore possible for censor to decrypt the Inital packets and check the SNI field against
mask.icloud.com.Measuring current (QUIC-)SNI censorship in China
We tested by capturing the initial packets from client and replaying them on a Chinese server. The server responded with QUIC handshake messages and we observed no disruption.
For example, we first saved the following hex stream as
quic.hex:We then send it to the ingress relay and received a response:
xxd -r -p quic.hex | nc -u mask.icloud.com 443 -vNote that the payload in the example will not get a reponse from an ingress relay anymore, approximately two days after it was first generated. One can probably still trigger reponses from the ingress relays with freshly generated Initial packets.
(Quic-)TLS fingerprint filtering
As explained above, the clienthello messages in the Initial packets can be easily decrypted. It is thus possible fro censor to conduct censorship based on the TLS fingerprint.
Our observation of the TLS fingerprint of the Private Relay aligns with the findings in this report:
Note that, apart from the 3 cipher suites, we saw a forth Grease ciphersuit (
0x2a2a).As a side note, we also observed two GREASE extensions
0xAAAA and 0X3A3A. They probably do not have anything to do with authentication (if they do, it's something very non-standard Apple is doing). The GREASE extensions turned out to be not uncommon; web browsers send them as well. As expalined in this doc, they were used to "reserve a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values". In other words, GREASE is meant to provide automated diversity to protocol fields, to prevent the protocol from "rusting shut" by assuming only certain values may appear.
We are also curious, by any chance, tlsfingerprint.io can tell us how unique these (or any) (QUIC) ClientHello fingerprints are? (@sergeyfrolov, @ewust)
Active probing to ingress relay
We find that the ingress relay will respond to a replay of the Initial packets within approximately two days since the packets were generated. We also tried to use quic-go and
curl --http3to send a typical Quic with SNI=mask.apple.com to the ingress relay; however, the ingress relay did not respond anything in this case. We suspected that has something to do with the ALPN extension included in the clienthello sent by the legitimate clients. It may also be possible that the client traffic contains some other authenticators.IP blocking to ingress relays
As introduced above, we could still receive responses from ingress relays by sending Initial packets from China. This indicates that, at least for the IP addresses we tested, China has not blocked it yet.
However, it could be fairly easy to block the ingress relay IP in serveral ways:
mask.icloud.com,mask-api.icloud.comandmask-h2.icloud.comresolve.IP-based discrimination against egress relays
Similar to Tor exit relays, which are available publicly, Apple provides an up-to-date lists of egress IP ranges (archive). This list could be easily used by websites to discriminate against Private Relay users, like what Tor users have been suffering from.
Questions not answered yet
How Apple implements the self censorship
Apart from all the possible external censorship methods discussed above, Apple has been conducting self-censorship to prevent users in heavily censored areas from using the Private Relays. It is thus important to understand how Apple implements the self censorship in order to circumvent it.
Specifically, Apple admitted that:
According to many news sources, these countries include China, Belarus, Colombia, Egypt, Kazakhstan, Saudi Arabia, South Africa, Turkmenistan, Uganda, the Philippines, and Russia.
It remains an unanswered questions on how and what self-censorship has been implemented by Apple. From our testing, it seems that the ingress server does not refuse service based on the geolocation of client IP addresses. However, it is still unclear to us how Apples determines the location of the user and thus refuse to be activated.
One report claimed (archive) that Apple learned users' geo-location from users' IP addresses connected to its certain servers; proxying traffic to these certain servers will activate the Private Relay service.
Another user report claimed (archive) that it is sufficient to activate Private Relay by changing the iCloud region to ones where Private Relay is not self-censored. However, another user in the post failed to activate the service with the same settings.
We note that it is not uncommon for a Chinese iOS circumventor to have a non-Chinese iCloud account. This is because, due to the heavy censorship against circumvention tools in Chinese app stores, it is almost essential to have a non-Chinese iCloud account to install other circumvention tools.
How does the user authentication work?
Apple claims that:
We are curious how (or if) Apple authenticates Priavet Relay users on the ingress and egress relays.
How does the underlying decryption work?
In the introduction section, we mentioned that the Private Relay "has a two-hop structure". However, we do not have know anything more about the underlying structure. For example, is an onion-routing structure used? Amir Houmansadr expressed concerns on the intransparency of the underlying protocol. Further investigation is required to better understand the underlying encryption/decryption mechanism.
Acknowledgement
We thank a person who prefers to stay anonymous for lending us an iPhone for testing.
Contacts
We encourage you to share your comments publicly or privately. Our private contact information can be found at the footer of GFW Report.
The text was updated successfully, but these errors were encountered: