incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ali Lown <a.lo...@gmail.com>
Subject Re: Wave with HTTPS + client auth
Date Wed, 02 May 2012 14:02:08 GMT
Thomas,

No. I never finished tidying it up for submission.
Also, I found a small issue where 'sometimes' the certificate isn't used,
and the user gets dumped back to the login screen when both client-auth and
password-based login is enabled.

Thanks for the rebase, I might work on this this evening then.

Ali
On May 2, 2012 10:36 AM, "Thomas Leonard" <tal@it-innovation.soton.ac.uk>
wrote:

> Hi Ali,
>
> Did this get submitted? I merged the patches into one and rebased them to
> trunk if that helps:
>
> https://github.com/tal-**itinnov/wave/commit/**
> 4e2c18ef95825b3fd92034d6544054**f26c358b79<https://github.com/tal-itinnov/wave/commit/4e2c18ef95825b3fd92034d6544054f26c358b79>
>
>
> On 2012-02-13 10:26, Thomas Leonard wrote:
>
>> It seems to work fine; please go ahead and submit...
>>
>>
>> On 2012-02-11 22:07, Ali Lown wrote:
>>
>>> Thomas,
>>>
>>> I have tidied it a bit more, and added a new option (disabled_loginpage).
>>>
>>> I thought you might want to take a look at it first, and depending on
>>> your thoughs would it be ok for me to submit my (heavily adjusted)
>>> version for review here?
>>>
>>> Ali
>>>
>>> On 9 February 2012 17:01, Ali Lown<a.lown0@gmail.com> wrote:
>>>
>>>> The IsRegistrationDisabled patch was implemented to disable the
>>>> registration
>>>> page for private internet-facing servers.
>>>>
>>>> As such, to extend the same function to the client certificate, would
>>>> be to
>>>> disable the automatic registration of users who authenticate with a
>>>> certificate for a user not already on the system.
>>>>
>>>> For your idea, I feel it would be better to do that sort of check
>>>> during the
>>>> actual registration step, and use a new setting:
>>>> mustRegistrationUsernameMatchC**ert?
>>>>
>>>> On Feb 9, 2012 10:16 AM, "Thomas Leonard"<tal@it-innovation.**
>>>> soton.ac.uk <tal@it-innovation.soton.ac.uk>>
>>>> wrote:
>>>>
>>>>>
>>>>> Thanks. BTW, I was hoping to use isRegistrationDisabled the other way:
>>>>> to
>>>>> prevent people from registering any account *except* the one in their
>>>>> certificate.
>>>>>
>>>>>
>>>>> On 2012-02-08 20:43, Ali Lown wrote:
>>>>>
>>>>>>
>>>>>> Thomas,
>>>>>>
>>>>>> Yes that does fix it under Socket.IO (tested in Chrome, but means
it
>>>>>> will work with all).
>>>>>>
>>>>>> I started work on generalising your patch a bit, you can see the
>>>>>> results in my ssl_client branch
>>>>>> (https://github.com/alown/**wave/tree/ssl_client<https://github.com/alown/wave/tree/ssl_client>
>>>>>> ).
>>>>>> You will probably want to cherry-pick from that branch though, because
>>>>>> I haven't kept it completely clean...
>>>>>>
>>>>>> Ali
>>>>>>
>>>>>> On 3 February 2012 09:50, Thomas Leonard<tal@it-innovation.**
>>>>>> soton.ac.uk <tal@it-innovation.soton.ac.uk>>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Well, we only need client auth for the AuthenticationServlet,
so it
>>>>>>> should
>>>>>>> be easy to fix this by changing "Need" to "Want". Here's a patch
to
>>>>>>> do
>>>>>>> that:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/tal-**itinnov/wave/commit/**
>>>>>>> 07a604e6d5ab050f6991498afc0b26**7939e15d6d<https://github.com/tal-itinnov/wave/commit/07a604e6d5ab050f6991498afc0b267939e15d6d>
>>>>>>>
>>>>>>>
>>>>>>> Does that fix it for you under Chrome?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2012-02-02 19:38, Ali Lown wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Also, I gave your patch a shot here, and it mostly works:
>>>>>>>> - In Chrome (17-Dev Build 0/Linux 64) websockets then fail
to
>>>>>>>> connect
>>>>>>>> (despite the websocket URL being a wss://) -> perhaps
Chrome doesn't
>>>>>>>> support authenticating websockets?
>>>>>>>>
>>>>>>>> After hard-disabling websockets (or using Firefox etc.) it
works
>>>>>>>> properly.
>>>>>>>> (Cherry-pick 67d73f61b77eb89315219f715d97f3**8f386fe09e and
>>>>>>>> 8626aa5d0b10eb8627ae1a38ff3c94**4390c73b22 from my github
repo)
>>>>>>>>
>>>>>>>> And you may want to add the removal of the "Sign out" button
to your
>>>>>>>> patch -> since it doesn't exactly server much purpose
when using
>>>>>>>> client auth.
>>>>>>>>
>>>>>>>> On 2 February 2012 15:18, Ali Lown<ali@lown.me.uk>
wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Looks interesting.
>>>>>>>>>
>>>>>>>>> It would be nice to generalise and get this patch submitted
>>>>>>>>> upstream
>>>>>>>>> (certainly beats typing in a username + password each
time).
>>>>>>>>>
>>>>>>>>> Since the AuthenticationServlet already has CoreSettings
injected
>>>>>>>>> in
>>>>>>>>> the constructor, it would be quite easy for you to move
the
>>>>>>>>> hard-coded
>>>>>>>>> OID and the addresses out into the config file which
would be nice.
>>>>>>>>>
>>>>>>>>> You will probably also want to add a useClientAuth flag
into the
>>>>>>>>> settings, and update ServerRpcProvider to enable based
on this. It
>>>>>>>>> would then let you decide in the AuthenticationServlet
whether to
>>>>>>>>> serve the login page or not (rather than commenting it
out).
>>>>>>>>>
>>>>>>>>> PS. Disabling tests in build.xml is all very well (as
long as you
>>>>>>>>> remember not to commit it to a review patch (I did this
once)),
>>>>>>>>> but I
>>>>>>>>> find it easier simply to map 'ant compile-gwt-dev&&
ant
>>>>>>>>> dist-server'
>>>>>>>>>
>>>>>>>>> to an alias in my shell instead.
>>>>>>>>>
>>>>>>>>> On 2 February 2012 14:41, Thomas
>>>>>>>>> Leonard<tal@it-innovation.**soton.ac.uk<tal@it-innovation.soton.ac.uk>
>>>>>>>>> >
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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/**
>>>>>>>>>> ae8d59c5725a74bcf0fc2ae08ae569**4abca02a7f<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<tal@it-innovation.**soton.ac.uk<tal@it-innovation.soton.ac.uk>
>>>>>>>>>>> >
>>>>>>>>>>> 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<ali@lown.me.uk>
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<ali@lown.me.uk>
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<ali@lown.me.uk> 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<vjrj@ourproject.org>
>>>>>>>>>>>>>>>> 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:tal@it-innovation.**soton.ac.uk<tal@it-innovation.soton.ac.uk>
>>>>>>>>>>>> http://www.it-innovation.**soton.ac.uk/<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:tal@it-innovation.**soton.ac.uk<tal@it-innovation.soton.ac.uk>
>>>>>>>>>> http://www.it-innovation.**soton.ac.uk/<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:tal@it-innovation.**soton.ac.uk<tal@it-innovation.soton.ac.uk>
>>>>>>> http://www.it-innovation.**soton.ac.uk/<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:tal@it-innovation.**soton.ac.uk <tal@it-innovation.soton.ac.uk>
>>>>> http://www.it-innovation.**soton.ac.uk/<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:tal@it-innovation.**soton.ac.uk <tal@it-innovation.soton.ac.uk>
> http://www.it-innovation.**soton.ac.uk/<http://www.it-innovation.soton.ac.uk/>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message