I am using cloudflare tunnels and I am having problems acquiring the certificate through ACME so while looking for a solution it occurred to me that perhaps it is not necessary to use HTTPS and I would like to know if I am right or not.
Imagine this scenario. Scenario 1
client → https → caddy (reverse proxy + Let’s Encrypt certificate) → https to another machine → https service.
Traffic is encrypted at all times and information is secure.
The certificate is from a recognized CA so there can be no man in the middle attack with a fake certificate.
Now imagine this. Scenario 2
client → https → cloudflare tunnel → http → caddy (reverse proxy) → https to another machine → https service.
That is, the tunnel ends at http in caddy instead https.
Question 1
It is true that http is not encrypted but the tunnel is, therefore, wouldn’t the information also be encrypted and protected at all times?
Finally, a third case occurs to me. Scenario 3
client → https → caddy (reverse proxy + self signed certificate (tls internal)) → https to another machine → https service.
Question 2
In this case, as in the first case, the information always travels via https so it is secure but I have a question as to whether there is a problem with using a self-signed certificate since the Cloudflare tunnel must be told not to do TLS validation (because it is self-signed) and I know that this is not good because there could be a mand in the middle attack but since the self-signed certificate is used within the tunnel, wouldn’t it be protected from this type of attack by the tunnel’s own encryption?
I hope I have explained myself well because I’ve used Google translate, if not, please ask me.
Cloudflare Tunnel is an HTTPS-based tunnel, which means it’s encrypted.
As long as you configure Cloudflare to trust your self-signed certificate, it should be OK.
When it comes to certificates, trust is one of the most important aspects. The key difference between a public CA-issued certificate and a self-signed one is that public CA certificates come with built-in trust, i.e. the root (and sometimes intermediate) certificates are already in the client’s system’s trust store, usually added through an out-of-band method.
But if you manually deploy your self-signed certificate to all the clients that need to trust it, including Cloudflare if it’s one of them, you’ve essentially achieved the same result.
So in short, as long as your clients trust the certificate and validate it properly (for example, making sure it’s not expired, the chain is valid, and the hostname matches), it doesn’t really matter whether it’s internal, self-signed, or issued by a public CA.
Regarding to question 2, the problem is that there is no way to say cloud flared trust in the self signed certificate to you have to disable TLS verification. (See attached pic)
If I’m not wrong, the tunnel is created and encrypted with a token at the time of creation. From that moment on, the information that goes inside the tunnel is encrypted, right?
That is why question 1 is the answer is that although caddy listens over http the information is encrypted and it is not necessary for caddy to listen over https to have encrypted communication.
Is what I just said true? If so, in scenario 2 (which caddy is listening on https - ser picture 2) Shouldn’t that certificate be internal to the tunnel and therefore no one could impersonate it?
You’re overcomplicating things. I’ll refer back to what said before about the trust. It’s up to you where you want to draw the line. As long as there’s at least one trusted encrypted connection, you should be OK. Doesn’t matter whether it’s the outer or inner layer. You can have multiple encrypted layers if you wish. But at least one of them should be trusted.
