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 12:49:54 GMT
Excellent. Thanks a lot for the help. Really appreciate it.
Jeewantha


On Thu, Feb 28, 2013 at 6:02 PM, Oleg Kalnichevski <olegk@apache.org> wrote:

> On Thu, 2013-02-28 at 13:54 +0530, Prasad Jeewantha wrote:
> > 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
> >
>
> This sounds viable. What you need to do is to mark the session as
> 'not-ready' yet, suspend all i/o events on it, start an asynchronous
> certificate verification process (either using a worker thread or
> another i/o reactor). Once the process is completed the worker can
> update the status and resume (or terminate) the session.
>
> Hope this helps
>
> Oleg
>
> >
> > 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
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> 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