0

Is a printer SSL cert really necessary if you just print? I don't use https for any administration; just http. I got a vulnerability saying that my cert was out of date.

closed as unclear what you're asking by Eric G, TildalWave, schroeder, AJ Henderson, Steve Aug 21 '14 at 21:18

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Answer this question first: Do you need a password or other authentication in order to print? or to manage it? – LatinSuD Aug 20 '14 at 18:57
  • No. It's shared on the network. – Ed Csech Aug 20 '14 at 18:58
  • Most services start both http and https with a default cert. I would recomend you to disable the https service if you do not use it (and if your security team does not demand you to use https for admin purposes). – NuTTyX Aug 20 '14 at 19:13
  • Do you care if I print to your printer? Do you care if I use your printer as an attack vector to your network? – Mark C. Wallace Aug 21 '14 at 18:29
4

If you are not using the HTTPS connection, then it would seem security is not a concern and it would be irrelevant whether the HTTPS is displaying and error. The certificate is part of what gives authenticity to the connection.

If you consider the HTTPS lack of a certificate to be a security issue, then just using HTTP itself would also be an issue. If the risk of attack does not justify using HTTPS in your scenario, you can disable it or advise users that the HTTPS version is not providing the full security, so they should not expect that (and just ignore the warning or use non-TLS/SSL HTTP).

1

HTTP(s) services on office printers are not generally necessary for normal operation. While the information and configuration options available through the web interface are useful, the same is most often also available by other means. User interfaces on the hardware itself, printer drivers, and sometimes even telnet/SSH are common alternatives to using the web interface.

Most printers also reside within a network that is generally considered "trusted". Therefore, many of the attacks which might normally be mitigated by a proper SSL configuration (HTTPS enforced, up-to-date certs signed by a trusted third party, etc.) are often considered a non-issue in the environment. Even when such attacks are a concern, many printers ship with self-signed or vendor-signed certificates which cannot be traced back to a trusted Certificate Authority. Because of this, most users are already acclimated to clicking through "Invalid Certificate" warnings when accessing the HTTPS interface.

Given the above, and some basic knowledge of how printers and SSL work, we're left with a few questions to be answered.


Does the printer really need to be connected to the network directly?

This is a serious question you should ask, if you're not keen on addressing the web interface vulnerabilities or you're worried that new web vulnerabilities might pop up on the device later on. If the printer can equally serve its purpose while being directly connected to another system via USB (and then shared from that system, if necessary), the simplest way to resolve this is to do just that. A printer linked via USB only poses much less of a network-accessible risk than one which is directly linked to the network.

Is the web interface to the printer needed at all?

If you have no use for the additional features available through the web interface, and/or all web-accessible features are available to you via some other means, then the simplest answer (if possible) is to just disable the web interface entirely. That means on both HTTPS and HTTP.

Are you concerned that someone on the network might sniff the credentials and other traffic you send to the printer, or inject malicious code into the web interface?

There are several reasons you might be, even if the printer is on a "trusted" network. However, if you're comfortable in accepting the risk of a user inside your network being able to read and/or manipulate the traffic between you and the printer's web interface, you may want to consider (if possible) just disabling the HTTPS service and leaving HTTP on. Everything you send will be in the clear, and a man-in-the-middle could easily inject code into your traffic stream that tries to exploit browser bugs and drop malware onto your users' computers, but you won't have to worry about that HTTPS vulnerability (which you don't care about anyway) showing up in future reports. If this security risk is a concern however, you should instead disable HTTP (if possible) and force all web interface users onto HTTPS.

Really, how worried are you about man-in-the-middle attacks?

Switching to HTTPS, with a proper certificate in place, does effectively mitigate the concerns raised in the previous question. However, without a proper certificate - as is your current standing - you're potentially still vulnerable to the same attacks. Only an extremely diligent user will notice when one invalid certificate is replaced with another, via man-in-the-middle attacks. Others will just happily click on through the warnings they're used to seeing (and, possibly, some they're not) thereby routing their connection with the printer through the attacker's system. Once the attacker has tricked your users into trusting their certificate, they can impersonate the user to the printer and vice-versa. This essentially allows them to conduct the same sort of data sniffing and code injection attacks they would have been able to do if the traffic was unencrypted entirely.

At this point, assuming you've decided you need the web interface and must use HTTPS to protect against sniffers and man-in-the-middle attacks, it's up to you to decide whether it's appropriate to go all the way and make sure HTTPS is being used properly. If you're comfortable enough having broken HTTPS on the printer, and you can provide a good explanation to justify it, ask your IT Security department what you need to do to request an exemption for the printer. If you are seriously concerned about doing HTTPS right, and/or you cannot get an exemption for the particular device in question, then you need to explore options for getting a proper certificate installed on the printer. Most printers do not have readily-available mechanisms to import a new certificate - e.g.: one which you generate yourself, including a signature from a trusted CA. However, it is possible the printer vendor may have provided a firmware update which includes a certificate refresh.


As with all vulnerabilities, how you handle this is up to you to decide. If the printer must be networked, and you need to have that HTTPS web interface, and you want to be protected against MitM attacks, then you should contact the printer vendor to discuss what options are available for fixing the SSL certificate issue. Otherwise, there's plenty of ways to work around it.

Not the answer you're looking for? Browse other questions tagged or ask your own question.