Hello Debian Printing Team, first of all, I would like to thank you for maintaining printing-related packages in Debian, making printing from Debian boxes possible!
I am considering the switch to driverless printing for some of the Debian boxes I administer and I have read the dedicated Debian wiki [page]. [page]: <https://wiki.debian.org/CUPSDriverlessPrinting> I have some questions about this. If I understand correctly, there are three main methods to print driverless to a networked printer (one that supports driverless printing, of course): 1. manually configure a permanent (driverless) print queue (e.g. using lpadmin) and send stuff to it (e.g. using lpr) 2. look for available networked printers (e.g. with `lpstat -e`) and send stuff to a printer (e.g. using lpr), via a temporary print queue, which is created on-the-fly by CUPS and then destroyed after a short timeout 3. rely on cups-browsed to automatically create print queues corresponding to available networked printers and send stuff to one of these queues (e.g. using lpr) The first method seems to make sense mainly for a machine which is connected to a fixed network (such as a desktop box or similar), where you know in advance which printers are available. It seems to be somewhat inconvenient for a laptop which will be connected each time to a different network, where completely different printers will be available. The other two methods seem to be more fit for this laptop scenario. One thing that is not clear to me (I haven't found any documentation about this) is: if the client machine (desktop or laptop) has its own firewall (e.g. nftables), which (TCP or UDP) ports need to be opened in input and which in output in order for the first method to work correctly? Which ports are needed for the second method? Which ports for the third method? Another thing I am puzzling over is related to the security concerns of these setups. If I understand correctly, sending stuff to a networked printer is done with the IPP protocol, which has, by default, no encryption or printer identity check. If someone is sniffing traffic on the local network, he/she can read anything I am sending to a networked printer. To avoid this, I could maybe use a IPP over TLS/SSL, if at all possible. But do driverless printers support this possibility? If so, is this possibility compatible with any of three above-mentioned methods? Even with encryption to avoid sniffing, how do I know for sure that I am sending stuff to the intended printer? Without printer identity check (e.g. with a fingerprint of a TLS/SSL certificate or some other cryptography key), someone on the local network could announce himself/herself as a printer with a name identical or very similar to an existing legitimate printer, trick me in sending stuff to this fake printer, read my stuff and forward it to the legitimate printer (man-in-the-middle attack). Is printer identity check possible, to avoid this attack? Is it compatible with any of the three above-mentioned driverless printing methods? Does it conflict with the practicality of printing without having to configure stuff for each different printer? Please note that I have read the [section] about duplicate print queues: some of my concerns come from thinking about the duplicate print queues issue... [section]: <https://wiki.debian.org/CUPSDriverlessPrinting#Duplicate_Print_Queues> All this adds up to the concern that a printer announcing itself on a local network will cause something to happen on my machine (especially when adopting the second or the third driverless printing method, with queues automatically created by CUPS): listening to printer announcements increases the attack surface and exposes the machine to potential malicious packets that could exploit some vulnerability in CUPS (such as [CVE-2024-47176], which is now fixed, but other vulnerabilities may be found in the future). [CVE-2024-47176]: <https://security-tracker.debian.org/tracker/CVE-2024-47176> If you have read thus far, thanks a lot for bearing with me! ;-) I would appreciate any answer/comments on these topics. P.S.: Please Cc me on replies, I am not subscribed to the list. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgp_tPj849wls.pgp
Description: PGP signature
