cannot redirect through a HTTPS proxy

[GoogleCodeExporter]

What steps will reproduce the problem?
1. install shellinabox on a server
2. configure nginx to listen on HTTPS and forward it to shellinabox
3. try and browse to shellinabox via the HTTPS proxy

Result: I get the "Connect" as per if I had logged out.  Attempts to
connect or refresh get quickly bounced back to the "Connect" button.

Is there anything in shellinabox that doesn't play well with HTTPS and
proxies?  Please note I have it running fine through a HTTP proxy (apache).

Build process:
I am using v2.8, running on Debian lenny, AMD64.  I created a package using
the venerable checkinstall, on my builder box, and installed the result on
my proxy box

Re SSL support:
I have the libssl-dev libs installed (config.log tells me it found
openssl-ish stuff) and therefore I assume it's compiled with openssl
support.  But when I run it with "-c" hoping it will create self-signed
certs, the directory remains empty, So not 100% sure.  But I don't think
this matters.  This info included for completeness.

I use a proxy because I have more than one HTTPS-protected web service
exposed on the one public IP.  Apart from certificate jiggery-pokery, nginx
handles this well, other than shellinabox.

I can't dedicate shellinabox to a singular public-facing IP address, but
any other method you can recommend to get this working (in lieu of nginx)
would be great.

Original issue reported on code.google.com by gnute...@gmail.com on 21 Jun 2009 at 1:33

[GoogleCodeExporter]

Good catch. I installed Nginx and noticed that I wasn't getting any responses. 
Turns
out, the version of nginx that was installed by Debian always uses HTTP/1.0 and
"Connection: close" when connecting through "proxy_pass". I haven't checked 
whether
there are any other versions of Nginx that support HTTP/1.1 for outgoing 
connections,
or whether this is a configuration option that I forgot to set.

In general, ShellInABox goes to great lengths to attempt to keep connections 
open, as
that will significantly improve performance. It erroneously assumed that there
weren't any browsers and/or proxies around, that don't know how to parse
"Content-Length".

The newest code in SVN now has a fix that respects "Connection: close". With 
that
change, ShellInABox should work fine when using Nginx as a reverse proxy. There 
is
going to be a small performance penalty for all the connections that get 
constantly
opened and closed, but as this is happening on localhost, the cost won't be as
noticable as when it happens over the WAN. Nonetheless, if you can figure out 
how to
make Nginx speak HTTP/1.1 and keep outgoing connections open, you should see a
performance improvement.

There are a few other non-obvious configuration details:

 1) You either have to tell ShellInABox to not upgrade to SSL (with the "-t" option),
or you have to configure "proxy_pass" to point to the HTTPS URL. Otherwise, 
you'll
end up with an infinite redirection loop. The former is preferable, as you 
otherwise
needlessly waste cycles with encrypting, decrypting, and re-encrypting each bit 
of data.

 2) You either need to tell Nginx to rewrite addresses to point to the root "/" entry
when forwarding the request; or you can add a new service entry with the "-s" 
option,
but then you have to make sure that users always type the URL so that it has a
trailing "/".

Of course, the alternative is that you don't use Nginx at all, and that you 
just host
ShellInABox on a dedicated port. But that has the drawback that some users can 
only
reach servers on port 80, because their outgoing traffic gets filtered.

If this code change did not fix the problem that you were seeing, please file 
another
bug report with detailed instructions on how to reproduce it.

Original comment by zod...@gmail.com on 21 Jun 2009 at 7:09

• Changed state: Fixed

[GoogleCodeExporter]

Thanks, the code worked - mostly. I neglected to remember and mention that from 
nginx
doing HTTPS, I proxy to apache which handles digest authentication (nginx can 
only do
basic auth) and that then proxies to shellinabox.

Using your code from SVN, nginx -> Apache2 -> SIAB doesn't work.  However, 
nginx ->
SIAB does work.  Currently I've turned on basic authentication in nginx, but is 
there
anything I'm missing in my apache2 config that you can think of, that could care
about this connection closing?

Original comment by gnute...@gmail.com on 22 Jun 2009 at 3:38

[GoogleCodeExporter]

For debugging purposes, can you temporarily disable all encryption. Then use
wireshark to log the network traffic. Take a look at the traffic between NGinx 
and
Apache, and the traffic between Apache and ShellInABox. Do you see any 
unexpected
differences?

Original comment by zod...@gmail.com on 22 Jun 2009 at 4:00

• Changed state: Started

[GoogleCodeExporter]

I cannot reproduce this problem. I can successfully proxy through
nginx->Apache2->ShellInABox.

Nginx is configured like this:

server {
        listen   443;
        server_name  localhost;

        ssl  on;
        ssl_certificate  cert.pem;
        ssl_certificate_key  cert.key;

        ssl_session_timeout  5m;
        keepalive_timeout    70;

        ssl_protocols  SSLv2 SSLv3 TLSv1;
        ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
        ssl_prefer_server_ciphers   on;

        location / {
                proxy_pass http://127.0.0.1;
        }
}

Apache 2 is configured like this:

<VirtualHost *:80>
    ProxyRequests Off
    <Proxy *>
      Order deny,allow
      Allow from all
    </Proxy>
    ProxyPass /shell/ http://localhost:4200/
    RedirectMatch permanent /shell$ /shell/
</VirtualHost>

And ShellInABox is configured like this:

SHELLINABOX_DAEMON_START=1
SHELLINABOX_PORT=4200
SHELLINABOX_ARGS=--no-beep
SHELLINABOX_ARGS="${SHELLINABOX_ARGS} -t --localhost-only"

Original comment by zod...@gmail.com on 5 Jul 2009 at 7:50

[GoogleCodeExporter]

Original comment by zod...@gmail.com on 8 Jul 2009 at 5:39

• Changed state: Done

[GoogleCodeExporter]

Revision 152 in the SVN repository changed the way that we redirect URLs. This 
should 
make it easier to configure proxies.

Original comment by zod...@gmail.com on 27 Jul 2009 at 6:32