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

Support for secure websockets #15

Closed tresf closed 9 years ago

tresf commented 9 years ago

Firefox by default blocks non-secure websockets connections from HTTPS locations. This is meant to be a placeholder for secure websockets (wss://) support.

Current design includes: (please check off items as they are completed):

tresf commented 9 years ago

@sjennison per e466811, 165cdb9 Windows support should be finished. Can you take a look at implementing the Java portion?

tresf commented 9 years ago

@robertcasto is @sjennison planning on tackling this still?

sjennison commented 9 years ago

Yep - I'll be working on it today

tresf commented 9 years ago

Great! :+1:

tresf commented 9 years ago

@sjennison FYI, updated the GitHub checklist to illustrate task completion of Ubuntu cert generation and installation.

To try out the windows self-cert portion, you'll have to:

As always, please email me if you need any assistance with this.

-Tres

sjennison commented 9 years ago

@tresf - is there a good way to reference that properties file from the Java code? Not sure where it would end up from the code in the .js file :)

tresf commented 9 years ago

@sjennison,

It should be in the install directory. For the installed-version (not running through IntelliJ), this should be the same directory as ShortcutUtilities.getJarPath().

For when running through IntelliJ, the properties won't necessarily be available, but we can discuss that later.

tresf commented 9 years ago

@robertcasto @bberenz, FYI, Firefox didn't like the .crt unless I enabled a CA flag on it via. https://github.com/qzind/qz-print/commit/87dd86b5f5a10df14c090b8dd31b95407007c9fb

Not sure if jetty needed this flag too, so FYI.

sjennison commented 9 years ago

So it's importing successfully into Firefox?

On Wed, Apr 22, 2015, 23:08 Tres Finocchiaro notifications@github.com wrote:

@robertcasto https://github.com/robertcasto @bberenz https://github.com/bberenz, FYI, Firefox didn't like the .crt unless I enabled a CA flag on it via. 87dd86b https://github.com/qzind/qz-print/commit/87dd86b5f5a10df14c090b8dd31b95407007c9fb

Not sure if jetty needed this flag too, so FYI.

Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/15#issuecomment-95407122.

tresf commented 9 years ago

@sjennison, only manually at the moment. The NSIS stuff is still giving me a hard time per #18.

I'm tempted to look into a JNI approach because Firefox is a very difficult beast as it simply won't read from the OS certs by design.

But back on topic... yes, it will import into Firefox now via manual method. That CA flag passed into Java's keystore generator was the ticket.

image

tresf commented 9 years ago

Steven said he left a note, but just to be sure: the installed qz-tray certificate needs the common name (CN) to be pointing to localhost for the secure websockets to work correctly.

@bberenz This is defined here:

https://github.com/qzind/qz-print/blob/1.9/qz-print/ant/self-sign.properties#L19

We should be able to just change this from -dname \\"CN=${jks.company}, to -dname \\"CN=localhost,.

Want me to do that now, or are you comfortable trying it?

tresf commented 9 years ago

@bberenz @sjennison do we have a way of detecting an invalid cert in JavaScript for the wss:// stuff? If so, perhaps we can provide manual instructions to the user to import the cert into Firefox until we develop an automated way.

tresf commented 9 years ago

@sjennison @bberenz what was the trick to get the cert working with Chrome? I finally have IE working, but Chrome won't connect.

I've changed CN=localhost vi 21425a6 and Internet Explorer works, but Chrome Version 42.0.2311.90 m is still giving me a hard time. Here's a copy of the cert...

CERT

-----BEGIN CERTIFICATE-----
MIIDaTCCAyegAwIBAgIELL8xhzALBgcqhkjOOAQDBQAwfDELMAkGA1UEBhMCVVMxCzAJBgNVBAgT
Ak5ZMRIwEAYDVQQHEwlDYW5hc3RvdGExGzAZBgNVBAoTElFaIEluZHVzdHJpZXMsIExMQzEbMBkG
A1UECxMSUVogSW5kdXN0cmllcywgTExDMRIwEAYDVQQDEwlsb2NhbGhvc3QwHhcNMTUwNDI3MDQw
NjM3WhcNMzUwNDI3MDQwNjM3WjB8MQswCQYDVQQGEwJVUzELMAkGA1UECBMCTlkxEjAQBgNVBAcT
CUNhbmFzdG90YTEbMBkGA1UEChMSUVogSW5kdXN0cmllcywgTExDMRswGQYDVQQLExJRWiBJbmR1
c3RyaWVzLCBMTEMxEjAQBgNVBAMTCWxvY2FsaG9zdDCCAbgwggEsBgcqhkjOOAQBMIIBHwKBgQD9
f1OBHXUSKVLfSpwu7OTn9hG3UjzvRADDHj+AtlEmaUVdQCJR+1k9jVj6v8X1ujD2y5tVbNeBO4Ad
NG/yZmC3a5lQpaSfn+gEexAiwk+7qdf+t8Yb+DtX58aophUPBPuD9tPFHsMCNVQTWhaRMvZ1864r
Ydcq7/IiAxmd0UgBxwIVAJdgUI8VIwvMspK5gqLrhAvwWBz1AoGBAPfhoIXWmz3ey7yrXDa4V7l5
lK+7+jrqgvlXTAs9B4JnUVlXjrrUWU/mcQcQgYC0SRZxI+hMKBYTt88JMozIpuE8FnqLVHyNKOCj
rh4rs6Z1kW6jfwv6ITVi8ftiegEkO8yk8b6oUZCJqIPf4VrlnwaSi2ZegHtVJWQBTDv+z0kqA4GF
AAKBgQDyXs6wiYxW/gxTjqgZkN4tumetN4x9suJIj417TrOO3BVTiCwDGvh0ZiCYOa/9zER48tup
667iVLct4IrSpwILYQBCogzXmprcKF7KuBsTNNvlmfj1XFGwOs1ugFGD+fuSF+0I7mE9tJef+aIc
tB53vTua28ODKAbc2s/5ytgMk6M1MDMwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUAnVO
PmD1FqVAxXY8zfnuOQSh5tEwCwYHKoZIzjgEAwUAAy8AMCwCFDkdULIY6GD55uWgzk40yz2CTmUV
AhQ+/FXTbJRLXNoSAGGhbuEoN+dYCQ==
-----END CERTIFICATE-----
tresf commented 9 years ago

So it turns out the certificate wasn't complex enough. I bumped it to RSA 2048 via 5dd5011 and it seems to be in much better shape now.

Chrome is working now, but Firefox is not unless I hand-allow the cert exception via https://localhost:8181.

The Firefox error is: mozilla_pkix_error_ca_cert_used_as_end_entity

Edit: Somewhat related, here's a decent conversation about it: https://bugzilla.mozilla.org/show_bug.cgi?id=1034124

From what I'm reading, Firefox is smart enough to know that the HTTPS is running from a CA generated cert, which is taboo (but overridable). @sjennison does this mean we'll have to issue an End-Entity certificate from the CA to circumvent this Firefox behavior?

tresf commented 9 years ago

So I've been looking for a valid way to generate a certificate chain for a web server, and came across this, specifically the section Generating Certificates for a Typical SSL Server

http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html

A couple of questions...

Do we need all three components:

  1. Root
  2. CA
  3. Server

Or can we get away with two:

  1. Root
  2. Server

I've begun adapting the tutorial to a batch file to wrap my head around everything... Its not working yet, so I'm calling it a night, but this is what I have so far:

@echo off
del ca.jks root.jks server.jks
set keytool="C:\Program Files (x86)\Java\jre1.8.0_31\bin\keytool.exe"
set dname="CN=MyCompany, OU=MyCompany, O=MyCompany, L=City, S=State, C=US"
set dnameserver="CN=localhost, OU=MyCompany, O=MyCompany, L=City, S=State, C=US"

%keytool% -genkeypair -noprompt -keystore root.jks -alias root -keyalg RSA -keysize 2048 -dname %dname% -storepass 123456 -keypass 123456 -ext bc:c
%keytool% -genkeypair -noprompt -keystore ca.jks -alias ca -keyalg RSA -keysize 2048 -dname %dname% -storepass 123456 -keypass 123456 -ext bc:c
%keytool% -genkeypair -noprompt -keystore server.jks -alias server -keyalg RSA -keysize 2048 -dname %dnameserver% -storepass 123456 -keypass 123456
%keytool% -keystore root.jks -alias root -exportcert -rfc -storepass 123456 -keypass 123456 > root.pem
%keytool% -storepass 123456 -keystore ca.jks -certreq -alias ca | %keytool% -storepass 123456 -keystore root.jks -gencert -alias root -ext BC=0 -rfc > ca.pem
%keytool% -keystore ca.jks -importcert -alias ca -file ca.pem -storepass 123456
%keytool% -storepass 123456 -keystore server.jks -certreq -alias server | %keytool% -storepass 123456 -keystore ca.jks -gencert -alias ca -ext ku:c=dig,kE -rfc > server.pem
copy /b root.pem+ca.pem+server.pem | %keytool% -keystore server.jks -importcert -alias server
tresf commented 9 years ago

So I'm still struggling to get past the end_entity Firefox error.

I believe this is possible if we can chain a separate server certificate just for jetty, but I'm struggling to find a way to do this on-the-fly as I can't figure out a way for Java to process a CSR in order to make a certificate chain.

I've read quite a few tutorials and they all seem to be under the assumption that the CSR is processed by a 3rd party CA using something like OpenSSL, but we don't necessarily have OpenSSL at install time so I'd like to rule out Java's keytool first, prior to distributing the installers with OpenSSL binaries....

tresf commented 9 years ago

Initial Firefox support on Windows has been added via 8d61a68

sjennison commented 9 years ago

Awesome! Anything you need me to do on this now?

On Thu, Apr 30, 2015, 00:04 Tres Finocchiaro notifications@github.com wrote:

Initial Firefox support on Windows has been added via 8d61a68 https://github.com/qzind/qz-print/commit/8d61a688c64265214c6a14f92025ed1177f41d6c

Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/15#issuecomment-97654359.

tresf commented 9 years ago

A better understanding of the feasibility of HTTP fallback support would be a plus although that may be a @bberenz task.

tresf commented 9 years ago

Also, were you able to reproduce the installer problem you had reported?

akberenz commented 9 years ago

Fallback support added via 9ebe9459be71a81586e79c403d7b69999531644e. The socket will attempt all the WSS ports before trying the WS ports, so insecure connections will take a little longer to be established.

tresf commented 9 years ago

@bberenz, this is great, thanks. One thing we haven't added yet is the ability to start the server on ws://. Ideally, we'd have at least one and up to two instances listening.

tresf commented 9 years ago

Apple is working per https://github.com/qzind/qz-print/commit/84d8b5365a3d6c96649d55db1edd03fecc660a82

We still have a few items to work out in terms of how to Uninstall properly, etc, but the screenshot below has Firefox and Chrome running using Secure Websockets.

image

tresf commented 9 years ago

A tester reported an issue launching the software on Apple per #22 which is hopefully fixed now.

The next items are installer related:

tresf commented 9 years ago

Remaining items (Linux installer cleanup, will start new thread):