Support for secure websockets

[tresf]

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):

• Generating a jself-signed Java Keystore
• Windows
• MacOS
• Ubuntu
• Exporting an OS certificate
• Windows
• MacOS
• Ubuntu
• Installing/import OS certificate
• Windows
  • Chrome (via System Store)
  • Firefox (via NSIS + AutoConfig)
  • Firefox (via System Store)
• MacOS
  • Chrome (via System Store)
  • Firefox (via certutil or AutoConfig)
  • Safari (via System Store)
• Ubuntu
  • Chrome (??)
  • Firefox (via certutil or AutoConfig)
• Add secure websocket support to QZ-Tray/Jetty
• Add HTTP fallback support
• Fallback method for when secure websockets fails
• Can Jetty listen on an alternate port for non-secure connections?

[tresf]

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

[tresf]

@robertcasto is @sjennison planning on tackling this still?

[sjennison]

Yep - I'll be working on it today

[tresf]

Great! 👍

[tresf]

@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:

• Install NSIS
• Do make nsis using ANT
• Run the qz-tray-1.8.90-setup.exe from the out directory
• As part of the Windows setup, the cert will be installed as part of the desktop installer (to fulfill the admin access requirement for Root store)
• Alternately if you'd rather not install the software, you can cherry-pick the windows-keygen.js file from out\build and run in in an Admin CMD window which will have the same effect. Of course, the install location would be unknown at that point, so it won't know where to put it, but you can tweak the file as needed. It's run via cscript.exe path\to\windows-keygen.js

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

-Tres

[sjennison]

@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]

@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]

@robertcasto @bberenz, FYI, Firefox didn't like the .crt unless I enabled a CA flag on it via. 87dd86b

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

[sjennison]

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
87dd86b

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

Reply to this email directly or view it on GitHub
#15 (comment).

[tresf]

@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.

[tresf]

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]

@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]

@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]

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]

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]

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]

Initial Firefox support on Windows has been added via 8d61a68

[sjennison]

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
8d61a68

Reply to this email directly or view it on GitHub
#15 (comment).

[tresf]

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

[tresf]

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

[akberenz]

Fallback support added via 9ebe945.
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]

@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]

Apple is working per 84d8b53

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.

[tresf]

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

The next items are installer related:

• Delete old certs prior to importing new ones on Apple
  • Done via b70e975
• Add uninstall support for Apple
• Add the Firefox cert logic to Linux
• Determine plan of attack for Chrome on Linux

[tresf]

• Linux Firefox and Chrome support added via c52185c
• Apple Firefox support added via 033ad08
• ws:// Fallback support added via 9ebe945 (per Brett)
• Apple uninstaller supported added via 286b2f9

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

• Determine permanent location to install on Linux
• Check for certutil prior to install on Linux, or else Chrome certs won't work
  • Possibly add yum/apt-get commands for installing
• Check for root prior to install on Linux