The short summary of this is that today there are 2 settings:
require_ssl- Force SSL is used for all non-unattended URLs
require_ssl_smart_proxies- Force SSL client certificates for Smart Proxies
My proposal is to drop these settings and make them mandatory (their current defaults)
Update: during this RFC it became clear there was still a use for the
This was inspired by Rails 6.1 which removes the controller level SSL enforcement (deprecated in 6.0).
Let’s start with
require_ssl. This can be turned off, in which case plain text HTTP is allowed. Today the installer defaults to
ssl is on. While users can pass
--foreman-ssl false, I don’t know how well this actually works.
Having fewer code paths, makes things easier. It’s also fairly standard to deploy applications using HTTPS nowadays.
Another benefit is that we can start to implement the HTTP → HTTPS redirect for non-unattended URLs in Apache instead of relying on Rails. While that’s out of scope for this PR and could technically already be done today, it’s worth pointing out.
It should be considered that many development environments don’t use HTTPS. That’s why I’m proposing to keep this limited to production environments (
If this setting is true (the default) The Smart Proxies authenticate using SSL client certificates.
If it’s false, other means can be used. Today reverse DNS can be used (foreman/smart_proxy_auth.rb at bde7047acb8a68a899f60585f751093c9713bb92 · theforeman/foreman · GitHub). I’d argue this is unsafe and we should not have this code at all.
For non-SSL we also have reverse DNS as a means (foreman/smart_proxy_auth.rb at bde7047acb8a68a899f60585f751093c9713bb92 · theforeman/foreman · GitHub). Perhaps this should be hidden behind
!Rails.env.production? so developers can still use it in their development environments.
It should also be noted that prior to Feature #30779: Use ActionDispatch::RemoteIp when working as a reverse proxy - Foreman users could spoof the remote IP if they came from the local network. That in combination with reverse DNS checks means it’s easy to bypass these security checks. After this, it may actually be that the Katello HTTP reverse proxy setup that it ships opens this security risk. Removing the option for users to shoot themselves in the foot makes the project more secure.
- We drop require_ssl_smart_proxies and make it always true.
- Drop reverse DNS as a potential Smart Proxy authentication mechanism over SSL
- Limit Smart Proxy authentication over HTTP to non-production mode
Update: the original RFC missed the word “Drop” in the second point. That caused some confusion.