#2948 Intermittent SSL redirect

[Mike]

There seems to be an issue where MiniServ does not comply with rfc1945 regarding the expected LF and Content-Type:

$ echo -e 'HEAD / HTTP/1.0' | nc 127.0.0.1 11635 &&
> echo -e 'HEAD / HTTP/1.0' | nc 127.0.0.1 80 &&
> echo -e 'HEAD / HTTP/1.0\n' | nc 127.0.0.1 80
HTTP/1.0 302 Moved Temporarily
Date: Wed, 31 Oct 2007 02:48:20 GMT
Server: MiniServ/0.01
Location: https://192.168.1.227:11635/
Connection: close

HTTP/1.1 400 Bad Request
Date: Wed, 31 Oct 2007 02:48:20 GMT
Server: Apache/2.0.52 (Red Hat)
Connection: close
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 302 Found
Date: Wed, 31 Oct 2007 02:48:20 GMT
Server: Apache/2.0.52 (Red Hat)
Location: http://127.0.0.1
Connection: close
Content-Type: text/html; charset=iso-8859-1

As shown in the first example, webmin gave an unexpected response prior to receiving the \n.

The second example shows that a 400 Bad Request should have been generated.

The third example shows that the Content-Type should be declared after the 302.

This causes intermittent functionality in browsers connecting without SSL if ssl_redirect=1

Let me know if more detail would be of use.

[Jamie Cameron]

Logged In: YES
user_id=129364
Originator: NO

The problem here is that when Webmin receives a connection in the wrong mode (ie. non-SSL when SSL is expected), it doesn't have access to the original HTTP request, as it has already been lost to the openssl library. So even if that request is totally invalid, it will still send back the same 302 response.

Could you explain further how this is causing problems for some browsers? Is the lack of a Content-type: the issue?

[Mike]

Logged In: YES
user_id=1925928
Originator: YES

Hello,

Thanks for investigating. I see what you mean regarding the unencrypted request hitting the SSL engine. Basically, in my testing there is a high probability that the redirect will cause a browser to generate an error. I think that what is happening is that when the request is made, the response arrives before the browser is ready to perform the redirect, ie the 'Connection: close' arrives just as the browser is ready to receive a response. If you refresh the page several times, the 302 will eventually function as if this is a race condition.

In IE on windows, you get the following:
"IE Cannot Display the Page"

In Firefox on linux, you get the following:
"The connection to the server was reset while the page was loading."

During my testing today, I was only able to reach the bug twice out of about twenty refreshes. It almost seems like omitting the trailing / makes the bug more likely to occur.
~mg

[Mike]

Logged In: YES
user_id=1925928
Originator: YES

I failed to mention that a 1 second delay prior to sending the 302 may resolve the issue entirely.
~mg

[Jamie Cameron]

Logged In: YES
user_id=129364
Originator: NO

You could test this 1-second delay theory by editing the file miniserv.pl under the Webmin root directory (usually /usr/libexec/webmin or /usr/share/webmin) and at line 1072 adding :

sleep(1);

Then restarting Webmin.

[Mike]

Logged In: YES
user_id=1925928
Originator: YES

Thanks for your time, it seems that I can no longer reproduce the bug even without the patch. Perhaps there was something else going on. Either way, you might consider the following:

--- webmin/miniserv.pl.bug1823225 2007-11-02 17:00:32.000000000 -0500
+++ webmin/miniserv.pl 2007-11-02 17:02:23.000000000 -0500
@@ -1069,13 +1069,11 @@
"https://$host:$port/";
if ($config{'ssl_redirect'}) {
# Just re-direct to the correct URL
- sleep(0.5);
- &write_data("HTTP/1.0 302 Found\r\n");
+ &write_data("HTTP/1.0 302 Moved Temporarily\r\n");
&write_data("Date: $datestr\r\n");
&write_data("Server: $config{'server'}\r\n");
&write_data("Location: $url\r\n");
&write_keep_alive(0);
- &write_data("Content-Type: text/html; charset=iso-8859-1\r\n");
&write_data("\r\n");
return 0;
}

[Jamie Cameron]

Logged In: YES
user_id=129364
Originator: NO

Thanks .. since this can't be re-produced, I will close this bug.

[Mike]

Logged In: YES
user_id=1925928
Originator: YES

Thanks for your time, it seems that I can no longer reproduce the bug even without the patch. Perhaps there was something else going on. Either way, you might consider the following:

--- webmin/miniserv.pl.bug1823225 2007-11-02 17:00:32.000000000 -0500
+++ webmin/miniserv.pl 2007-11-02 17:02:23.000000000 -0500
@@ -1069,13 +1069,11 @@
"https://$host:$port/";
if ($config{'ssl_redirect'}) {
# Just re-direct to the correct URL
- sleep(0.5);
- &write_data("HTTP/1.0 302 Found\r\n");
+ &write_data("HTTP/1.0 302 Moved Temporarily\r\n");
&write_data("Date: $datestr\r\n");
&write_data("Server: $config{'server'}\r\n");
&write_data("Location: $url\r\n");
&write_keep_alive(0);
- &write_data("Content-Type: text/html; charset=iso-8859-1\r\n");
&write_data("\r\n");
return 0;
}