Cloudflare Hates Firefox On Mac

What is the name of the domain?

Any

What is the error number?

Constant Captcha

What is the error message?

Verify You Are Human

What is the issue you’re encountering

Browser Will Not Get Past Captcha

What steps have you taken to resolve the issue?

Started a brand new profile, tried any site that uses cloudflare (including this cloudflare community site, had to use a different browser just to login)
On Mac Firefox v131, the captcha “Please verify you are a human” continually refreshes and does not allow the target site to resolve.
On the same version of Firefox with Win 10 64 (or any browser but Firefox on the Mac), the target site is resolved immediately
Default security settings on Windows and Mac. Also tried setting Enhanced Tracking Protection to Custom turning off all blockers, turning off Block Pop-Up Windows, and setting DNS over HTTPS to OFF, forcing the user agent string to be the same as Windows, no effect.

What is the current SSL/TLS setting?

Off

Can you follow this and share the QR/Rayid

Sure, thanks for replying. Hadn’t posted them as they change all the time.

Each time, ensuring no other instances of FF were running, and opening via profile manager.

New profile 1, had to click on ‘verify’ checkbox, proceeded to target site after clicking: 8cc5097c4f7de91e
New profile 2, did not have to click on ‘verify’ checkbox, proceeded to target site: 8cc50bd33bcb4752
Existing profile 3, endless cycle of seeing ‘verify’ checkbox: 8cc513abaea1e70a
Existing profile 4, endless cycle of seeing ‘verify’ checkbox: 8cc5152a29af477e

For all four profiles:
Browser Privacy: Standard
Block Dangerous Content: NOT Checked
HTTPS-Only: Not Enabled
DNS Over HTTPS: Default
No Add-Ons

For the two existing profiles that were blocked, cookies had been cleared in a previous session before re-opening the profile. Previously they had been successfully getting to the target site, but now they won’t.

Note that this is just today’s behavior. Overall, it’s inconsistent. Yesterday, brand new profiles were getting the endless ‘verify’ checkbox, but the day before, they were working OK. A few days before that new profiles were again getting blocked.

Here’s an example of the inconsistency. Opened up FF with each new profile, one at a time, with a single tab that already had the target site up after getting past challenges.cloudflare.com

After clicking the URL for this topic in my email client to open a new tab.

With new profile 1, got the endless block, closed and re-opened the browser twice:
8cc528d35e53465f
8cc535c82dee0bcf

The third try on profile 1 finally got through to this topic.

With profile 2, got the turnstile but then it went through to this topic OK.

So, the behavior isn’t just with the main target site, it’s this community site as well.

Once they made it through OK, closed and re-opened each profile, and both were still OK on both the target as well is this community site, no turnstile. Existing profiles 3 & 4 though still stubbornly refused to go to the target site, much less this community site.

It’s the inconsistency that’s troublesome. Tomorrow the working profiles may break yet again. Would sure like to know what’s causing the inconsistency.

Hey there! This report is rather confusing, as some of the rayIds you sent are being blocked by signals we only sent to automated browsers (the ones Turnstile aims to block).

Are you sure you have no add-ons in Firefox, or that you have no tool that could be trying to automate your browser as you run through those profiles (think: browser isloation)?

The last two rays that you send look successful, and I’m confused as to why you wouldn’t be passing challenges there.

1 Like

Fresh profiles, manually started, still being blocked.

But here’s the Paul Harvey. Even after getting blocked, other machines in the same LAN do not appear to suffer. Yet, the blocked machine, with either the same, or a different profile, cannot connect to the target site, and the only difference is that the blocked machine may have recently and quite legitimately employed automation on some site (perhaps not even the target one).

One such is with our VoIP provider (not your customer so no turnstile ever appears there), from whom we download some 60 CSV’s every day. No way that’s going to happen by hand.

This means simply that your fingerprinting is, to be charitable, a tad overzealous. Putting aside your flagging a machine that has at some time in the near past used automation, a fresh, new profile, pristine and empty, manually connecting to the target site as its very first action without any form of automation employed, should not be able to trigger the endless turnstile; or, even if the captcha checkbox does come up, clicking it should allow connection to the target site.

Yet once blocked, it’s endless turnstile, until eventually we just don’t try to open the target site for awhile and whatever data you’re persisting on your side (a combination of UA strings, LAN IP’s, timestamps, whatever) goes stale, allowing us to connect again. Haven’t nailed down the timeframe, but it seems to be a day or so.

Not that it’s any of your business, but the target site - our ERP - became your customer about a year ago after they were hacked. We routinely download reports to sync data entered by staff via the ERP’s website to our local database. Customer, vendor, product updates, etc. Thanks to your apparent “all automation is evil” approach, these tasks have grown more difficult.

(That approach is of course just as naive as saying all guns are evil. The tool cannot “decide” to be evil. It’s always the user.)

We understand that since they’re your customer, and we aren’t, us asking for you to knock it off won’t be effective.

Having them get you to force allow one machine is also not the answer; we haven’t done anything wrong. It’s our data, and we shouldn’t need special permission to access it.

Another wrong answer would be to waste manpower and invite the certainty of error by having staff manually click on all the myriad checkboxes and datepickers it would take to get the various reports (some multiple times as they have to be run per physical location).

We also understand your company provides a great service in helping keep businesses safe from nefarious actors. Alas, in your zeal to keep out the bad guys, you’re discriminating against legitimate use of automation.

If there was some way to get vetted and set a cookie or whatever prior to connecting, maybe set you up in our 2FA site and pass along a token, that’d be fine. But this whack-a-mole with the endless turnstile when we haven’t done anything wrong is growing tiresome.