On Thu, Jun 17, 2010 at 12:56 AM, jean-frederic clere <jfcl...@gmail.com>wrote:
> On 06/16/2010 07:44 PM, Costin Manolache wrote: > > On Tue, Jun 15, 2010 at 11:14 PM, jean-frederic clere <jfcl...@gmail.com > >wrote: > > > >> On 06/16/2010 07:08 AM, Mladen Turk wrote: > >>> On 06/16/2010 12:34 AM, Costin Manolache wro te: > >>>> Hi, > >>>> > >>>> There are some methods in SSLContext to create and use a new BIO. Are > >>>> there > >>>> any examples/tests for this ? I can't find how to attach the BIO to a > >>>> socket, it seems SSL_set_bio is never called, can't figure what > >>>> SSLContext.setBIO() does. > >>>> > >>> > >>> I'd suggest you forget about those ;) > >>> > >>> SSL BIO allows to write a java code that will SSL use > >>> for read/write to the sockets. > >>> Jean-Frederic created those but cannot tell for what reason. > >> > >> The idea was to use java socket directly to have just the crypto layer > >> done by SSL but tc-native went another way. > >> > > > > > > I know - it allows one to use OpenSSL like SSLEngine - without doing the > > network > > IO trough OpenSSL. > > > > I'm not worried about the 4-5 extra JNI calls - we're talking about slow > > encryption here. > > > > For tomcat-lite - JSSE is a dead end, there is no way to support SPDY and > a > > lot of other > > things are bad/missing ( i.e. most SSL extensions - hostname, session > > tickets, etc ). > > However I want to separate the I/O from the encryption. > > May be we should just start another native module so that we don't need > to use APR but only OpenSSL. > > What do you mean by 'native module' ? I hope not another .so - it's hard enough to deal with this one. Build, install, documentations, deb/rpm, etc. If you mean a separate directory - or just a set of files - that provide only JNI for OpenSSL, without dependencies to APR, or with minimal deps - I think it's a great idea. OpenSSL has its own portability layer, so it doesn't really need APR - but there is no harm in having both in the same library. The purpose of tc-native (IMHO) is to allow access to native libraries that provide better implementation than the Java one, or provide things that are not available in java. I think the original plan was to have it as a very thin layer - exposing as closely as possible the native library, up to pointers and alloc/free. But short term - either remove BIO if it's broken ( no point on having it if it can't be used), or better we should fix it and add a test. It's sad that tcnative, now a separate module, is only used and documented as a helper for the connectors and not as a general purpose utility people can use in their own code. Costin > Cheers > > Jean-Frederic > > > > > > > > > > >> > >>> Probably to allow direct java.sockets via SSL by writing > >>> custom wrapper for SSL Bio (really cannot figure out > >>> why would one wish to go trough 4 JNI callback layers for > >>> making a write, but it's there). > >>> Like you said it wasn't tested, and I was trying to > >>> axe this stuff from version 0.1, but it still hangs there. > >>> > >>> Why would you need that? > >> > >> If not needed we should remove it. > >> > > > > Well, I think it would be needed - if it would work. > > Tomcat-native can be used for more than the tomcat connector - especially > > since it's now > > easy to install on linux ( apt-get install :-). > > > > I would guess adding just the SSL_set_bio() would be enough - assuming > the > > rest of the > > BIO impl is ok. > > > > Do you have any test code you used when implementing this ? I think > adding > > the missing pieces > > may be better than trowing it away. > > > > Costin > > > > > >> Cheers > >> > >> Jean-Frederic > >> > >>> > >>> > >>> Regards > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > >
