Worker works on workers.dev domain but not on own subdomain

[mwerner]

I have a worker that does 3 things, all of which are proxies:

1. Accessing /dataPlane will simply execute a fetch against a different URL (an analytics JS SDK)
2. Acessing /sourceConfig requires an auth header to proxy some stuff
3. POSTing to /v1/page or /v1/track , and a few others, passes on the posted body to the destiantion and returning that origin’s response

I deployed it to the workers subdomain and as you can see here: https://rsp-production.financialflo.workers.dev/dataPlane it shows the JS file I am proxying. The other 2 things also work just fine.

There is an additional route configured for this worker: rsp.obsessiveanalytics.com/*
and according to the worker docs I added DNS records for rsp, specifically:

A record → name: rsp → IPv4 address: 192.0.2.1 → Cloudflare proxy is turned on
AAAA record → name: rsp → IPv6 address: 100:: → Cloudflare proxy is turned on

However the problem is:
For scenario 1, https://rsp.obsessiveanalytics.com/dataPlane will just return an empty result but with 200 status code.
For scenario 2, https://rsp.obsessiveanalytics.com/sourceConfig (with auth header) will give a 525 error with this error message:

Error 525
Ray ID: 683cf0ad75301971 • 2021-08-24 13:31:18 UTC
SSL handshake failed
You
Browser
Working
Newark
Cloudflare
Working
api.rudderlabs.com
Host
Error
What happened?
Cloudflare is unable to establish an SSL connection to the origin server.

What can I do?
If you're a visitor of this website:
Please try again in a few minutes.

If you're the owner of this website:
It appears that the SSL configuration used is not compatible with Cloudflare. This could happen for a several reasons, including no shared cipher suites. Additional troubleshooting information here.

Cloudflare Ray ID: 683cf0ad75301971 • Your IP: 156.34.17.221 • Performance & security by Cloudflare

Other things I’ve tried:

• Using only an A record or an AAAA record, same problem
• Using a CNAME record for the rsp subdomain and pointing it to the worker domain (rsp-production.financialflo.workers.dev), same problem

[zeograd]

I think I have the same issue as you.

I have a blog proxy worker mapped to both https://io-redirect-blog.mjb-blog.workers.dev and a custom route MonJardinBio, le blog du jardinage biologique et de la permaculture – MonJardinBio.com*

If I use the debug console for the worker, a GET on any of the 2 URLs retrieve the correct content.
However, if I use curl from any machine, only the *.workers.dev route retrieves the correct content. The custom URL doesn’t trigger the worker.

It used to work for months up to ~ 24h ago.
(I have a second proxy worker on the same domain which stopped working at the exact same time)

I tried to unmap and remap the worker to the custom route, without luck.

Could it be linked to the recent deployment of the logs in dashboard for workers?

[AppleSlayer]

I get HTTP error 500 (internal server error)

Error 500: internal server error

Error 500 generally indicates an issue with your origin web server. Error establishing database connection is a common HTTP 500 error message generated by your origin web server. Contact your hosting provider to resolve.

Resolution

Provide details to your hosting provider to assist troubleshooting the issue.

[AppleSlayer]

Ah! Never mind, wrong link!

[AppleSlayer]

@mwerner You are getting a HTTP error 500 on http://rsp.obsessiveanalytics.com/* and 525 SSL handshake failed on https://rsp.obsessiveanalytics.com/sourceConfig

To fix Error 500
Provide details to your hosting provider to assist troubleshooting the issue.
To fix 525: SSL handshake failed
Contact your hosting provider to exclude the following common causes at your origin web server:

• No valid SSL certificate installed
• Port 443 (or other custom secure port) is not open
• No SNI support
• The cipher suites accepted by Cloudflare does not match the cipher suites supported by the origin web server

If 525 errors occur intermittently, review the origin web server error logs to determine the cause. Configure Apache to log mod_ssl errors. Also, nginx includes SSL errors in its standard error log, but may possibly require an increased log level.

Also, this is at the top

[mwerner]

@AppleSlayer

The worker works perfectly fine, just not via the own subdomain, all requests against the .workers.dev domain works, the JS in the worker simply performs a fetch and returns the response:

switch(pathname){
    case '/sourceConfig':
      return fetch('https://api.rudderlabs.com/sourceConfig', {headers: request.headers})
      break;
    case '/dataPlane':
      const init = {
        headers: {
          'Content-Type': 'application/javascript'
        }
      };
      const response = await fetch('https://cdn.rudderlabs.com/v1/rudder-analytics.min.js');
      const responseText = await response.text();
      return new Response(responseText, init);
      break;
//...
}

The fact that the exact same code works on the workers.dev subdomain but not on the own subdomain would tell me that it’s an issue with the cloudflare routing/proxying, not the worker code itself, no?

[mwerner]

Got some logging and the empty response is because apparently JS returns an empty response when you call .responseText() on a fetch. The status of the fetch is 525 SSL handshake failed. Again this works on the workers subdomain but not on my own.

I’m not the only one it seems that has issues fetching in workers and getting 525 errors, so far I have found no solutions in those posts though. One said to change the SSL mode (which is currently set to flexible on the site settings) to full or full (strict) via a page rule.

I did that:

But still get the 525 error.

[mwerner]

Found the solution. Apparently CloudFlare workers bypass page rules so the approach above I had was fine just had to be done in reverse.

I set the overall SSL settings to “full” and then made a page rule for my website to make it go down to “flexible”. Now it works as intended on my own subdomain. @AppleSlayer thanks for the help it was much appreciated.

[sandro]

@mwerner

I set the overall SSL settings to “full” and then made a page rule for my website to make it go down to “flexible”.

In both cases you have a security issue.

Why you should choose Full Strict, and only Full Strict

Unencrypted & unverified connections Imagine you open Paypal and suddenly get that warning [image] Would you continue? Probably not. For decades leaders in IT security have advocated that people upgrade their sites from unencrypted HTTP to secure HTTPS. And for a reason, everything you send via an HTTP connection is sent in plain text and can be intercepted at any point between you and the server. Equally, you’d probably not proceed if you got such a warning, right? [image] That’s when th…

[mwerner]

That’s all fine and good @sandro but going strict/full strict was simply not an option for the origin server that is hosting the website/webapp at my main domain. At least right now it isn’t. And I’m not handling any PII data or user information so having the CloudFlare <> my origin server connection secured is not paramount - right now.

Using full (strict or not) overall and flexible for my app/site is functional. My site isn’t down and the proxy setup is working too.

Also I just switched the overall settings to Full Strict and it’s working for the proxy so yay, I just haven’t gotten around to setting up the origin certificate SSL stuff on my website.

[sandro]

@mwerner

not an option for the origin server

Then you have an issue with the server and should fix that first. Right now you not only have an insecure site you also deceive your visitors.

[mwerner]

I’m sorry to disagree. There’s a reason your post is a post here and not an official CloudFlare documentation.

Firstly about the “insecure site” argument:
There is nothing wrong with using flexible. SSL termination is extremely common. Take a look at any AWS load balancer for instance. They handle the SSL termination and the traffic between the load balancer to the origin server(s) is over HTTP. This is not insecure. Unless your sever is compromised, no one is “able to intercept, record, and manipulate these connections without you, Cloudflare, or your visitors having the slightest idea” as you put it.

About the “deceiving your visitors argument”:
Please do tell me how I am deceiving anyone here? A visitor is getting an encrypted connection to cloudflare and for anything that is cacheable they are guaranteed to get CloudFlare’s cache of the requested resource. As for the things I proxy through the workers, that is what they are there for; to handle these kinds of requests that need extra processing, authentication, that you don’t want or need to expose on the front-end.

[sandro]

@mwerner

SSL termination is extremely common.

Yes, locally, not across public networks aka the Internet.

As for your deception, how else would you call it if someone pretends to have a secure site when in fact everything goes in an unencrypted fashion over the wire? You are sugarcoating your insecure setup.

[mwerner]

Well tell me how someone would (without having a shell on my origin server) be able to intercept CloudFlare’s proxy request and I’ll believe you that it is “insecure”.

[sandro]

If you answer the question how someone can intercept any request, you’ll also have the answer to your question. Are you saying HTTPS is overrated?

[mwerner]

Of course it isn’t but I’m saying that because the connection between cloudflare and my origin server, and the various protections it has, is over HTTP, calling the entire site “deceptive” and “insecure” is wrong.

[sandro]

@mwerner

is over HTTP

I am afraid it is insecure for that very reason.

I am really not sure why we even need to discuss this in 2021. A certificate these days is a matter of seconds and if you really cared about security you’d have installed this in the meantime instead of discussing why HTTP is insecure.

[mwerner]

CloudFlare’s reverse proxy is plenty secure for the site that you didn’t take the time to even look at. It’s a blog and has a contact form that is handled in JS so it doesn’t even submit to the “insecure” origin server. That is why I haven’t bothered putting the origin certificate there (yet) and why that site is secure.

[sandro]

@mwerner

it doesn’t even submit to the “insecure” origin server.

If you do not have an origin server the encryption mode won’t matter at all and you can set it to Full Strict anyhow. Why did you downgrade in the first place then?

[mwerner]

OK last reply here because it isn’t productive. This post is about an issue with cloudflare workers and 525 erorrs when using your own domain. Knowing that in order for that to work SSL needs to be “full” (strict or not) is the end of that.

And you didn’t read my post. The contact form doesn’t submit to the origin server. The blog/blog content comes from an origin server. It effectively serves only static content and receives no input/user data. That origin server does not have the origin certificate setup (yet) since I’m currently rebuilding it so it’s a waste of time to add SSL functionality to it right now.