tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: tomcat native - SSL setBIO()
Date Thu, 17 Jun 2010 14:30:49 GMT
On Thu, Jun 17, 2010 at 12:56 AM, jean-frederic clere <jfclere@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 <jfclere@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >
>
>

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