search

qzind / qz-print

Archive for legacy qz-print versions (1.8, 1.9). See https://github.com/qzind/tray for modern versions.
Other
141 stars 101 forks source link

Remove static localhost bindings in code #91

Closed tresf closed 8 years ago

tresf commented 9 years ago

We have a user that has taken the time to convert QZ Tray to use a hostname instead of localhost which may help for our Citrix enhancement (#83) via fc33512 1eb2350 005da8a.

This is a placeholder to enhance the localhost bindings to allow an IP address or hostname similar to the aforementioned commits (we'll leave localhost as default).

Questions...

dsanders11 commented 9 years ago

I think the list is rendering a bit off, but I think I can read it how it was intended.

Something I'll point out in regards to this: With the custom certificate generation, it would be very useful to be able to supply a root certificate to use for signing the generated certificate, or simply the ability to supply an existing certificate in the installer.

When I implemented this in my use case, I generated a root CA certificate and installed that on the client machines which would need to print (several Apple and a Windows). From there I used that certificate when manually rolling a certificate (for the WebSocket) for the qz-print installation, that way if I change the hostname or anything like that I don't have to redeploy the generated certificate to client machines, things will continue to work since the root certificate was already installed.

This also allows for easily adding more qz-print installations since they would all be signed using the root certificate and will work out of the box.

tresf commented 9 years ago

This also allows for easily adding more qz-print installations since they would all be signed using the root certificate and will work out of the box.

I'm going to pick on semantics here a bit (sorry) but signing is done using a private key. Would you distribute that same private key to all machines? This is what Lenovo did with the superfish blunder and it's normally frowned upon, but risk is minimal if the cert is bound to a particular hostname rather than a wildcard domain (I assume you did this?).

We'd likely keep the certificate something completely separate from what the company uses as to not encourage such a security threat, so my idea is to make the private key and certificate something that would be grabbed from the "print server" at install time and then distributed to the clients (private key distributed for signing, certificate used for allowing the HTTPS traffic). Does that make sense?

dsanders11 commented 9 years ago

Yes, the private key for the self-signed CA certificate.

To avoid any extra confusion here, since there are two certificate/private key pairs at play here: the one used for secure traffic on the web socket (WSS) and the one used for securing print requests to qz-tray.

To make life simpler, both of those certificates in my deployment were signed with the private key of a self-signed CA certificate, and the self-signed CA certificate was distributed to any client machine wishing to print. The private key for the CA certificate has been kept private and was not distributed.

I'm not overly concerned with security in this situation since the private key of the CA certificate is not needed for day to day operations.

My suggestion for allowing providing this private key with the CA certificate during qz-tray installation is indeed a bit of a security risk, but the private key would reside on the machine temporarily (if properly deleted) and could be password protected. My alternative suggestion was to allow for the already generated WSS certificate and private key to be provided since they could be generated offline (and bound to the hostname of that machine).

tresf commented 9 years ago

The private key for the CA certificate has been kept private and was not distributed.

Oh of course because the PCs won't have the software running. :bulb:

Thanks for the explanation.

tresf commented 9 years ago

I think the list is rendering a bit off

Thanks, fixed. :+1:

tresf commented 9 years ago

Added initial support for non-localhost bindings via https://github.com/qzind/qz-print/commit/f8b273af8b6d2f8a0189a120bbae042d5afaca7d

Although an install-time approach is likely preferred, handing the different host.domain input methods on Apple, Windows and Linux adds a complexity (fetch input via AppleScript, NSIS, bash) as well as an unnecessary prompt to our base installer that probably isn't worth it... so here's the initial support...

For secure websocket non-localhost bindings

Generating keystore and certificate on Windows (Linux support is started too but needs testing)

  1. Install QZ Tray via the desktop installer
  2. Open cmd as Administrator

  3. Run the following command, where host.domain is the IP or hostname QZ Tray will be running on.

    • Note: If you require Firefox wss:// support, Firefox needs to be installed prior to running this command.
    cd "%PROGRAMFILES%\QZ Tray\"
cscript auth\windows-keygen.js . install host.domain
    • This will re-run the keygen utility, but re-generate the qz-tray.properties, qz-tray.crt and qz-tray.jks using the provided domain.
  4. Create a copy of the qz-tray.crt and deploy to workstations which will connect to the supplied domain using wss:///
  5. If Firefox support is needed, copy the following files from the Firefox installation directory:
    • defaults/pref/firefox-prefs.js
    • firefox-config.cfg
    • Note: If unsure of the location of these Firefox files on your system (Linux, Mac, etc), install QZ Tray on a test system and search for them by name. They are both created by QZ Tray and can safely be overwritten with ones copied.

Testing

  1. Copy demo folder from QZ Tray to a separate test PC.
  2. Install qz-tray.crt into Trusted Root Certificates (this process will vary depending on platform)
  3. Open Google Chrome
  4. Right Click, Inspect Element on the sample page
  5. Click the Console tab
  6. Verify the secure websocket connection to 8181 succeeds.

Note

  1. deployQZ needs to have hostname provided... i.e. deployQZ('host.domain'), which currently isn't in the qz-websocket.js.
tresf commented 8 years ago

deployQZ("foo.bar") added via 6f1cd58 Apple support is done via 91487b0.

Last step is documentation.

Edit: Documentation started here: wiki/Print-Server @klabarge to complete and publish to home page.

tresf commented 8 years ago

Documentation finished via https://github.com/qzind/qz-print/wiki/print-server.

Some Linux and Mac steps need to be added for cross-platform support, but the enhancement is completed.

dsanders11 commented 8 years ago

Awesome!

tresf commented 8 years ago

@klabarge FYI, we'll need to fix the wiki for 2.0 as it makes specific reference to deployQZ which is a 1.9-only feature.

https://github.com/qzind/qz-print/wiki/print-server#deploy-qz

klabarge commented 8 years ago

Documentation updated: https://github.com/qzind/qz-print/wiki/Print-Server#connect-to-qz-tray