I've now got X.509 client authentication working working too. Now, when one
of our users goes to our server it:
- checks that their browser has a certificate issued by us (from our
Microsoft Active Directory Certificate Services)
- generates a wave ID for them automatically, based on the email address in
their certificate
- creates an account for them if they don't already have one
- logs them in automatically
The patch is quite hacky (just enough to get it working), but in case anyone
wants to see how it works:
https://github.com/tal-itinnov/wave/commit/ae8d59c5725a74bcf0fc2ae08ae5694abca02a7f
This means that everyone gets access to their old imported waves (i.e. they
can't register an account with the wrong ID, or with someone else's ID).
On 2012-02-01 22:43, Ali Lown wrote:
Updated the patch for review to the one I am using.
I haven't yet been able to solve the ICS/OpenSSL issue much to my irritation.
Ideas on this are welcome since I am not a security expert (or have
ever used JSSE before...)
On 31 January 2012 10:56, Thomas Leonard<[email protected]> wrote:
Would it be worth applying the patch anyway, with a note in the config that
this doesn't work with all clients (and is disabled by default)? That would
allow wider testing.
On 2012-01-29 23:01, Ali Lown wrote:
OpenSSL's s_client is also unable to connect when asked to use the TLS
cipher suites (but can do SSL3 ones fine).
This is despite the web browsers (Chrome, Firefox etc.) all connecting
via TLS 1.0
It is looking like a bug/limitation in Jetty's SSL engine to me now,
rather than an issue with ICS's browser.
Still looking into this issue before sending any further patches/updates.
On 29 January 2012 15:08, Ali Lown<[email protected]> wrote:
Found another issue with the implementation:
For some reason Android ICS's Browser has a 'time out' when loading
the page, yet Gingerbread, Froyo etc. are fine.
They must have changed something to do with the SSL handshake the
device performs when running ICS.
Other devices, eg. iPhone have no issue with the handshake...
Looking into this now.
On 26 January 2012 20:33, Ali Lown<[email protected]> wrote:
Oops, just discovered that my patch broke the bots (due to them all
having hard-coded 'http' URLs in the code). The fact it took me a week
despite running it on my server, suggests this code isn't ready yet.
I will submit a new patch to fix this in a few days time, once I have
had a chance to check for any other bugs it may have introduced.
On 22 January 2012 22:59, Ali Lown<[email protected]> wrote:
Sent a review request for most of the code.
To get socket.io to work correctly though I had to edit socket.io.js
in the third_party/runtime/socketio/socketio-core-0.1-SNAPSHOT.jar
(attached here for your reference).
As for the issue of privileged ports, I have chosen to run WIAB on a
non-privileged, and with the help of an iptables REDIRECT, can make it
appear to be running on 443.
Works for me. :)
On 18 January 2012 15:12, Vicente J. Ruiz Jurado<[email protected]>
wrote:
El 18/01/12 00:20, Ali Lown escribió:
I had a go at setting it up and yes this method of adjusting jetty
seems to work fine.
Over the next couple of days I will have a go at writing a patch so
that we can choose between ssl (and normal) listeners, keystore
location and password all from the configuration file.
Just to say: Great job guys!
--
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/
