[cups.bugs] SSL by default

[Michael Sweet]

Johannes Meixner wrote:
 > ...
> Details:
> 
> Normally the CUPS web-interface uses the HTTP protocol.
> "basic" authentication via HTTP protocol sends the credentials
> unencrypted (only base64 encoded) via network.

"Encryption Required" will be part of the default configuration
when the host supports encryption...  This kicks in *before*
the authentication checks, so before the user gets the
authentication challenge they will be redirected to a https:
URL...

> Even "digest" authentication is actually not more secure, see
> in the "CUPS Software Administrators Manual" the sections
> "Using Basic Authentication" and "Using Digest Authentication". 

Yeah, I know, I wrote that part of the documentation... :)

> 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.

Right, however just brute-forcing the MD5 sum is only effective
from the same IP, and if we ever add md5-sess support (which
does a sum of the whole message) then it will be that much
harder...

Anyways, SSL/TLS is a simpler solution...

> 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
> ---------------------------------------

See above...

> 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?

Yes.

>   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.

That is something the web browser (and eventually the CUPS client)
can detect - the first time you access a server, the certificate is
cached so that changes to the certificate will be noticed (that
doesn't help the initial connection spoofing, of course, but that
is what CA-signed certificates are for...)

> - 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.
 > ...

This has been changed in CUPS 1.2 - if the files are not under
/etc/cups (or whatever ServerRoot is set to), then the permissions
are not changed.

(brutally? :)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com