On Wed, Oct 7, 2015 at 5:59 PM, Graham Leggett <[email protected]> wrote: > 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.
Are we talking about this particular commit or more generally about the handling of SSL_ERROR_WANT_READ/WRITE in mod_ssl? In the former case, the "flush" is not masking but addressing a bug in openssl, which does not always flush its (handshake) data where it should... Also, AFAICT, SSL_ERROR_WANT_READ/WRITE can only happen during (re)negotiation, it makes sense here to block rather than scheduling small packet exchanges through the MPM (and maybe let mod_reqtimeout handle any DOS attempt). Regards, Yann.
