> Okay, so basically what's happening is that we depend upon OpenSSL to
tell
> us
> when the data it got from the client resembles an HTTP request rather
than
> an
> SSL handshake. The test looks like this:
> if ((n = SSL_accept(filter->pssl)) <= 0) {
> ...
> if (ERR_GET_REASON(ERR_peek_error()) ==
SSL_R_HTTP_REQUEST) {
> return HTTP_BAD_REQUEST;
> }
> ...
> }
> There's no distinction in there of whether it detected an 0.9 or an
1.x
> request, just that it wasn't SSL and it kinda looked like HTTP. The
above
> condition triggers a hardcoded magic request
>
> GET /mod_ssl:error:HTTP-request HTTP/1.0
>
> to be sent back up the input filter chain, which is obviously broken
if
> the
> original request was in fact 0.9. So somehow we either need to get
> OpenSSL to
> give us back more information (like perhaps a copy of the data it
errored
> out
> on) or we need to stash a copy of that data before OpenSSL processes
it.
> Either way could be potentially messy... I'm not sure of the
> implementation
> details yet.
Cliff,
This bug is actually nastier than it looks on first glance. Think
through what happens if you have "RewriteRule .* http://foo.com"; in your
config file when you send a non-SSL request to an SSL socket. What
actually happens, is that you will get the http://foo.com request sent.
The reason is that mod_ssl is faking a request to the core server, and
the core server is re-writing that faked request.
Whatever you do to solve this, you need to ensure that if mod_ssl
detects this error case, it doesn't make it look like a real request to
the core server.
Ryan
