Using libssh compiled from http://git.libssh.org/projects/libssh.git/log/?h=v0-5 I now can successfully connect via a proxy server to a SSH server. My coding is available at svn co http://www.xypron.de/svn/x2go/x2goclient/branches/proxy/
The changes in sshmasterconnection.* and connectionwidget.* are complete to my understanding. In onmainwindow I have only treated one of three entrypoints to sshmasterconnection. E.g. LDAP is not proxy enabled yet. In onmainwindow the proxy password field I introduced possibly should only be shown if a proxy is used and a login provided.
Best regards
Heinrich
Am 24.09.2012 23:22, schrieb Xypron:
Using libssh compiled from http://git.libssh.org/projects/libssh.git/log/?h=v0-5 I now can successfully connect via a proxy server to a SSH server. My coding is available at svn co http://www.xypron.de/svn/x2go/x2goclient/branches/proxy/
The changes in sshmasterconnection.* and connectionwidget.* are complete to my understanding. In onmainwindow I have only treated one of three entrypoints to sshmasterconnection. E.g. LDAP is not proxy enabled yet. In onmainwindow the proxy password field I introduced possibly should only be shown if a proxy is used and a login provided.
Best regards
Heinrich
Hello Heinrich,
I've checked your code and it looks good for me. I'll include it in master branch soon. You have developed support for HTTP proxy. I'm working now on a little more complex case - SSH proxy with password/public key authentication. In the future user should be able to choose between HTTP and SSH proxy. I have a one notice. In your case HTTP protocol is used for proxy. It is mean, that user name and password will be transmitted unencrypted. It can follow to security issues. Can you think about HTTPS support? This should be not very difficult, as Qt already supports SSL. You can check code of HttpBrockerClient class in X2Go Client, which can use HTTPS connections.
And one more thing, as I understood, this code work only with recent version of libssh. We should think, how can we make it available for distributions like squeeze. Such distributions should be also supported by X2Go Client.
regards, Alex
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Dear Oleksandr,
And one more thing, as I understood, this code work only with recent version of libssh. We should think, how can we make it available for distributions like squeeze. Such distributions should be also supported by X2Go Client. I have sent a bug report to Debian to include the missing patch. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688700
I have a one notice. In your case HTTP protocol is used for proxy. It is mean, that user name and password will be transmitted unencrypted. It can follow to security issues. Can you think about HTTPS support? This should be not very difficult, as Qt already supports SSL. You can check code of HttpBrockerClient class in X2Go Client, which can use HTTPS connections.
QNetworkProxy relies on QAuthenticator.
QAuthenticator supports the following authentication methods:
- Basic
- NTLM version 2
- Digest-MD5
Which one is used depends on the setup of the proxy server. Squid has plugin for NTLM.
NTLM and Digest-MD5 should be acceptable inside a private network.
After the connection is established all further traffic will be SSH encrypted.
I am not aware of proxies being contacted over https.
An interesting feature might be QNetworkProxy::DefaultProxy which can use the system settings to determine the proxy server.
Best regards
Heinrich Schuchardt
Hi Guys,
On Di 25 Sep 2012 05:08:19 CEST glpk xypron wrote:
Dear Oleksandr,
And one more thing, as I understood, this code work only with recent version of libssh. We should think, how can we make it available for distributions like squeeze. Such distributions should be also supported by X2Go Client. I have sent a bug report to Debian to include the missing patch. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688700
I have a one notice. In your case HTTP protocol is used for proxy. It is mean, that user name and password will be transmitted unencrypted. It can follow to security issues. Can you think about HTTPS support? This should be not very difficult, as Qt already supports SSL. You can check code of HttpBrockerClient class in X2Go Client, which can use HTTPS connections.
QNetworkProxy relies on QAuthenticator.
QAuthenticator supports the following authentication methods:
- Basic
- NTLM version 2
- Digest-MD5
Which one is used depends on the setup of the proxy server. Squid
has plugin for NTLM.NTLM and Digest-MD5 should be acceptable inside a private network.
After the connection is established all further traffic will be SSH
encrypted.I am not aware of proxies being contacted over https.
An interesting feature might be QNetworkProxy::DefaultProxy which
can use the system settings to determine the proxy server.Best regards
Heinrich Schuchardt
Can you think of a way to utilize WPAD for proxy detection. Many
systems I know use the WPAD protocol to roll out proxy settings over
the network:
http://de.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol
Just in case Qt knows about it...
Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi,
On Di 25 Sep 2012 05:08:19 CEST glpk xypron wrote:
I am not aware of proxies being contacted over https.
Hmmm... this indeed is true... The feature will mostly be an
inside-to-outside connection. Hmmm... To get it clear, would we send
http-proxy authentication strings in cleartext to the proxy server or
would we send the remote X2Go server credentials to the proxy in
cleartext.
Sending proxy auth in cleartext probably is common practice (?). Most
proxy setups do not even need an auth-against-the-proxy.
This feature clearly needs a good documentation so that we do not
false security alarms on the mailing lists!!!
Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On 2012-09-25 10:25, Mike Gabriel wrote:
On Di 25 Sep 2012 05:08:19 CEST glpk xypron wrote:
I am not aware of proxies being contacted over https.
Hmmm... this indeed is true... The feature will mostly be an inside-to-outside connection. Hmmm... To get it clear, would we send http-proxy authentication strings in cleartext to the proxy server or would we send the remote X2Go server credentials to the proxy in cleartext.
Client ---http & Basic Auth---> proxy (Basic Auth) -> New Socket Using this new socket: Client ---SSL ---- Socket at Proxy ---Still same SSL---> Server
This we first authenticate unencrypted at the proxy using the proxy user/pass. Then the SSL connection is made to the server and we authenticate against the server.
Sending proxy auth in cleartext probably is common practice (?). Most proxy setups do not even need an auth-against-the-proxy.
Yep, but some do.
This feature clearly needs a good documentation so that we do not false security alarms on the mailing lists!!!
Nay, I think this is a matter of the gui that must clearly suggest, that this user/password is for the proxy.
/--- Proxy-----------------------
| Enable:
| Address :
| User (optinal):
| Password (optional):
\-------------------------------/
Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Am 25.09.2012 10:25, schrieb Mike Gabriel:
Hi,
On Di 25 Sep 2012 05:08:19 CEST glpk xypron wrote:
I am not aware of proxies being contacted over https.
Hmmm... this indeed is true... The feature will mostly be an inside-to-outside connection. Hmmm... To get it clear, would we send http-proxy authentication strings in cleartext to the proxy server or would we send the remote X2Go server credentials to the proxy in cleartext.
only proxy server authentication is in clear text. However, many setups have the same authentication for proxy-users as for system-users. Often such authentication is performed over central LDAP-Server. Sure, it is a fail of system administrator, if he allow such unecrypted authentication over Internet. But I don't even give them a possibility to make such mistake...
Sending proxy auth in cleartext probably is common practice (?). Most proxy setups do not even need an auth-against-the-proxy.
This feature clearly needs a good documentation so that we do not false security alarms on the mailing lists!!!
Mike
Alex
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
On 2012-09-25 10:47, Oleksandr Shneyder wrote:
Sure, it is a fail of system administrator, if he allow such unecrypted authentication over Internet. But I don't even give them a possibility to make such mistake...
I don't really get your point. The credentials are used by the browser anyway - because otherwise there would be no need for a proxy. I don't think it's our job to disable features because of incompetent system administrators. After all proxy authentication is normally used within LANs.
Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Am 25.09.2012 11:01, schrieb Moritz Struebe:
On 2012-09-25 10:47, Oleksandr Shneyder wrote:
Sure, it is a fail of system administrator, if he allow such unecrypted authentication over Internet. But I don't even give them a possibility to make such mistake... Sorry, here should be "I don't want to give" instead of "I don't give"
I don't really get your point. The credentials are used by the browser anyway - because otherwise there would be no need for a proxy. I don't think it's our job to disable features because of incompetent system administrators. After all proxy authentication is normally used within LANs.
I don't want to disable any features. I only say, it is nice to have a possibility to send authentication data to server encrypted. In LAN it is not a such big problem to send it in clear text. But in case of SSH-Proxy it is an Internet connection. And I want, that every one, who use this feature with X2Go know, that sending unecrypted data over Internet is not safe. And that should not be the same authentication data as used on other servers.
Morty
Alex
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
hi Alex,
On Di 25 Sep 2012 11:13:16 CEST Oleksandr Shneyder wrote:
I don't want to disable any features. I only say, it is nice to have a possibility to send authentication data to server encrypted. In LAN it is not a such big problem to send it in clear text. But in case of SSH-Proxy it is an Internet connection. And I want, that every one, who use this feature with X2Go know, that sending unecrypted data over Internet is not safe. And that should not be the same authentication data as used on other servers.
With SSH proxy support you normally do _not_ send passwords unencrypted.
Manual SSH proxy tunnel:
ssh -l<proxy-user> <proxy-host> -L
127.0.0.1:<some-local-port>:<ip-or-host-behind-proxy>:<ssh-port-on-remote-host>
and then an X2Go session to
Hostname: 127.0.0.1 Port: <some-local-port> User: <ssh-user-on-remote-host>
Both SSH authentications do not reveal clear text credentials. So, I
am wondering what your SSH proxy strategy will be(?).
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Am 25.09.2012 11:21, schrieb Mike Gabriel:
hi Alex,
On Di 25 Sep 2012 11:13:16 CEST Oleksandr Shneyder wrote:
I don't want to disable any features. I only say, it is nice to have a possibility to send authentication data to server encrypted. In LAN it is not a such big problem to send it in clear text. But in case of SSH-Proxy it is an Internet connection. And I want, that every one, who use this feature with X2Go know, that sending unecrypted data over Internet is not safe. And that should not be the same authentication data as used on other servers.
With SSH proxy support you normally do _not_ send passwords unencrypted.
Manual SSH proxy tunnel: ssh -l<proxy-user> <proxy-host> -L 127.0.0.1:<some-local-port>:<ip-or-host-behind-proxy>:<ssh-port-on-remote-host>
and then an X2Go session to
Hostname: 127.0.0.1 Port: <some-local-port> User: <ssh-user-on-remote-host>
Both SSH authentications do not reveal clear text credentials. So, I am wondering what your SSH proxy strategy will be(?).
I mean SSH over HTTP Proxy with authentication on Proxy-Server with clear text. There is no security problem in case you described.
Greets, Mike
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Am 25.09.2012 11:01, schrieb Moritz Struebe:
On 2012-09-25 10:47, Oleksandr Shneyder wrote:
Sure, it is a fail of system administrator, if he allow such unecrypted authentication over Internet. But I don't even give them a possibility to make such mistake... Sorry, here should be "I don't want to give" instead of "I don't give"
I don't really get your point. The credentials are used by the browser anyway - because otherwise there would be no need for a proxy. I don't think it's our job to disable features because of incompetent system administrators. After all proxy authentication is normally used within LANs.
I don't want to disable any features. I only say, it is nice to have a possibility to send authentication data to server encrypted. In LAN it is not a such big problem to send it in clear text. But in case of SSH-Proxy it is an Internet connection. And I want, that every one, who use this feature with X2Go know, that sending unecrypted data over Internet is not safe. And that should not be the same authentication data as used on other servers. <snip> I very much agree with Alex here. Although we can absolve ourselves of
On Tue, 2012-09-25 at 11:13 +0200, Oleksandr Shneyder wrote: the responsibility, it is wiser to do as much as we can to prevent both admins and users from shooting themselves the stupid things they may do. For example, it is not just a matter of a sloppy admin not realizing they should use a separate authentication domain for the proxy; even if they do, we have the social engineering problem of users using the same password for the proxy as for anything else. Once one intercepts that password, a cracker will try it everywhere they can for that user. Thus, I would strongly advocate all authentication even to the proxy be protected by encryption. Thanks - John
Hello Mike,
in enterprise settings it is good practice to require authentication at the proxy to be able to be able log which user is doing what.
Best regards
Heinrich
-------- Original-Nachricht --------
Datum: Tue, 25 Sep 2012 10:25:25 +0200 Von: Mike Gabriel <mike.gabriel@das-netzwerkteam.de> An: glpk xypron <xypron.glpk@gmx.de>, 34@bugs.x2go.org CC: Oleksandr Shneyder <oleksandr.shneyder@obviously-nice.de> Betreff: Re: [X2Go-Dev] Bug#34: SSH_OPTIONS_FD
Hi,
On Di 25 Sep 2012 05:08:19 CEST glpk xypron wrote:
I am not aware of proxies being contacted over https.
Hmmm... this indeed is true... The feature will mostly be an
inside-to-outside connection. Hmmm... To get it clear, would we send
http-proxy authentication strings in cleartext to the proxy server or
would we send the remote X2Go server credentials to the proxy in
cleartext.Sending proxy auth in cleartext probably is common practice (?). Most
proxy setups do not even need an auth-against-the-proxy.This feature clearly needs a good documentation so that we do not
false security alarms on the mailing lists!!!Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On 2012-09-25 05:08, glpk xypron wrote:
And one more thing, as I understood, this code work only with recent
version of libssh. We should think, how can we make it available for distributions like squeeze. Such distributions should be also supported by X2Go Client. I have sent a bug report to Debian to include the missing patch. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688700
I just had a discussion with RT. As far as I understand the situation, the simplest option would be to provide a patched libssh version via the x2go repository and wait for the next libssh release. Thus allowing those users that want to use a proxy to install that package manually.
Cheers Morty
P.s.: What's our policy on discussing bugs? Should it be done via the bug or via the ML and only the results filed to the bug?
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Hi Alex, hi Heinrich,
On Di 25 Sep 2012 01:17:56 CEST Oleksandr Shneyder wrote:
Am 24.09.2012 23:22, schrieb Xypron:
Using libssh compiled from http://git.libssh.org/projects/libssh.git/log/?h=v0-5 I now can successfully connect via a proxy server to a SSH server. My coding is available at svn co http://www.xypron.de/svn/x2go/x2goclient/branches/proxy/
The changes in sshmasterconnection.* and connectionwidget.* are complete to my understanding. In onmainwindow I have only treated one of three entrypoints to sshmasterconnection. E.g. LDAP is not proxy enabled yet. In onmainwindow the proxy password field I introduced possibly should only be shown if a proxy is used and a login provided.
Best regards
Heinrich
Hello Heinrich,
I've checked your code and it looks good for me. I'll include it in master branch soon. You have developed support for HTTP proxy. I'm working now on a little more complex case - SSH proxy with password/public key authentication. In the future user should be able to choose between HTTP and SSH proxy.
Alex, I would be very pleased if you could reuse the sshproxy options
available in PyHoca-GUI:
usesshproxy (Bool)
sshproxyuser (String)
sshproxykeyfile (Pathname)
sshproxyhost = (String, Host:Port) (example: myhost.somedomain.tld:32032)
sshproxytunnel (String) (example:
127.0.0.1:22234:<ip-or-host-behind-proxy>:22)
I have a one notice. In your case HTTP protocol is used for proxy. It is mean, that user name and password will be transmitted unencrypted. It can follow to security issues. Can you think about HTTPS support? This should be not very difficult, as Qt already supports SSL. You can check code of HttpBrockerClient class in X2Go Client, which can use HTTPS connections.
HTTP should not be available... only HTTPS.
And one more thing, as I understood, this code work only with recent version of libssh. We should think, how can we make it available for distributions like squeeze. Such distributions should be also supported by X2Go Client.
Let me know what the minimum of a version of libssh is that you need.
I will see that our Debian and Ubuntu archives have the needed version
available (unless the distro itself has the proper version).
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On 2012-09-25 10:12, Mike Gabriel wrote:
It can follow to security issues. Can you think about HTTPS support? This should be not very difficult, as Qt already supports SSL. You can check code of HttpBrockerClient class in X2Go Client, which can use HTTPS connections.
HTTP should not be available... only HTTPS.
As Heinrich already noted there are no HTTPS proxies around....
And one more thing, as I understood, this code work only with recent version of libssh. We should think, how can we make it available for distributions like squeeze. Such distributions should be also supported by X2Go Client.
Let me know what the minimum of a version of libssh is that you need. I will see that our Debian and Ubuntu archives have the needed version available (unless the distro itself has the proper version).
0.5.2 is the latest release and it's buggy. (See also the the other mail I send in a sec)
Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
On Tue, Sep 25, 2012 at 10:22 AM, Moritz Struebe <Moritz.Struebe@informatik.uni-erlangen.de> wrote:
On 2012-09-25 10:12, Mike Gabriel wrote:
It can follow to security issues. Can you think about HTTPS support? This should be not very difficult, as Qt already supports SSL. You can check code of HttpBrockerClient class in X2Go Client, which can use HTTPS connections.
HTTP should not be available... only HTTPS.
As Heinrich already noted there are no HTTPS proxies around....
Have a look at http://wiki.squid-cache.org/Features/HTTPS, the last paragraphs.
-- regards, Reinhard
Hello Mike
HTTP should not be available... only HTTPS. The proxy server defines how to communicate. There is not choice between HTTP and HTTPS.
After the connection to the proxy server is established all other communication in SSH.
Whether passwords can be communicated in encrypted form depends on the proxy server.
Best regards
Heinrich Schuchardt
Am 25.09.2012 15:08, schrieb glpk xypron:
Hello Mike
HTTP should not be available... only HTTPS. The proxy server defines how to communicate. There is not choice between HTTP and HTTPS.
Okay, now I got it. Have you already tested this feature with proxy server configured for HTTPS ?
After the connection to the proxy server is established all other communication in SSH.
Whether passwords can be communicated in encrypted form depends on the proxy server.
Best regards
Heinrich Schuchardt
-- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
On 2012-09-25 15:14, Oleksandr Shneyder wrote:
Okay, now I got it. Have you already tested this feature with proxy server configured for HTTPS ?
I don't think this worth investigating. See RT's link[1]: "Unfortunately, popular modern browsers do not permit configuration of TLS/SSL encrypted proxy connections. " and "The Chrome browser is able to connect to proxies over SSL connections if configured to use one in a PAC file or command line switch. GUI configuration appears not to be possible (yet)." as well as "[Firefox:] There are bugs open for many years against this browser"
Thus, if it's not supported by any browser it's very unlikely an admin will set up a _HTTP_ proxy using SSL.
Cheers Morty
[1] http://wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connectio...
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
-
glpk xypron -
John A. Sullivan III -
Mike Gabriel -
Moritz Struebe -
Oleksandr Shneyder -
Reinhard Tartler -
Xypron