hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prasad Jeewantha <jeewamp....@gmail.com>
Subject Re: How are TrustStores and KeyStores used in SSL in HTTP-core-nio
Date Thu, 28 Feb 2013 08:24:43 GMT
Cool! Thanks a lot for the tip. I understand that *
AbstractMultiworkerIOReactor* runs several dispatchers(*BaseIOReactor)* in
several worker threads and that the dispatcher will be blocked for all
other events till certificate verification is over if not handled
asynchronously. One possible solution IMO is to have another *status2* *=
NOT_OK* variable in *SSLIOSession* class so that its
*isAppOutputReady()*method returns false until the
*status2* variable is set to *OK* by the thread created for certificate
verification. In *SSLClientIOEventDispatch* class
*outputReady(IOSession)*method has
if (sslSession.isAppOutputReady()) {
           conn.produceOutput(this.handler);
}
so the connection will not be used until certificate verification is done.
Please tell me whether this could be a viable solution and whether it will
give any unexpected problems. I really appreciate your comments.
Thanks a lot,
Jeewantha


On Wed, Feb 27, 2013 at 7:31 PM, Oleg Kalnichevski <olegk@apache.org> wrote:

> On Wed, 2013-02-27 at 19:12 +0530, Prasad Jeewantha wrote:
> > Hi Oleg,
> > Thanks for the response. I have one more question. When creating an
> > SSLClientIOEventDispatch(.. , .. , .. ,..) it gets an SSLIOSessionHandler
> > which has a *verify(SocketAddress remoteAddress, SSLSession
> > session)*method. I am planning to add my OCSP/CRL feature here. This
> > method is
> > called by *doHandshake()* method in *SSLIOSession*. My question is, at
> the
> > point where the *verify()* method is called, will the JSSE trust manager
> > already has checked whether at least one certificate in the chain is
> > trusted?
>
> Yes, that is the case. At that point the session will be fully
> established.
>
> > If so I can assume at this point, the entire chain is trusted, so
> > that I can do the OCSP/CRL verification here.
>
> In ideal situation OCSP/CRL check should be performed at the same time
> the trust verification is performed, but this has to be done
> asynchronously without blocking the i/o dispatch thread. I also believe
> JSSE should provide an injection point for OCSP/CRL, but I cannot say
> that for sure. For a start doing the OCSP/CRL check after the session
> has been established should be good enough. Please note the check will
> have to be asynchronous as well or otherwise you would be blocking the
> i/o thread and all the active sessions managed by it. So, you have got
> to know what you are doing.
>
> Oleg
>
> > Thanks again,
> > Jeewantha
> >
> >
> > On Wed, Feb 27, 2013 at 6:06 PM, Oleg Kalnichevski <olegk@apache.org>
> wrote:
> >
> > > On Wed, 2013-02-27 at 17:10 +0530, Prasad Jeewantha wrote:
> > > > Hi all,
> > > > There is an SSL Certificate Verification feature (OCSP/CRL) I want to
> > > > implement in Apache Synapse which uses http-core-nio project as a
> > > > dependency. In Synapse when creating an *SSLContext* it takes *
> > > > truststore.jks* and the *keystore.jks* as arguments. In the class *
> > > > org.apache.http.impl.nio.reactor.SSLIOSession* it creates an
> > > *SSLEngine*from
> > > > *sslContext.createSSLEngine(hostname, port) *method. When debugging
> > > Synapse
> > > > I can see the TrustManagers and KeyManagers in SSLEngine. *Please
> tell me
> > > > how the TrustManagers and KeyManagers are used in http-core-nio
> project*.
> > >
> > > Jeewantha
> > >
> > > HttpCore does not do anything special with regards to trust
> verification
> > > and authentication with a private key. It relies on the standard
> > > mechanisms provided by JSSE.
> > >
> > >
> > > > I want to verify whether the root certificate in the Peer certificate
> > > chain
> > > > is in the TrustStore. I am not sure whether this is already
> implemented.
> > > > Thanks in advance.
> > > > Jeewantha.
> > > >
> > >
> > > Standard JSSE trust manager considers a certificate chain trusted if at
> > > least one cert in the chain is trusted. It does not have to be the root
> > > cert. If you are absolutely sure that you have to verify validity of
> the
> > > root cert, you should implement a custom TrustManager and use it
> instead
> > > of the default implementation.
> > >
> > > Hope this helps
> > >
> > > Oleg
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

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