23 Replies
Can we do a thread?
Sure. So you mention “disable inbound connection for worker 2” can you give more details about this? Can this stop tools like Charles proxy, Reqable, Burpsuite etc from spying on my worker’s requests over HTTPS?
Yes. Basically, if your Worker doesn't accept HTTP(S) connections, then there is no way for a proxy like that to be used
Not sure I see what you mean? Worker #2 validates an MTLS certificate, but does nothing else? I don't see how that protects you from someone making proxied requests to Worker #1
Yes, i thought if I create mTLS between 2 workers, a certificate is pushed from worker1(client) to workers2(server) and usually if the connection is clean it will validate, but if the connection is from a device using tools like Reqable (which I have installed on my iphone and I had to add its Certificate and enable full trust in ios settings) then this will not validate and the logic on worker1 will not continue
But what if you use Reqable against Worker #1?
From my understanding with mTLS for cloudflare workers, the client certificate will be installed on worker1, so when worker1 domain is accessed the certificate will be pushed through the request. In the traditional mTLS setup (no workers) the certificate had yo be installed on the devices (mobile app, IoT device, etc)
Yes, but that just validates that the connection from Worker-Worker is intact. It doesn't protect the connection from User-Worker
Ok so I should have some check between user and worker1, that’s what you’re saying
Yeah, though as you said, your options that would actually work/be practical are pretty slim
I was talking to someone to make a checking microservice in Go (as it is fast and performant), he proposed something like this:
[Client Request] → [Cloudflare Worker] → [Golang Service with SSL Pinning] → [Cloudflare Worker] → [Final Destination]
I will provide a TLS cert and TLS key that you can send to the Golang service so that I verify that the request is coming from the cloudflare worker and not any other proxy.
Will this work?
Client request will come from mobile devices mostly
I still don't understand, what does the second Worker do that the first Worker can't do?
The second worker in that scenario is the same worker1, as i said the main logic (the redirects) are set in worker1 and before the main logic there is this “checking” logic that will forward the worker request to the Go microservice to see if the certificate setup on the worker with mtls bindings is the same as the one set on the Go service, if they match, then the worker1 can continue the logic and do the redirects.
Here are the scenarios I see:
1. User is a valid, non-proxied client:
User's browser sends request to Worker #1. Worker #1 sends MinTLS request to Worker #2, which returns that it is valid. Worker #1 redirects user.
Works as expected
2. User uses a proxy against Worker #1:
User's browser sends request to the proxy. Proxy sends request request to Worker #1. Worker #1 sends MinTLS request to Worker #2, which returns that it is valid. Worker #1 sends redirect to proxy, which is forwarded to user.
This request should have been blocked, but isn't.
3. User uses a proxy against Worker #2:
User's browser sends a request to the proxy. Proxy sends a request to Worker #2. Since request is not MinTLS-encrypted, request is rejected.
This request is useless, since even if the request was MinTLS-protected, it would just have returned a status code, not a redirect
Yes,#2 is the issue. I thought mTLS was going to fix that
The only way MinTLS will do anything is if you install it on the client
Btw, by MinTLS you mean MutualTLS right?
Oh yeah, sorry
Mb
But yeah, you need to install it on the user's device for it to be useful in your setup
Yeah, in my case I can’t install on the user’s device, it would be impossible
I suppose with SSL Pinning is the same situation, right?
I'm not entirely sure you can SSL-pin in a browser
The same scenario at #2 would apply but since the proxy present it’s own Certificate (to be able to intercept HTTPS) it would forward the user request to the worker1. Now assuming I make a mTLS binding on this worker for a certificate that is also configured in the next step at the Go microservice (server) for ssl pinning, I don’t know if the proxy own Certif that is set in the device trusted certificated will overwrite the mTLS one. If it does, the the SSL Pinning on the Go microservice will block the proxy connection
I mean social networks like IG use SSL Pinning to block such tools. So I assume the proxy own SSL would overwrite IG app embedded Certificate but because the SSL Pinning at the IG servers, the connection get’s blocked
Now in this scenario if we replace IG app with a worker, it should have the same result and block the connection if such proxy tool is used.
Hey! So I’m doing some tests, but I’m not sure if the mTLS cert is added on the worker request through the mTLS binding as shown here: https://developers.cloudflare.com/workers/runtime-apis/bindings/mtls/
Is there a way to check this?
Cloudflare Docs
mTLS | Cloudflare Workers docs
Configure your Worker to present a client certificate to services that enforce an mTLS connection.