Re: [gnet-dev] [PATCH] SSL
- From: "David A. Helder" <dhelder gizmolabs org>
- To: Szalai Ferenc <szferi angel elte hu>
- Cc: gnet-dev gnetlibrary org
- Subject: Re: [gnet-dev] [PATCH] SSL
- Date: Mon, 08 Sep 2003 20:39:46 -0400
On Mon, 2003-09-08 at 15:05, Szalai Ferenc wrote:
> > Both the SSL context and session are stored in the Option struct, so
> > maybe caching is still possible. What exactly is OpenSSL caching
> > anyway?
> Ok. The ssl session saching mechanizm is used for reduce the session creation cost
> in OpenSSL. With this an allocated set of sessions can reused. See
> Apache-SSL :)
If caching can be done transparently, then do it. Otherwise, I don't
think it's worth adding another step. If people want to write a super
high performance server, they'll probably not use GNet anyway.
> > The point adding SSL support vs. adding OpenSSL support. Using GNet SSL
> > shouldn't require understanding OpenSSL, only SSL.
> Thats right! But there are some special "feature" on OpenSSL like CRL
> handling which makes hard the transparent implementation.
What's CRL handling? Is it necessary?
> > If you get a non secure context, the function should fail because the
> > whole point was to get a secure context. Or, this should be
> > configurable (with not-secure=failure by default).
> I have never try it but I think It will be a clear behavior if you must
> specify at least CA certificate verification locations other case the
> context initaializatin get failure.
Ok, then require that. It's better to make the API too strict in the
first version.
> > Yes, so I'm wondering if tcp->iochannel should be the GSSLIOChannel or
> > not.
> I think the anware is no. Because the the glib's io channel handling
> mechanizm only work well if the tcp->iochannel is GIOChannel. We should
> solve our problems in other way.
But GSSLIOChannel is derived from GIOChannel so should work seamlessly
as a GIOChannel.
> > I could add a set_io_channel to GTcpSocket. Or change the
> > io_channel constructor so the GTcpSocket is passed, like this:
> >
> > gnet_ssl_io_channel_new_connect(GTcpSocket* tcp_socket, options)
> I think the last one is better.
>
> > Will OpenSSL only work on TCP socket descriptors? If so, this would be
> > better API.
> There isn't any problem with other socket type like UNIX or UDP. I think
> if we finish the design of TCP socket any other will easy to implement.
Ok, then we'll do gnet_ssl_io_channel_new_connect(GTcpSocket*
tcp_socket...)
> Do you have any idea how we can pass the SSLoptions to asycn callbacks
> if we don't want to use default options?
Call gnet_tcp_socket_new_async(). When the user (not GNet) gets the
callback they can call gnet_ssl_io_channel_new_{connect/accept}. The
SSL negotiation might block. Does OpenSSL have non-blocking API
though? We could add a gnet_ssl_io_channel_new_{connect/accept}_async
if we can make the negotiation async.
> Technical question: Do you want make changes on my patch discussed
> above? Or Need I do that?
Yes please.
I think we've agreed on this at least:
gnet_ssl_io_channel_new_connect(GTcpSocket*...
gnet_ssl_io_channel_new_accept(GTcpSocket*...
[in a ssliochannel.[ch]]
These issues are still open:
GSSLOptions vs. GSSLCtx/GSSLSession.
can tcp_socket->iochannel be a GSSLIOChannel?
(i'm leaning towards yes)
I also need:
documentation for the functions (there's only a few now)
examples - you have some. maybe integrate with the non-ssl
examples with an option flag if you think it would
be more readable.
tests - please get client_server_test.pl working with the
ssl echoclient/server. include any necessary certs
if you can write documentation for the module too, that'd be great.
see the HTML documentation on the website for an
example. basically i'm looking for ~ 3 paragraphs covering the
major API.
Thanks,
David
--
David Helder - dhelder gizmolabs org - http://www.gizmolabs.org/~dhelder
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]