Bug 279895 – Cannot visit Cloudflare-protected https://www.rkz.nl/ with Safari "Cross-Site Tracking" Protections Enabled

• Status: NEW
• Component: New Bugs

[Henk Poley]

I am unable to access the website of a burn-care hospital (https://www.rkz.nl/) that contains medical information and patient dossiers when using Safari (tested on versions 17 and 18) with both "Hide My IP" and "Cross-Site Tracking" protections enabled. The page remains stuck at loading.

The issue appears to be related to Cloudflare's interaction with Safari's privacy features, particularly when using iCloud Private Relay, and Cross-Site Tracking protection. Other browsers, even those that also use WebKit on iPhone, like Google Chrome, Firefox Focus, and Microsoft Edge, do not experience this problem.

**Steps to Reproduce:**

1. Open Safari (v17 or v18) on macOS or iOS.
2. Ensure that "Hide My IP" (iCloud Private Relay) is ENabled.
3. Navigate to https://www.rkz.nl/.
4. Observe that the page stalls indefinitely.

1. Open Safari (v17 or v18) on macOS or iOS.
2. Ensure that "Hide My IP" (iCloud Private Relay) is DISabled, and "Cross-Site Tracking" protections is ENabled.
3. Navigate to https://www.rkz.nl/.
4. Observe that the page stalls on a (Cloudflare) verification screen with the message "wacht terwijl de aanvraag wordt gecontroleerd..." (English: "wait while the request is being checked") indefinitely.

**Expected Behavior:**

The website should load properly, or at the very least, Safari should provide a prompt to temporarily disable the relevant privacy protections for this specific site.

**Observed Behavior:**

The page does not load, getting stuck on loading, or on a Cloudflare protection screen with no further action. Disabling IP hiding globally in Safari settings still leaves the page stuck on the Cloudflare verification screen, until "Cross-Site Tracking" protection is also disabled, after which the page finally loads.

**Additional Information:**

- The issue is specific to Safari, as other browsers (Google Chrome, Firefox, Microsoft Edge) do not encounter this problem, even when using WebKit-based browsers on iPhone.
- A related issue is that Qualys SSL Labs SSL Server Test cannot connect to the site either, returning the message: "Assessment failed: Unable to connect to the server" (potential Cloudflare blocks on iCloud Private Relay IP ranges). Link: https://www.ssllabs.com/ssltest/analyze.html?d=www.rkz.nl
- Running `nmap -p 443 -sV www.rkz.nl` also results in error messages, indicating the server is returning a "Bad Request" rather than a more informative response like "200 OK" or a redirect.
- Port 80 is closed (not uncommon), HTTP/2 works, but HTTP/3 appears to be stuck.
- I was able to debug this, but I'm asking for someone who would not be able to figure out these steps.

**Related Feedback:**

This issue has also been submitted via Apple Feedback (FB14467023) in July 2024.

**Suggested Action:**

Could you investigate why Safari's privacy protections are causing the website to fail to load, and whether Safari could provide a prompt to temporarily disable these protections for specific trusted sites, such as those protected by Cloudflare?

And maybe I can forward some Cloudflare WAF configuration hints to rkz.nl ? I can imagine that Cloudflare WAF can check traffic coming in through iCloud Private Relay (also hosted on Cloudflare) for unique Apple Account users or something.

[Alexey Proskuryakov]

rdar://132397107

[John Wilander]

Thanks for filing!

I'm not able to load anything from that website via curl:

$ curl -I https://www.rkz.nl/
curl: (28) Failed to connect to www.rkz.nl port 443 after 75004 ms: Couldn't connect to server

$ curl -I http://www.rkz.nl/
curl: (28) Failed to connect to www.rkz.nl port 80 after 75005 ms: Couldn't connect to server

(In reply to Henk Poley from comment #0)
> I am unable to access the website of a burn-care hospital
> (https://www.rkz.nl/) that contains medical information and patient dossiers
> when using Safari (tested on versions 17 and 18) with both "Hide My IP" and
> "Cross-Site Tracking" protections enabled. The page remains stuck at loading.
Just to make sure I understand:
1. You say "unable to access" here and "page stalls indefinitely" below. I assume that's the same issue, right?
2. You use of the word "both" here which would mean that having either of those two features disabled makes the page load? Your repro steps indicate that both are not required.

> The issue appears to be related to Cloudflare's interaction with Safari's
> privacy features, particularly when using iCloud Private Relay, and
> Cross-Site Tracking protection. Other browsers, even those that also use
> WebKit on iPhone, like Google Chrome, Firefox Focus, and Microsoft Edge, do
> not experience this problem.
> 
> **Steps to Reproduce:**
> 
> 1. Open Safari (v17 or v18) on macOS or iOS.
> 2. Ensure that "Hide My IP" (iCloud Private Relay) is ENabled.
> 3. Navigate to https://www.rkz.nl/.
> 4. Observe that the page stalls indefinitely.
Does this stall involve the Cloudflare screen?

> 1. Open Safari (v17 or v18) on macOS or iOS.
> 2. Ensure that "Hide My IP" (iCloud Private Relay) is DISabled, and
> "Cross-Site Tracking" protections is ENabled.
> 3. Navigate to https://www.rkz.nl/.
> 4. Observe that the page stalls on a (Cloudflare) verification screen with
> the message "wacht terwijl de aanvraag wordt gecontroleerd..." (English:
> "wait while the request is being checked") indefinitely.
> 
> **Expected Behavior:**
> 
> The website should load properly, or at the very least, Safari should
> provide a prompt to temporarily disable the relevant privacy protections for
> this specific site.
There is no setting to disable tracking prevention temporarily or for a specific website.

> **Observed Behavior:**
> 
> The page does not load, getting stuck on loading, or on a Cloudflare
> protection screen with no further action. Disabling IP hiding globally in
> Safari settings still leaves the page stuck on the Cloudflare verification
> screen, until "Cross-Site Tracking" protection is also disabled, after which
> the page finally loads.
> 
> **Additional Information:**
> 
> - The issue is specific to Safari, as other browsers (Google Chrome,
> Firefox, Microsoft Edge) do not encounter this problem, even when using
> WebKit-based browsers on iPhone.
> - A related issue is that Qualys SSL Labs SSL Server Test cannot connect to
> the site either, returning the message: "Assessment failed: Unable to
> connect to the server" (potential Cloudflare blocks on iCloud Private Relay
> IP ranges). Link: https://www.ssllabs.com/ssltest/analyze.html?d=www.rkz.nl
This is interesting. It's not clear to me how Qualys servers could be affected by "potential Cloudflare blocks on iCloud Private Relay IP ranges." Could you elaborate, please?

> - Running `nmap -p 443 -sV www.rkz.nl` also results in error messages,
> indicating the server is returning a "Bad Request" rather than a more
> informative response like "200 OK" or a redirect.

> - Port 80 is closed (not uncommon), HTTP/2 works, but HTTP/3 appears to be
> stuck.
> - I was able to debug this, but I'm asking for someone who would not be able
> to figure out these steps.
> 
> **Related Feedback:**
> 
> This issue has also been submitted via Apple Feedback (FB14467023) in July
> 2024.
> 
> **Suggested Action:**
> 
> Could you investigate why Safari's privacy protections are causing the
> website to fail to load, and whether Safari could provide a prompt to
> temporarily disable these protections for specific trusted sites, such as
> those protected by Cloudflare?
> 
> And maybe I can forward some Cloudflare WAF configuration hints to rkz.nl ?
> I can imagine that Cloudflare WAF can check traffic coming in through iCloud
> Private Relay (also hosted on Cloudflare) for unique Apple Account users or
> something.

[Henk Poley]

I suspect the hospital website has really strict firewall IP-range settings. Maybe they only allow domestic IP-ranges from The Netherlands in. And without any fallback webpage, just tarpitting. Hence you are seeing these 75s timeouts with curl, and I'm seeing no loading progress in Safari (same thing).

Yeah, the phrasing "unable to access" was written when I had not figured out I could visit the page with both iCloud Private Relay, and Cross-Site Tracking protection disabled.

As to the "both", disabling iCloud Private Relay seems to let me (from The Netherlands, at home) past their IP-range filtering that blocks iCloud Private Relay from communicating with them, and then disabling "Cross-Site Tracking" Protections maybe allows their Cloudflare WAF to set some important-to-them cookie. So both (or either) of these block you from accessing this hospital webpage.

The iCloud Private Relay blockade does not include any Cloudflare screen. I just see the previous page contents. E.g. the favourites page by default on Safari, from opening a new tab. Also there is a short blue line below the address bar, indicating some loading status. 

The Cross-Site Tracking protection issue does have a white page, which had hints of a Cloudflare WAF in the javascript. I no longer see this white page, even with Cross-Site Tracking protection enabled. So maybe they have some kind of inverse fail2ban for IPs who got past that test. Or some cookie-like storage across another domain, that cannot be set with Cross-Site Tracking protection enabled, but can be read. I can clear rkz.nl storage in Safari settings, and still visit the page now.

My bug report is kind of to have some quirks mode for this website, or a detection, that would offer a bypass. The current stuck-on-loading situation is not helpful. Though it is kind of by choice, how the hospital set their webpage up.

The Qualys SSL check is not hosted on a domestic Dutch 'house' IP-range, that is probably the reason they are blocked. Or they are blocked because they are on a hosting/server IP-range. I phrased that incorrectly. Sorry.

[Alexey Proskuryakov]

We'll use rdar://132397107 for the iCloud Private Relay issue, and this bug for the Cross-Site tracking protection issue. As you said, clearly there's an IP block.

Unfortunately, this second issue will be very hard to investigate, as we cannot load the website from here. It's also somewhat surprising, as why would Cloudflare protection behave differently on this website than elsewhere.

[Radar WebKit Bug Importer]

<rdar://problem/136541813>

[John Wilander]

(In reply to Henk Poley from comment #3)
> I suspect the hospital website has really strict firewall IP-range settings.
> Maybe they only allow domestic IP-ranges from The Netherlands in. And
> without any fallback webpage, just tarpitting. Hence you are seeing these
> 75s timeouts with curl, and I'm seeing no loading progress in Safari (same
> thing).
> 
> Yeah, the phrasing "unable to access" was written when I had not figured out
> I could visit the page with both iCloud Private Relay, and Cross-Site
> Tracking protection disabled.
> 
> As to the "both", disabling iCloud Private Relay seems to let me (from The
> Netherlands, at home) past their IP-range filtering that blocks iCloud
> Private Relay from communicating with them, and then disabling "Cross-Site
> Tracking" Protections maybe allows their Cloudflare WAF to set some
> important-to-them cookie. So both (or either) of these block you from
> accessing this hospital webpage.
> 
> The iCloud Private Relay blockade does not include any Cloudflare screen. I
> just see the previous page contents. E.g. the favourites page by default on
> Safari, from opening a new tab. Also there is a short blue line below the
> address bar, indicating some loading status. 
> 
> The Cross-Site Tracking protection issue does have a white page, which had
> hints of a Cloudflare WAF in the javascript. I no longer see this white
> page, even with Cross-Site Tracking protection enabled. So maybe they have
> some kind of inverse fail2ban for IPs who got past that test. Or some
> cookie-like storage across another domain, that cannot be set with
> Cross-Site Tracking protection enabled, but can be read. I can clear rkz.nl
> storage in Safari settings, and still visit the page now.

What does this mean? Are you able to load the page with cross-site tracking protections as long as you clear website data for rkz.nl first?

> My bug report is kind of to have some quirks mode for this website, or a
> detection, that would offer a bypass. The current stuck-on-loading situation
> is not helpful. Though it is kind of by choice, how the hospital set their
> webpage up.

It's extra hard to quirk pages/sites that don't even load initially. You'd have to imagine a prompt over a blank page which is very hard for the user to make a decision on. But it could be that a partitioned cookie quirk could work here.

> The Qualys SSL check is not hosted on a domestic Dutch 'house' IP-range,
> that is probably the reason they are blocked. Or they are blocked because
> they are on a hosting/server IP-range. I phrased that incorrectly. Sorry.