Can't access SIAB behind a reverse-proxy

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Launch SIAB as usual (daemon listening on port 4200)
2. Try to connect through a reverse proxy. Let's suppose that our web 
server listens on the default port, and that we have set up a reverse 
proxy so that /login gets redirected to the IP where SIAB is running. So 
for example we point a browser to http://myhost.com/login.
3. Apparently, the request goes through the reverse proxy, reaches SIAB 
and then fails when SIAB upgrades the session to SSL/TLS (the URL changes 
to http://myhost.com:4200/login, which won't work unless you open that 
port)

What is the expected output? What do you see instead?

The expected behaviour would be getting redirected to the SSL/TLS session 
using the same port as the initial request.

What version of the product are you using? On what operating system?

2.9 (r149) on a fresh Lenny install - Linux version 2.6.26-2-686 (Debian 
2.6.26-17)

Please provide any additional information below.

Reverse proxy is handled by lighttpd, which listens on port 80 on another 
system. 

I've also tried using the --localhost-only option (which the man page 
suggests), but the result was the same (the only visible change was that 
SIAB started listening on the loopback interface only).

I'm not quite sure if this issue is related with the way shellinabox sends 
HTTP headers when establishing the SSL/TLS session or if it happens 
because i haven't set up the reverse proxy properly. If it's because of 
the latter, please disregard this report.

Original issue reported on code.google.com by alejandr...@gmail.com on 27 Jul 2009 at 2:17

[GoogleCodeExporter]

I guess that a possible solution would be using the -p option to make SIAB 
listen on 
the same port number used by the web server. 

But unfortunately, this approach would only work if the web server and SIAB are 
running on different systems, which isn't always possible.

Original comment by alejandr...@gmail.com on 27 Jul 2009 at 2:24

[GoogleCodeExporter]

Additional information:

After running tshark, this is what i got:

<- GET /login HTTP/1.1..Host: myhost.com:8888..User-Agent: Mozilla5.0

-> HTTP/1.1 302 Found..Content-Length: 0..Content-Type: text/html..Location: 
http://
myhost.com:4200/login/

(Note that in this case i was using a web sever listening on 8888 and 
redirecting /
login to localhost:4200)

Original comment by alejandr...@gmail.com on 27 Jul 2009 at 2:40

[GoogleCodeExporter]

If you use a reverse proxy in front of ShellInABox, you have to let the proxy 
do the
encryption. How else would it be able to look into the session and decide where 
the
URL points to? After all, the whole point of encryption is that nobody can look 
at
the traffic -- not even your own proxy.

You then have to tell ShellInABox to run in plain-text mode when talking to the
proxy. That's what the "-t" option is for. And if you use "-t", you probably 
also
want "--localhost-only", so that only your reverse proxy connects directly to 
the
ShellInABox daemon.

Alternatively, you can always open that port on your firewall. It really 
depends on
whether you prefer your proxy or ShellInABox to do the encryption.

Original comment by zod...@gmail.com on 27 Jul 2009 at 3:22

• Changed state: WontFix

[GoogleCodeExporter]

Ok, that's a very good point. You're probably 100% right, and i should have 
thought 
about that before reporting. 

So let's take SSL/TLS sessions out of the equation for a while, and let's run 
SIAB 
with the -t option to disable the encryption completely. After restarting the 
daemon, this is what ps shows:

/usr/bin/shellinaboxd -q --background=/var/run/shellinaboxd.pid -c /var/lib/
shellinabox -p 4200 -u shellinabox -g shellinabox --no-beep -s 
/login:root:root:/:/
bin/login --localhost-only -t

Now, if i go to http://myhost.com/login, the result is the same as before. That 
is, 
the browser gets redirected to http://myhost.com:4200/login, which it can't 
access.

After repeating the experiment and capturing the traffic, this is the reply 
from 
SIAB:

HTTP/1.1 302 Found..Content-Length: 0..Content-Type: text/html..Location: 
http://
myhost.com:4200/login/

From this we can tell that the reverse proxy is indeed working (the incoming 
request 
reached shellinabox on the expected port), and SIAB is replying with a location 
header that points to port 4200.

Anyway, let's take the reverse proxy out of the equation too, and let's try 
with a 
plain and simple port forwarding rule from port 80 to port 4200. After trying 
that 
approach, i get the same result. 

Once again, i might be missing something embarassingly obvious here, and if 
that's 
the case, i sincerely apologize for the inconvenience.

Best regards,
Alex

Original comment by alejandr...@gmail.com on 27 Jul 2009 at 4:23

[GoogleCodeExporter]

I think, I see what you are doing. You have ShellInABox installed on "/login". 
It 
needs to tell the browser that this is a "directory" and there are resources 
underneath it, so it redirects the browser to "/login/". I bet, if you went to 
http://myhost.com/login/ everything would work just fine.

Ideally, you should configure your proxy so that it generates URLs with the 
appropriate number of slashes, when it forwards the request.

Often, it is easier to get this right, if you use the default "-s" line, as 
that 
forces you to think about the appropriate rewriting rules in the proxy 
configuration 
file.

BTW, it is often better to write "-s /:LOGIN" instead of "-s 
/:root:root:/:/bin/login". The "login" daemon has special calling conventions 
and 
ShellInABox knows about that, if you use the magic "LOGIN" keyword.

Original comment by zod...@gmail.com on 27 Jul 2009 at 4:53

[GoogleCodeExporter]

Let me know if the latest version of the code in SVN (rev 152) works better for 
you. I 
moved all the URL redirection code into JavaScript. In principle, this should 
make it 
more robust against subtle configuration problems with reverse proxies.

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

• Changed state: Fixed

[GoogleCodeExporter]

Hi, i've just installed r152 and i can confirm that:

- It's working fine with a reverse proxy handled by lighttpd (running SIAB with 
the -
t option), and now a trailing slash is appended to the URL if it wasn't 
present. 

- It's working fine with a port forwarding rule (for example, 8888 -> 4200), 
with or 
without the -t option (this wasn't working with r149, so i think that the 
latest 
changes solved this issue)

BTW, thanks for the "-s /:LOGIN" tip.

Original comment by alejandr...@gmail.com on 27 Jul 2009 at 7:58