[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