Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of vinod.p@gmail.com designates
 66.249.82.198 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=fvShbXVlmtbwb2fS4/8srNrxuAnJiq7PVkLbEtdZ4f2Y4M++UZRXYQj8WPkhjynMwJW4UYaJaS4j2RQNa97VLFuyZ3QQs7A/+s4fKBe8WvfcDHXGdNnlI73mfO2wSZnlDW/vCG74RP57RbvNa1ZAwMrWIJYTXsowxLaSTRrzEdk=
Message-ID: <a8f18ca30510310335i258f5cdfxeb8e9d55fdda99c1@mail.gmail.com>
Date: Mon, 31 Oct 2005 17:05:57 +0530
From: Vinod Panicker <vinod.p@gmail.com>
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [mina] SSLFilter race condition: Take #2
In-Reply-To: <768dcb2e0510130614y574acffbx@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <768dcb2e0510120146g52fab08ak@mail.gmail.com>
	 <768dcb2e0510130520q766eb09dg@mail.gmail.com>
	 <1129208559.14855.1.camel@localhost.localdomain>
	 <768dcb2e0510130614y574acffbx@mail.gmail.com>

Sorry I wasn't around to add my 2 bits to this discussion, but I'm
kinda OK with this solution.  Only question is - what will happen if
data is received in the middle of this process?  Will it be given to
the SSLFilter or not?

I'm also of the opinion that a "filter bypass" solution should be
abstracted as a one-time solution to such race conditions.

What I'm doing right now as a workaround to this problem is
implementing my own filter which simply keeps buffering all the
incoming data till the sslfilter is implemented.  After that, I remove
the filter and retrieve all the data.

Regards,
Vinod.

On 10/13/05, Trustin Lee <trustin@gmail.com> wrote:
> 2005/10/13, Julien Vermillard <jvermillard@archean.fr>:
> > Why not :
> >
> > public void messageReceived(IoSession session, Object message) {
> >     if (message instanceof MyStartTLSRequest) {
> >         // insert SSLFilter to start handshaking
> >         session.getFilterChain().addFirst(sslFilter);
> >
> >         // Disable encryption
> >         sslFilter.setEnabled(false); // SSLfilter is bypassing
> >
> >         // write StartTLSResponse
> >         session.write(new MyStartTLSResponse(OK));
> >
> >         // Enable encryption
> >         sslFilter.setEnabled(true); // SSLfilter is crypting
> >     }
> > }
>
> What if a client initiates TLS handshake process before we call
> sslFilter.setEnable(true).  I know this won't happen easily, but it has
> possibility of race condition yet.
>
> I talked with Emmanuel and here's another option:
>
> public void messageReceived(IoSession session, Object message) {
>     if (message instanceof MyStartTLSRequest) {
>         // insert SSLFilter to start handshaking
>         session.getFilterChain().addFirst(sslFilter);
>
>         // Disable encryption temporarilly.  This attribute will be clear=
ed
> after Session.write()
>         session.setAttribute( SSLFilter.DISABLE_ENCRYPTION , Boolean.TRUE=
 );
>
>         // write StartTLSResponse
>         session.write(new MyStartTLSResponse(OK));
>     }
> }
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/