> On Oct 7, 2015, at 11:59 AM, 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.
> 

Ah, I see now...

Digging into it a bit, I think your suspicion is correct, but I
can't find it.

Reply via email to