Encrypted printing to port other than 443

iikka at trueflaw.com iikka at trueflaw.com
Sun May 23 09:19:23 PDT 2004


Hi all,

I tried to set up SSL-encrypted printing from Mac OS X client to linux server over network and run into serious problems. (The story is long as is, so most of the dirty details have been left out.)

First I set up the linux-server, which seemed to go OK. I could not bind the IPP-using-HTTPS to port 443, because it's already used by the HTTPS-server, so I picked an arbitrary port I'm not using for the IPP-using-HTTPS. As it happens, this port was 632. So the server is now listening to 631 for regular HTTP-requests and 632 for HTTPS-requests. I can connect to the server with a web browser, print test pages and watch the print queues over http (port 631) and https (port 632). So this part seems to be up and running OK.

Next, I added a printer to the Mac OS X client using the Apple GUI with the "advanced" mode, where I could give the device URI directly with usernames and passwords, e.g. http://username:password@my.server.name:631/printers/myPrinter. No hick-ups here.

Next, I wanted to do the same with SSL-encryption. Not so smooth experience:
   First I added a symlink to the backend directory https->ipp. After HUPping the CUPS-server, the https: showed in the GUI list, so I proceeded as before and gave the device URI for the printer:
https://username:password@my.server.name:632/printers/myPrinter
The GUI client accepted this URI, so I went on to test it out and print a page - no luck. The print spooler (or whatever, the GUI thingy that shows print progress), tries every 10 seconds to re-send the page with no luck. The CUPS error_log on the server says (every 10 seconds):
E [...] EncryptClient: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
E [...] Bad URI "HTTP/1.1" in request!
So, apparently the ipp-backend-client with the https-protocol and the https-URI isn't talking https, after all.

I tried numerous things to convince the client to use https, including setting "Encryption always" in the ~/.cupsrc and client.conf, which only took down the whole local cups server, which was not configured for SSL. In the end I downloaded the cups source, and studied the client code to see, how the encryption decision is made. It appears, (I hope I'm mistaken) that the logic goes as follows:
   - if the port is 443 go to SSL/TLS (Encryption always)
   - if the configure-files or environment variable sets Encryption globally, respect that
   - else set encryption to TLS on request (Encryption ifRequested)

.. so the https: part of the URI is not consulted, and the only options for using SSL is to use port 443 or set Encryption always globally. As I explained earlier, neither of these was a relevant option for me, so i patched the code to do: if the port is 443 or 632 go to SSL/TLS, compiled cups, installed libcups to relevant location, HUPped cups, and hooray, it all works beautifully. Thank god it's open source.

Now, this is hardly the optimal solution. It's laboursome, not very general, and worst of all, I'm probably going to lose this functionality with every major OS update Apple makes, and so I'll have to patch each cups version and play with the libraries.

So, I have few requests to whomever it may concern:
    1. Please prove me wrong. There's got to be an easier solution, that I've overlooked. Please reveal it to me, underline it in the CUPS manual and put it under "encryption".

    2. If not, please patch the next version of CUPS to handle this better. Options include:
       - consult the URI to see if https is specified
       - set a configuration directive to set Encryption always on per-server:port basis
       - reserve a new port for IPP-using-HTTPS and replace 443 with that.

All of these seem to be trivial patches to the code; IMHO, the best one would be the first one. I'd be happy to contribute the patch to do this, if that would help.

Sincerely,

Iikka







More information about the cups mailing list