www.cendio.com
Bug 4580 - tlstunnel should redirect to requested host; not server IP
: tlstunnel should redirect to requested host; not server IP
Status: CLOSED FIXED
: ThinLinc
Misc
: 4.0.0
: PC Unknown
: P2 Normal
: 4.2.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2013-04-03 13:02 by
Modified: 2014-05-15 14:36 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2013-04-03 13:02:45
Currently, if you visit a tlstunnel protected service such as tlwebadm, ie
connecting to http://eudemo.thinlinc.com:1009, tlstunnel will redirect to the
IP:
https://193.12.253.88:1009/. It would be much better if the redirection was to
https://eudemo.thinlinc.com:1009/.
------- Comment #1 From cendio 2013-04-03 13:03:00 -------
See also bug 3998.
------- Comment #2 From cendio 2013-04-10 11:21:30 -------
Fixing this would require a HTTP implementation in tlstunnel. A better solution
is probably to enable tlstunnel to redirect unencrypted connections as well.
That way a Python implementation could handle the redirection.
------- Comment #3 From cendio 2013-07-25 14:18:26 -------
I wonder if we can use the "Upgrade" HTTP header for switching to TLS, rather
than "Redirect" as tlstunnel currently does. This might mean that the client
re-uses the URL as entered by the user, rather than being redirected to an IP
address. It should also be more efficient, since the existing TCP connection is
being upgraded, rather than creating a new one.

It also makes slightly more sense using Upgrade; there's no "redirection" per
se going on, the URL and even port number remain the same. The only thing
that's changing is the protocol. The question is whether the browser will
update itself to show that the connection is secure.
------- Comment #4 From cendio 2013-07-26 11:15:54 -------
(In reply to comment #3)
> I wonder if we can use the "Upgrade" HTTP header for switching to TLS, rather
> than "Redirect" as tlstunnel currently does.

No browsers actually implement this, so it doesn't seem like an option after
all.
------- Comment #5 From cendio 2013-08-08 10:49:31 -------
(In reply to comment #2)
> Fixing this would require a HTTP implementation in tlstunnel. A better solution
> is probably to enable tlstunnel to redirect unencrypted connections as well.
> That way a Python implementation could handle the redirection.

Ideally we would re-write tlwebadm/tlwebaccess to implement TLS, and get rid of
tlstunnel altogether. However, this means we would need to require Python >=
2.6[1] and the OpenSSL libraries.

RHEL5 is stuck on Python 2.4, so the question is if this platform is still
important to us - Python 2.6 is nearly 5 years old, and RHEL5 is getting pretty
ancient. Re-assigning for discussion.

[1] http://docs.python.org/2/library/ssl.html
------- Comment #6 From cendio 2013-11-29 16:48:17 -------
Dupe of bug 4070?
------- Comment #7 From cendio 2014-02-21 16:15:21 -------
*** Bug 4070 has been marked as a duplicate of this bug. ***
------- Comment #8 From cendio 2014-02-26 12:39:53 -------
Should be done now, but bug 4993 is preventing me from proper testing. Will fix
that and then make sure everything works here.
------- Comment #9 From cendio 2014-02-27 13:39:45 -------
Tested on a fresh Fedora 20. Works nicely.
------- Comment #10 From cendio 2014-02-27 13:39:55 -------
*** Bug 3998 has been marked as a duplicate of this bug. ***
------- Comment #11 From cendio 2014-03-17 13:41:36 -------
Tested using build 4289, works as expected.
------- Comment #12 From cendio 2014-03-18 09:46:09 -------
*** Bug 5022 has been marked as a duplicate of this bug. ***
------- Comment #13 From cendio 2014-03-18 09:47:40 -------
When trying to go to the HTML5 client login page in Internet Explorer 10 on
Windows 7 the following gets printed in the tlwebaccess log and the browser
says that it can't find the page. Works fine against eudemo (4.1.1).

2014-03-18 09:20:40 INFO tlwebaccess[25169]: Connection from ::ffff:10.48.2.23,
port 49688
2014-03-18 09:20:40 ERROR tlwebaccess[25170]: code 400, message Bad request
syntax
('\x16\x03\x03\x00\x9c\x01\x00\x00\x98\x03\x03S(\x01\xdb\xe1$\xcd\x1b\x13M\xe8F30\xae\xca9\x91\x8b\xbf\xed\xf9\xe3YU\xff]\x8c\xfca-\xbf\x00\x00*\x00<\x00/\x00=\x005\x00\x05\x00')
2014-03-18 09:20:40 INFO tlwebaccess[25170]:
"��S(��$M�F30��9������YU�]��a-�*</=5" 400 -
------- Comment #14 From cendio 2014-03-18 13:38:00 -------
(In reply to comment #13)
> When trying to go to the HTML5 client login page in Internet Explorer 10 on
> Windows 7 the following gets printed in the tlwebaccess log and the browser
> says that it can't find the page. Works fine against eudemo (4.1.1).
> 
> 2014-03-18 09:20:40 INFO tlwebaccess[25169]: Connection from ::ffff:10.48.2.23,
> port 49688
> 2014-03-18 09:20:40 ERROR tlwebaccess[25170]: code 400, message Bad request
> syntax
> ('\x16\x03\x03\x00\x9c\x01\x00\x00\x98\x03\x03S(\x01\xdb\xe1$\xcd\x1b\x13M\xe8F30\xae\xca9\x91\x8b\xbf\xed\xf9\xe3YU\xff]\x8c\xfca-\xbf\x00\x00*\x00<\x00/\x00=\x005\x00\x05\x00')
> 2014-03-18 09:20:40 INFO tlwebaccess[25170]:
> "��S(��$M�F30��9������YU�]��a-�*</=5" 400 -

Fixed in r28653.

It did however expose a bug in the logging in that raw data is written straight
into the logs. This could be exploited by putting terminal control sequences in
there.

Unfortunately the bug is in Python code, not ours. But we can override the
relevant method with a fixed one.
------- Comment #15 From cendio 2014-03-18 13:40:26 -------
(In reply to comment #14)
> 
> It did however expose a bug in the logging in that raw data is written straight
> into the logs. This could be exploited by putting terminal control sequences in
> there.
> 
> Unfortunately the bug is in Python code, not ours. But we can override the
> relevant method with a fixed one.

Fixed in r28654.

Tester can use this for testing:

$ cat /dev/urandom | nc dhcp-254-171 300
------- Comment #16 From cendio 2014-03-19 14:00:32 -------
(In reply to comment #15)
> (In reply to comment #14)
> > 
> > It did however expose a bug in the logging in that raw data is written straight
> > into the logs. This could be exploited by putting terminal control sequences in
> > there.
> > 
> > Unfortunately the bug is in Python code, not ours. But we can override the
> > relevant method with a fixed one.
> 
> Fixed in r28654.
> 
> Tester can use this for testing:
> 
> $ cat /dev/urandom | nc dhcp-254-171 300

Tested using build 4293, both netcat and IE10 on win7 works as expected.

Raw data is now escaped when logged..
------- Comment #17 From cendio 2014-03-27 09:41:22 -------
We do not guarantee that the unix sockets are only accessible by us. We should
probably sort that out as part of the new wrapper class.
------- Comment #18 From cendio 2014-03-27 11:30:30 -------
(In reply to comment #17)
> We do not guarantee that the unix sockets are only accessible by us. We should
> probably sort that out as part of the new wrapper class.

Fixed in r28730.
------- Comment #19 From cendio 2014-03-28 11:00:06 -------
Documentation still claims it'll redirect to the IP.

> clientplatforms.xml-1864-  <listitem><para>
> clientplatforms.xml:1865:    It is vital that "https" is specified. Otherwise, the browser
> clientplatforms.xml-1866-    will redirect to the corresponding IP address, which will not
> clientplatforms.xml-1867-    match the certificate.
> clientplatforms.xml-1868-  </para></listitem>
------- Comment #20 From cendio 2014-03-28 11:08:08 -------
(In reply to comment #19)
> Documentation still claims it'll redirect to the IP.
> 
> > clientplatforms.xml-1864-  <listitem><para>
> > clientplatforms.xml:1865:    It is vital that "https" is specified. Otherwise, the browser
> > clientplatforms.xml-1866-    will redirect to the corresponding IP address, which will not
> > clientplatforms.xml-1867-    match the certificate.
> > clientplatforms.xml-1868-  </para></listitem>

r28750.
------- Comment #21 From cendio 2014-04-01 15:45:42 -------
Reviewed and tested commit r28730 which works as expected. Reviewed commit
r28750 looks good.
------- Comment #22 From cendio 2014-05-14 17:07:33 -------
umask issues, see bug 4826.
------- Comment #23 From cendio 2014-05-15 11:02:43 -------
(In reply to comment #22)
> umask issues, see bug 4826.

r28979.

Besides retesting the normal stuff, the tester should make sure things work
with a restrictive umask (e.g. 0077 or 0777). Remember to remove
/var/run/thinlinc, and to verify that tlwebaccess and tlwebadm actually get the
expected umask (need to hack /etc/bashrc on RH systems for example).
------- Comment #24 From cendio 2014-05-15 14:36:10 -------
(In reply to comment #23)
> (In reply to comment #22)
> > umask issues, see bug 4826.
> 
> r28979.
> 
> Besides retesting the normal stuff, the tester should make sure things work
> with a restrictive umask (e.g. 0077 or 0777). Remember to remove
> /var/run/thinlinc, and to verify that tlwebaccess and tlwebadm actually get the
> expected umask (need to hack /etc/bashrc on RH systems for example).


Tested on RHEL 6

- Edited /etc/profiles and added umask 77
- Installed rc2
- Verified that /var/run/thinlinc have wrong permissions; 700
- Verified that a login with native client failed with permission denied in
  tlclient.log.

- Updated installation with rc3
- Deleted /var/run/thinlinc between each restart of services and verified that  
  each service created the directories with correct permissions.
- Verified that i successfully could log into a session.

Also verified that tlwebaccess (pamtester) / tlwebadm (tlstunnel) worked as
expected using the umask 77.