Re: [gnet-dev] [PATCH] SSL

["David A. Helder" <dhelder gizmolabs org>]

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