You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2002/06/03 23:03:47 UTC
DO NOT REPLY [Bug 9488] -
HTTP/0.9 requests spoken on https port returns HTTP/1.0 response
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9488>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9488
HTTP/0.9 requests spoken on https port returns HTTP/1.0 response
jwoolley@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
OS/Version|Windows XP |All
Platform|PC |All
Summary|Simple "GET" requests (http |HTTP/0.9 requests spoken on
|0.9) Behave incorrectly |https port returns HTTP/1.0
| |response
Version|2.0.36 |HEAD
------- Additional Comments From jwoolley@apache.org 2002-06-03 21:03 -------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
RE: [Bug 9488] - HTTP/0.9 requests spoken on https port returns HTTP/1.0 response
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Ben Laurie [mailto:ben@algroup.co.uk]
>
> Ryan Bloom wrote:
> >>From: Ben Laurie [mailto:ben@algroup.co.uk]
> >>
> >>Cliff Woolley wrote:
> >>
> >>>On Mon, 3 Jun 2002, Ryan Bloom wrote:
> >>>
> >>>
> >>>
> >>>>I was actually just about to look at this problem if you are busy.
> >>>
> >>>
> >>>Go for it... I'm working on something else.
> >>
> >>Perhaps its just me, but I'm amused this is considered a bug.
> >
> >
> > It's a security hole IMO. The problem is that if you rewrite the
URL
> > .*, then the error URL that mod_ssl will be rewritten. This means
that
> > you can serve information over HTTP that was supposed to be
restricted
> > to HTTPS.
>
> Sorry, I don't understand this - seems like you missed a word or two
out?
Sorry, here is a real example:
RedirectMatch ^/([^/]+)?$ index.html
Now, assume that this is specified for an SSL protected virtual host, so
the only way to access this page should be through SSL. But, now I make
an HTTP request over the SSL port. The way mod_ssl used to handle this
case (fixed last night), was to fake a request that started with
/mod_ssl:error... The handler would then see that URI, and send an
error page back. The problem is that in the translate_name phase,
mod_alias redirected /mod_ssl:error to index.html. Then, in the handler
phase, we successfully served that page.
The only good thing is that the ONLY page you can view is the one that
you redirected to, but that is still a bad thing. Anyway, this was
solved last night by removing all of the special /mod_ssl: URIs.
Ryan
Re: [Bug 9488] - HTTP/0.9 requests spoken on https port returns
HTTP/1.0 response
Posted by Ben Laurie <be...@algroup.co.uk>.
Ryan Bloom wrote:
>>From: Ben Laurie [mailto:ben@algroup.co.uk]
>>
>>Cliff Woolley wrote:
>>
>>>On Mon, 3 Jun 2002, Ryan Bloom wrote:
>>>
>>>
>>>
>>>>I was actually just about to look at this problem if you are busy.
>>>
>>>
>>>Go for it... I'm working on something else.
>>
>>Perhaps its just me, but I'm amused this is considered a bug.
>
>
> It's a security hole IMO. The problem is that if you rewrite the URL
> .*, then the error URL that mod_ssl will be rewritten. This means that
> you can serve information over HTTP that was supposed to be restricted
> to HTTPS.
Sorry, I don't understand this - seems like you missed a word or two out?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
RE: [Bug 9488] - HTTP/0.9 requests spoken on https port returns HTTP/1.0 response
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Ben Laurie [mailto:ben@algroup.co.uk]
>
> Cliff Woolley wrote:
> > On Mon, 3 Jun 2002, Ryan Bloom wrote:
> >
> >
> >>I was actually just about to look at this problem if you are busy.
> >
> >
> > Go for it... I'm working on something else.
>
> Perhaps its just me, but I'm amused this is considered a bug.
It's a security hole IMO. The problem is that if you rewrite the URL
.*, then the error URL that mod_ssl will be rewritten. This means that
you can serve information over HTTP that was supposed to be restricted
to HTTPS.
Ryan
Re: [Bug 9488] - HTTP/0.9 requests spoken on https port returns
HTTP/1.0 response
Posted by Ben Laurie <be...@algroup.co.uk>.
Cliff Woolley wrote:
> On Mon, 3 Jun 2002, Ryan Bloom wrote:
>
>
>>I was actually just about to look at this problem if you are busy.
>
>
> Go for it... I'm working on something else.
Perhaps its just me, but I'm amused this is considered a bug.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
RE: [Bug 9488] - HTTP/0.9 requests spoken on https port returns
HTTP/1.0 response
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 3 Jun 2002, Ryan Bloom wrote:
> I was actually just about to look at this problem if you are busy.
Go for it... I'm working on something else.
Thanks.
RE: [Bug 9488] - HTTP/0.9 requests spoken on https port returns HTTP/1.0 response
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Cliff Woolley [mailto:jwoolley@virginia.edu]
>
> On Mon, 3 Jun 2002, Ryan Bloom wrote:
>
> > 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
> ..
> > 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.
>
> Yeah, I think we've actually had a PR where that happened to someone.
We
> need a better way to send the notification of error down than this
> "/mod_ssl:error:HTTP-request" thingy.
>
> Thanks for mentioning this.
I was actually just about to look at this problem if you are busy.
Ryan
RE: [Bug 9488] - HTTP/0.9 requests spoken on https port returns
HTTP/1.0 response
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 3 Jun 2002, Ryan Bloom wrote:
> 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
..
> 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.
Yeah, I think we've actually had a PR where that happened to someone. We
need a better way to send the notification of error down than this
"/mod_ssl:error:HTTP-request" thingy.
Thanks for mentioning this.
--Cliff
RE: [Bug 9488] - HTTP/0.9 requests spoken on https port returns HTTP/1.0 response
Posted by Ryan Bloom <rb...@covalent.net>.
> 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