[cups.bugs] SSL by default (was: cups administration how to log on?)
Johannes Meixner
jsmeix at suse.de
Wed Feb 8 01:35:26 PST 2006
Hello,
On Feb 7 12:58 Michael Sweet wrote (shortened):
> I still have to add the location redirector for non-CUPS clients
> (instead of returning 426 Upgrade Required)
Great!
What the main problem is:
It doesn't help regarding system security whether or not cupsd
accepts the credentials for admin authentication (e.g. when
not root but only an admin is allowed to set up or change queues)
because most innocent persons who get the authentication dialog
will enter "root" and the root password and send this via an
unencrypted network protocol to the cupsd.
Details:
Normally the CUPS web-interface uses the HTTP protocol.
"basic" authentication via HTTP protocol sends the credentials
unencrypted (only base64 encoded) via network.
Even "digest" authentication is actually not more secure, see
in the "CUPS Software Administrators Manual" the sections
"Using Basic Authentication" and "Using Digest Authentication".
As far as I know this is because nowadays a brute-force attack
may take only a few hours (or a few days) to find a clear text
string for a given MD5 sum.
Therefore the problem is:
How to avoid that innocent persons send the root password
in an unencrypted way via network.
I think the solution is to allow only HTTPS for administration
by having by default in cupsd.conf
---------------------------------------
<Location /admin>
....
Encryption Required
---------------------------------------
The problems with "Encryption Required" are:
- Neither Mozilla nor Konqueror work with
"Upgrading to TLS Within HTTP".
But this problem is solved in CUPS 1.2 via redirection.
- How to get the necessary certificates?
SSL/TLS by default requires to have by default the files
/etc/cups/ssl/server.key and /etc/cups/ssl/server.crt
Could those files be autogenerated during the
installation of CUPS?
For example as described in ENCRYPTION.txt via
openssl req -new -x509 -keyout /etc/cups/ssl/server.key \
-out /etc/cups/ssl/server.crt -days 365 -nodes
chmod 600 /etc/cups/ssl/server.*
Of course such self-signed certificates are only meant
to get the data transfer encrypted and cannot make sure
that really the right CUPS server machine is accessed.
- If there are already certificates on a system (e.g. really
signed certificates), they cannot be directly used by
the cupsd via something like
ServerCertificate /etc/ssl/servercerts/servercert.pem
ServerKey /etc/ssl/servercerts/serverkey.pem
because the cupsd (at least in CUPS 1.1) would brutally
change owner, group and permissions of those files
so that other services can no longer use them.
For example on Suse Enterprise Server there are the files
/etc/ssl/servercerts/servercert.pem
/etc/ssl/servercerts/serverkey.pem
which are sufficiently protected and use an ACL to grant
access exactly for the services which need them:
-rw-r--r-- 1 root root ... servercert.pem
-rw-r-----+ 1 root root ... serverkey.pem
The workaround is to copy them to /etc/cups/ssl/
but then SSL would no longer work for CUPS when they expire
even if the system admin had updated the original certificates
in /etc/ssl/servercerts/
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix at suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
More information about the cups-devel
mailing list