[BlueOnyx:18524] Re: Force secure connection

[Michael Stauber]

Hi Maurice,

> The login page of the admserver allows a choice for a secure connection. 
> Is it possible to always force it to a secure connection in a way that 
> wont interfere with updates?
> 
> I could block access to port 444, but then I have to edit 
> /etc/httpd/conf.d/blueonyx.conf to have it redirect to port 81 in stead 
> of 444, with the risk of this file getting overwritten during a yum update.

I thought long and hard about it when I designed that part of the login
mechanism for the new GUI. I also tried different approaches and ended
up with the one we have now.

When you access the GUI on port 444 the "Use SSL" toggle is set to "No".
When you access the GUI via port 81 the "Use SSL" toggle is pre-selected
to be set at the "Yes" position.

Toggling it to the opposite will redirect you to the login form on the
other port.

I think that's the best and safest compromise that we can work out
without forcibly taking any options away.

I totally agree that SSL should be the preferred choice to access the
GUI on a server that is accessed over (or in) an untrusted network. But
the way we have it now gives people the choice. If you start by
accessing at port 81 you're already good. If you start at port 444 all
you need is one click to make it a secure connection. And even better:
If you start at 444 and make that one click, no pre-filled in login
information will be submitted.

Then there is the SSL certificate issue, which we long talked about on
various occasions on this list and the developer list: AdmServ runs on
its own SSL certificate. It starts with a self signed cert that can be
replaced (via the GUI) with a "real" certificate. When you run it on a
"real" cert it'll only *not* show any browser supplied certificate
warnings (hostname doesn't match the name in the certificate) if you
access the GUI at the URL of the server name. But any access via
https://siteX.com/login will show you that warning. Which can generate
trust issues with clients that haven't been educated about the matter.
It gets worse if you have sites that don't have their own SSL
certificate to begin with.

Even the usage of the self signed SSL certificate alone (for the GUI)
can generate these trust issues, although self signed certificates
aren't inherently more insecure than "real" certificates. Thanks to NSA
and compromises of various CA authorities in recent years that is pretty
clear to all who have some insight into these matters. If you're the
only one who has access to all private parts of your certificate chain,
then you're naturally better off than having it shared with the CA
authority. Especially considering that the mechanism of revoking certs
is inherently broken.

Could we add a mechanism that forcibly redirects port 444 to 81? Or
disables port 444 to begin with? Yes, we could. Should we? I don't know.
If we do it, we end up with a solution where we expose our users to
browser related SSL certificate warnings that we need to educate them
about. Either way: It's not perfect.

-- 
With best regards

Michael Stauber