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/.
See also bug 3998.
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.
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.
(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.
(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
Dupe of bug 4070?
*** Bug 4070 has been marked as a duplicate of this bug. ***
Should be done now, but bug 4993 is preventing me from proper testing. Will fix that and then make sure everything works here.
Tested on a fresh Fedora 20. Works nicely.
*** Bug 3998 has been marked as a duplicate of this bug. ***
Tested using build 4289, works as expected.
*** Bug 5022 has been marked as a duplicate of this bug. ***
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 -
(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.
(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
(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..
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.
(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.
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>
(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.
Reviewed and tested commit r28730 which works as expected. Reviewed commit r28750 looks good.
umask issues, see bug 4826.
(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).
(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.
