RE: Some SSL stuff.

[Christian Hopp]

On Thu, 14 Nov 2002, Jan-Henrik Haukeland wrote:

(...)
> > And it still works!
>
> Yahoo!

Google! (-:


> > > Now I also want to feather bed the ssl connection into a BIO, too.
> >
> > That would need a complete rewrite of the SSL engine and the
> > surrounding socket engine. They would have conceptional differences.
> > And that's a lot.
>
> Yeah, I can imagine. Don't do it, you have put a lot of work into it
> and besides, it works. I plan to use BIO all the way in my zervlet
> implementation of SSL and can kick back some code if you really want
> to go for the BIO abstraction. Unfortunately, I haven't yet started
> on the SSL implementation for zervlets. I have had to focus on
> getting the engine ready with HTTP and implementing the Servlet
> spec.

I can tell you... you should really do!  Sketch you SSL engine
detailedly before you implement it.  As soon as you get deeper in the
SSL stuff (and every second thing is you peek in the openssl source
code) things get tough.  I have thrown around so much code (and I have
read a big file of foreign code for it)... DON'T DO THAT, TOO!!!

I mean monit's SSL stuff works great but I think I would do some stuff
differently if I would have to do it from scratch again.

> > Isn't it possible to surround the accept stage in the same kind of
> > timeout frame like it is used in validate.c or would they collide?
>
> If you're thinking about using alarm() it would probably collide,
> because alarm is process wide and the alarm signal could be emitted
> from within two different threads you could start the wrong alarm
> handler or suspend the monit process in a state it shouldn't be
> suspended. In fact previous versions (<=3.0) of the processor.c used
> alarm and I observed collision on more than one occasion. Not often,
> but it did happen.

See below... we don't need it any more!!!! (-:

> > Anyways, it seems to me we have make the underlying socket
> > non-blocking in order to make the ssl connection non-blocking.  That
> > means we need to do a
> >   fcntl(s, F_SETFL, O_NONBLOCK)
> > with our network socket.
>
> It should be non-blocking before you call SSL_accept() and blocking
> afterwards.  Have you tried something as simple as:
>
>  set_noblock(socket);
>  SSL_accept(socket);
>  set_block(socket);
>
> This is the most important call to not have blocking, other stuff like
> read/write in the SSL lib are probably using select() to avoid blocking (I
> would guess).

I don't know if you have browsed to my new read-write code.  The ssl
sockets are non-blocking to their end.  It works great!  SSL has nice
features to switch to non-blocking sockets.  And they do even better
then before!

Christian


-- 
Christian Hopp                                email: address@hidden
Institut für Elektrische Informationstechnik             fon: +49-5323-72-2113
TU Clausthal, Leibnizstr. 28, 38678 Clausthal-Zellerf.   fax: +49-5323-72-3197
                             pgpkey: https://www.iei.tu-clausthal.de/pgp-keys/