OK, so to summarise:
On the server side, getting Jetty to serve SSL is simple enough. In
ServerRpcProvider.java, use:
SslContextFactory sslContextFactory = new SslContextFactory();
sslContextFactory.setKeyStore("/home/.../keystore.ks");
sslContextFactory.setKeyStorePassword("secret");
SelectChannelConnector connector = new
SslSelectChannelConnector(sslContextFactory);
The most difficult part is passing the configuration settings around
(instead of hard-coding it like I did). I changed the syntax of
http_frontend_public_address to include a scheme, e.g.
http_frontend_public_address = https://localhost:9898
http_frontend_addresses = ${http_frontend_public_address}
That required changing the type from InetSocketAddress to a pair of an
InetSocketAddress and an SSL flag.
On the client side, getting it to work with Chromium just means changing
wss: to ws: in WebClient.java, but socket.io ignores the scheme and uses
http in all cases. It sounds like you have a patch for this?
On 2012-01-17 16:57, Ali Lown wrote:
Yes. Because you have only changed it to support secure web sockets.
In Firefox (even v9) it still reverts to XHR-Multipart (or simpler)
which if you check (use Firebug) will still be attempting to connect
to a http:// url.
To fix this you need to manually edit (inside the jar file
third_party/runtime/socketio/socketio-core-0.1-SNAPSHOT.jar) the
socketio.js file to use https URLs.
Because this is a bit of a mess/hack, I am looking into editing the
code such that the jetty server serves SSL pages directly (should be
possible).
On 17 January 2012 16:53, Thomas Leonard<[email protected]> wrote:
OK, so after editing WebClient.java to change "ws:" to "wss:", it works from
Chromium but not from Firefox. So I guess it works for raw web-sockets but
not for socket.io?
Any chance of getting socket.io updated to fix this?
On 2012-01-16 09:31, Ali Lown wrote:
I have also been playing around with this.
I went for using stunnel to handle the actual termination, and then
editing the socket.io code to force the websockets to be initialised
using wss:// instead.
On 16 January 2012 09:27, Thomas Leonard<[email protected]>
wrote:
Are there any instructions on configuring WiaB to use SSL?
I tried changing ServerRpcProvider to use SslSelectChannelConnector
instead
of SelectChannelConnector and that allowed me to view the login page
using
https://localhost:9898, but then it gives lots of errors like this:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
so I assume some change is needed at the client end too.
The reasons I want to do this are:
1. The usual encryption/confidentiality reasons.
2. I can allow access only for our organisation by only trusting our CA,
meaning I don't have to rely so much on the correctness of the WiaB auth
code.
3. Hopefully I can use client authentication so that users don't need to
log
in or remember passwords, etc. This also means that everyone will get the
correct user name (rather than letting them choose their own), which is
important for the imported waves (otherwise, someone can register a new
account with someone else's name and get access to that person's imported
waves).
Thanks,
--
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK
tel: +44 23 8059 8866
mailto:[email protected]
http://www.it-innovation.soton.ac.uk/
--
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK
tel: +44 23 8059 8866
mailto:[email protected]
http://www.it-innovation.soton.ac.uk/
--
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK
tel: +44 23 8059 8866
mailto:[email protected]
http://www.it-innovation.soton.ac.uk/
