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
Attachment:
pgpjX1NofQ9Mb.pgp
Description: PGP signature