> -----Ursprüngliche Nachricht----- > Von: Graham Leggett [mailto:[email protected]] > Gesendet: Mittwoch, 7. Oktober 2015 17:59 > An: [email protected] > Betreff: Re: svn commit: r1706275 - > /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c > > On 07 Oct 2015, at 5:53 PM, Jim Jagielski <[email protected]> wrote: > > >> As I understand we’re using openssl in non blocking mode, which means > that openssl will ask us permission before attempting any read or write. > >> > >> The core will then in turn either read or write as requested by > openssl based on the “sense” flags CONN_SENSE_WANT_READ or > CONN_SENSE_WANT_WRITE. > >> > >> If openssl has a bug and reads/writes without first asking permission > we’ll block, but by the same token if openssl as asking us permission > using SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE and we’re ignoring > openssl, we’ll block for the same reason. > > > > But certainly these are situations which it's "safer" to block > > in any case, right? Of course, they could also be vectors for some > > sort of DDoS, but even then, that would be relying on pretty > > nasty bugs. > > The blocking isn’t really the problem, it’s accidentally waiting for a > socket to be readable when openssl asked you to tell it when the socket > is writable. > > I suspect turning on the “flush” is masking a bug.
I guess we are talking of different things. During the initial handshake (client or server) we never hand back control to the event part of the MPM. We never use ssl_filter_write and ssl_io_filter_output as this is only used for data we want to encrypt on the connection. During the handshake we deal directly with the core output filter. We are just synchronous here. And I think this is not a big deal as the amount of data that needs to be transferred here is low and buffered by the socket buffer anyway. So we would not really notice the difference between synchronous and asynchronous since the socket is not blocking / says its writable. Regards Rüdiger
