Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 31684 invoked from network); 29 Nov 2005 01:55:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 29 Nov 2005 01:55:29 -0000 Received: (qmail 39709 invoked by uid 500); 29 Nov 2005 01:55:28 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 39478 invoked by uid 500); 29 Nov 2005 01:55:26 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 39467 invoked by uid 99); 29 Nov 2005 01:55:26 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Nov 2005 17:55:26 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 64.233.184.198 as permitted sender) Received: from [64.233.184.198] (HELO wproxy.gmail.com) (64.233.184.198) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Nov 2005 17:56:56 -0800 Received: by wproxy.gmail.com with SMTP id 68so1936663wri for ; Mon, 28 Nov 2005 17:55:05 -0800 (PST) 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:references; b=U0vN0aq5snMTPSjWV1hLmAxfw+8wn3BFT4SPgD9U+xysRGB2Z0s3oevwuecLTZz6vgh5lqIKmLrGf+5YIJ9pO2Qj/nKdIEk/ffGFIu3Yzw7ZEMpZW/I/DJxR5svwGvsMbVwdMsMEHWSg/p56IAeNsGnjS6VeL7kAe+HfcqOpqrI= Received: by 10.54.153.18 with SMTP id a18mr321018wre; Mon, 28 Nov 2005 17:53:24 -0800 (PST) Received: by 10.54.127.2 with HTTP; Mon, 28 Nov 2005 17:55:03 -0800 (PST) Message-ID: <768dcb2e0511281755l26576d35s@mail.gmail.com> Date: Tue, 29 Nov 2005 10:55:03 +0900 From: Trustin Lee To: Apache Directory Developers List Subject: Re: [mina] SSLFilter fires SESSION_SECURED twice In-Reply-To: <438B9D6D.9040105@poczta.onet.pl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_43151_31185894.1133229303232" References: <438B9D6D.9040105@poczta.onet.pl> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_43151_31185894.1133229303232 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Janusz, Thank you for your report. I've just checked in the fix. Now it should fire the event only once. HTH, Trustin 2005/11/29, Janusz Nykiel : > > I am currently developing a simple instant messaging application (client > and server AND a webapp, but the role of the webapp is irrelevant to the > topic). It's basically a toy project. Yesterday I checked out and built > the latest 0.9 MINA. Looking at the SumUp example, I managed to code a > simple message-based protocol. > > I want the communication to be encrypted. I want clients to authenticate > with client certificates. I created sample certificates, key- and > truststores for the server and an example client, added properly > configured SSLFilters to filter chains and it worked. The problem is, I > also want to authorize the clients with their certificates (i.e. > retrieve user ID corresponding to the certificate, without having to > embed the user ID in, for example, the certificate subject DN field). > > The peer (client) certificate chain is stored in a SSLSession object. By > the time the sessionOpened method of the IoHandler is called, the > SSLSession does not yet exist. The SSLFilter can fire the > SESSION_SECURED/SESSION_UNSECURED special messages, so it's possible to > perform the authorization in the messageReceived method. I set the > SSLFilter.USE_NOTIFICATION attribute in sessionCreated. Every time, the > SESSION_SECURED message is fired twice by the SSLFilter, consecutively, > with very similar stack traces. The SSLSession retrieved with > sslFilter.getSSLSession(session) - where sslFilter is an instance of the > filter and session is the IoSession passed to messageReceived - is the > same for both messages. Technically, you can live with that, but either > I'm missing something important, or it's a bug :) I checked whether it > has to to with client authentication being enabled but no, with server > authentication only the problem still occurs. > Relevant source code fragments: > > Server main: > > SSLContext ctx =3D prepareServerSslContext(); > SSLFilter filt =3D new SSLFilter(ctx); > filt.setNeedClientAuth(true); > filt.setUseClientMode(false); > reg.getAcceptor(TransportType.SOCKET).getFilterChain().addLast("ssl", > filt); > > Client main: > > IoConnector conn =3D new SocketConnector(); > SSLFilter filt =3D new SSLFilter(prepareClientSslContext()); > filt.setUseClientMode(true); > conn.getFilterChain().addLast("ssl", filt); > > Server SessionHandler sessionCreated: > > session.getFilterChain().addFirst("protocolFilter", > new ProtocolCodecFilter( > new NetworkProtocolCodecFactory())); // it's my class > session.setAttribute(SSLFilter.USE_NOTIFICATION, true); > > Server SessionHandler messageReceived: > > if (message =3D=3D SSLFilter.SESSION_SECURED) { > SSLSession sslSession =3D sslFilter.getSSLSession(session); > ...do some stuff with sslSession.getPeerCertificates() > // this code gets executed twice when it shouldn't > } > else { > ...do the normal protocol communication > } > > I'd greatly appreciate an answer. My source already looks ugly and > having to code around this problem certainly wouldn't help :) > > -- > Janusz Nykiel; cynic@poczta.onet.pl > -- what we call human nature is actually human habit -- http://gleamynode.net/ ------=_Part_43151_31185894.1133229303232 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Janusz,

Thank you for your report.  I've just checked in the= fix.  Now it should fire the event only once.

HTH,
Trustin<= br>
2005/11/29, Janusz Nykiel < cynic@poczta.onet.pl>:
I am currently developing a simple instant messaging app= lication (client
and server AND a webapp, but the role of the webapp is irrelevant to th= e
topic). It's basically a toy project. Yesterday I checked out and buil= t
the latest 0.9 MINA. Looking at the SumUp example, I managed to code a
simple message-based protocol.

I want the communication to be en= crypted. I want clients to authenticate
with client certificates. I crea= ted sample certificates, key- and
truststores for the server and an exam= ple client, added properly
configured SSLFilters to filter chains and it worked. The problem is, I=
also want to authorize the clients with their certificates (i.e.
ret= rieve user ID corresponding to the certificate, without having to
embed = the user ID in, for example, the certificate subject DN field).

The peer (client) certificate chain is stored in a SSLSession objec= t. By
the time the sessionOpened method of the IoHandler is called, the<= br>SSLSession does not yet exist. The SSLFilter can fire the
SESSION_SEC= URED/SESSION_UNSECURED special messages, so it's possible to
perform the authorization in the messageReceived method. I set the
S= SLFilter.USE_NOTIFICATION attribute in sessionCreated. Every time, the
S= ESSION_SECURED message is fired twice by the SSLFilter, consecutively,
with very similar stack traces. The SSLSession retrieved with
sslFilter.= getSSLSession(session) - where sslFilter is an instance of the
filter an= d session is the IoSession passed to messageReceived - is the
same for b= oth messages. Technically, you can live with that, but either
I'm missing something important, or it's a bug :) I checked whether it<= br>has to to with client authentication being enabled but no, with serverauthentication only the problem still occurs.
Relevant source code fra= gments:

Server main:

SSLContext ctx =3D prepareServerSslContext();SSLFilter filt =3D new SSLFilter(ctx);
filt.setNeedClientAuth(true);filt.setUseClientMode(false);
reg.getAcceptor(TransportType.SOCKET).ge= tFilterChain().addLast("ssl", filt);

Client main:

IoConnector conn =3D new SocketConnector();
= SSLFilter filt =3D new SSLFilter(prepareClientSslContext());
filt.setUse= ClientMode(true);
conn.getFilterChain().addLast("ssl", filt);<= br>
Server SessionHandler sessionCreated:

session.getFilterChain().a= ddFirst("protocolFilter",
      =   new ProtocolCodecFilter(
      = ;          new NetworkPro= tocolCodecFactory())); // it's my class
session.setAttribute(SSLFilter.USE_NOTIFICATION, true);

Server Sessi= onHandler messageReceived:

if (message =3D=3D SSLFilter.SESSION_SECU= RED) {
        SSLSession sslSes= sion =3D sslFilter.getSSLSession(session);
        ...do some stuff with s= slSession.getPeerCertificates()
      &nbs= p; // this code gets executed twice when it shouldn't
}
else {        ...do the normal protocol= communication
}

I'd greatly appreciate an answer. My source alre= ady looks ugly and
having to code around this problem certainly wouldn't help :)

--=
Janusz Nykiel; cynic@poczta.one= t.pl



--
what we cal= l human nature is actually human habit
--
http://gleamynode.net/ ------=_Part_43151_31185894.1133229303232--