httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
Date Wed, 07 Oct 2015 15:53:03 GMT

> On Oct 7, 2015, at 5:17 AM, Graham Leggett <minfrin@sharp.fm> wrote:
> 
> On 07 Oct 2015, at 10:04 AM, Joe Orton <jorton@redhat.com> wrote:
> 
>> That's really interesting.  That extra buffering BIO makes sense if 
>> OpenSSL is writing to the socket descriptor directly, as with pre-2.x 
>> mod_ssl, but doesn't really make sense with 2.x mod_ssl, since the core 
>> output filter is doing that work in the "right" place.
>> 
>> I guess it doesn't impact performance much because it's handshake-time 
>> only as you say, but still, it would be interesting to try ripping that 
>> out.
> 
> 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.
Mime
View raw message