Excellent. Thanks a lot for the help. Really appreciate it. Jeewantha
On Thu, Feb 28, 2013 at 6:02 PM, Oleg Kalnichevski <[email protected]> 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 <[email protected]> > 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 <[email protected] > > > > > 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: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
