httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: [Bug 9488] - HTTP/0.9 requests spoken on https port returns HTTP/1.0 response
Date Mon, 03 Jun 2002 21:49:29 GMT
> 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



Mime
View raw message