-
Notifications
You must be signed in to change notification settings - Fork 482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why recommending no SSL when behind Cloudflare? #1039
Comments
I don't think it's deceiving as the comment does say that Cloudflare terminates the SSL, which technically means encryption ends at Cloudflare. By default, Cloudflare uses Flexible mode, which means that even if you set I can create a PR to address this if that would be useful, does that sound good? |
So for this to work well with Cloudflare we need to set |
Also just to confirm, I and many others had hacked Kamal 1 to work with letsencrypt by running We also need to remove that dir for this to work well right? |
I started with Kamal 2, so no idea about that. But, I'd suggest, to try without removing first and then remove it and try again. |
It would be amazing if kamal-proxy had an easy built-in option to generate self-signed certificates as an option instead of letsencrypt which would allow full (but not strict) end-to-end with cloudflare |
Thanks @tuladhar , will try that. |
In regards to the original issue, my main issue was with the imperative default advice that might be harmful to the security of the origin. I'll post that line again:
As @tuladhar mentioned, the default setting in Cloudflare is Flexible which means "go over unencrypted HTTP". And then the default advice in Kamal is "turn SSL off when using (something like) Cloudflare" In their docs, Cloudflare clearly recommends using Full: Again, it's probably not Kamal's job to educate people about all this. I'm not sure what is a more idiomatic solution here for Kamal specifically, but I'd either remove that recommendation completely from the config template or spend another line explaining implication of Or flip the statement and always recommend turning SSL on unless the users are really sure that the server will have a reverse proxy in front of it inside their private network (either physically or via some VPN) and it will be terminating SSL. |
But why would you need a self-signed certificate when you can get a valid LE certificate for free for your domain? |
@kirillrogovoy PR opened: #1054 |
The LE cert only works in situations with a single app server, if you are load balancing a bunch of them it’s easier to do self signed. And I want SSL to the load balancer, even if it is self signed. |
Thanks @tuladhar! ❤️ |
Does anybody know of a proven guide that works for Rails 8 + Kamal 2 for setting up:
I watched the DHH videos, bought the Kamal handbook, but am still in SSL proxy CDN DNS hell. For Kamal to succeed I feel like it has to provide a lot of documentation on how to set this stuff up. Otherwise people will just keep using the alternatives. I was able to get a single DigitalOcean droplet to work with Cloudflare DNS set with an A record for the Droplet and Proxy Status set to "Proxied", i.e. terminating HTTPS. But when I added a DigitalOcean load balancer in front of the Droplet (with the health check for /up on port 80) it's always red. When I try to visit the domain for the load balancer, which is setup in Cloudflare DNS as an A record with "DNS only", I get Cloudflare handshake errors. I feel like I've tried every combination of variables (i.e. editing production.rb in Rails, editing deploy.yml, spinning up new Droplets, toggling Cloudflare Proxy Status) and I'm 12 hours in and can't find the right set of variables. There should just be a cookbook in the Kamal docs for the common setups for Rails 8 + Kamal 2, or else I'm going to go back crying to fly.io 😭 |
I'm sorry if this had been discussed. Couldn't find it anywhere.
This line from the config template got me puzzled:
I've always believed that one has to have SSL at the origin server even if behind a public proxy such as Cloudflare.
Because, otherwise, the request between Cloudflare and the origin server will travel through the public internet unencrypted, right? Like this:
User <-encrypted-> Cloudflare <-plain-> Origin
Don't we want to have this instead?
User <-encrypted-> Cloudflare <-encrypted-> Origin
I understand that the ultimate answer is "well, it's up to you" which is fair. However, I feel like the way this comment is phrased might deceive users into thinking that they have complete User<->Server encryption when they actually don't.
Or am I missing something here?
The text was updated successfully, but these errors were encountered: