Subject: Support for proxy server

From: "glpk xypron" <[email-masked]>
Date: Fri, 21 Sep 2012 08:03:30 +0200

Package: x2goclient
Version: V.3.99.2.2 (Qt - 4.8.1)
Severity: wishlist

I would like to use x2goclient from behind a firewall without having to setup a tunnel with an external tool.

My ssh server is running on port 443. The http method CONNECT can be used to create the connection over the firewall.

Please, add proxy support to the x2goclient.

Best regards

Heinrich Schuchardt

---

From: Mike Gabriel <[email-masked]>
Date: Fri, 21 Sep 2012 09:37:51 +0200

Hi Heinrich,

On Fr 21 Sep 2012 08:03:30 CEST glpk xypron wrote:

> My ssh server is running on port 443. The http method CONNECT can be  
> used to create the connection over the firewall.
>

You may want to test PyHoca-GUI. It has SSH tunneling support  
built-in. You can SSH through an SSH tunnel to a server behind a  
firewall. Only thing needed is a machine (on the gate) that allows SSH  
hopping.

I suspect, though, you mean something differen.

What external tool do you use for setting up your tunnel. Please  
specify on that. Do you go over a squid proxy? Including such a  
feature into x2goclient (esp. for the X2Go plugin) will be a wanted  
feature.

If you have, please provide you concept in detail and post it to

   [email-masked]

Thanks,
Mike

-- 

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: [email-masked], http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

---

From: "glpk xypron" <[email-masked]>
Date: Fri, 21 Sep 2012 14:20:19 +0200

Dear Mike,

what I would like to have is that like in putty I can enter the proxy server, the port, my proxy user, and my proxy password. The x2goclient will create a SSH connection.

As long as x2go does not support this scenario. I have to log onto my server using putty. With putty I log onto port 443 of my server and create a tunnel between port 443 on my laptop to port 443 of my server. The I use the x2goclient to connect to my laptop port 443.

Best regards

Heinrich

-------- Original-Nachricht --------
> Datum: Fri, 21 Sep 2012 09:37:51 +0200
> Von: Mike Gabriel <[email-masked]>
> An: glpk xypron <[email-masked]>, [email-masked]
> Betreff: Re: [X2Go-Dev] Bug#34: Support for proxy server

---

From: Stefan Baur <[email-masked]>
Date: Fri, 21 Sep 2012 14:47:45 +0200

More info for the devs:

http://en.wikipedia.org/wiki/Tunneling_protocol - section "Tunneling to 
circumvent firewall policy", second paragraph.

-Stefan

---

From: Mike Gabriel <[email-masked]>
Date: Fri, 21 Sep 2012 14:48:09 +0200

Hi Heinrich,

On Fr 21 Sep 2012 14:20:19 CEST glpk xypron wrote:

> Dear Mike,
>
> what I would like to have is that like in putty I can enter the  
> proxy server, the port, my proxy user, and my proxy password. The  
> x2goclient will create a SSH connection.
>
> As long as x2go does not support this scenario. I have to log onto  
> my server using putty. With putty I log onto port 443 of my server  
> and create a tunnel between port 443 on my laptop to port 443 of my  
> server. The I use the x2goclient to connect to my laptop port 443.

Ok, we will investigate what putty is doing and maybe it is quite easy  
to immitate that. I am still not sure what there is behind that  
technologically.

Please take a look at the SSH proxy feature in PyHoca-GUI and check if  
that meets your requirements.

Do not expect such a feature to be there by tomorrow. It is on the  
wishlist, though.

Mike

-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Reinhard Tartler <[email-masked]>
Date: Fri, 21 Sep 2012 15:07:39 +0200

> circumvent firewall policy", second paragraph.

Sounds pretty much what corkscrew does:
http://www.mtu.net/~engstrom/ssh-proxy.php

AFAIUI the bug submitter wants this functionality built into x2goclient.

-- 
regards,
    Reinhard

---

From: Xypron <[email-masked]>
Date: Fri, 21 Sep 2012 22:00:49 +0200

Hello Mike,

that meets your requirements.
PyHoca-GUI seems to have nothing to do with my wish.

to immitate that. I am still not sure what there is behind that
technologically.
See http://www.ietf.org/rfc/rfc2616.txt for the CONNECT command in http
and how to deal with proxy servers.

Best regards

Heinrich

---

From: Xypron <[email-masked]>
Date: Sat, 22 Sep 2012 13:23:05 +0200

The relevant RFC describing tunneling of HTTP is in
http://www.ietf.org/rfc/rfc2817.txt
Chapter 5.2 Requesting a Tunnel with CONNECT

---

From: Xypron <[email-masked]>
Date: Sun, 23 Sep 2012 22:20:32 +0200

I managed to adjust the GUI and to open a socket through the firewall
with the SSH header arriving from the server.

The socket can be passed to the SSH session with
ssh_options_set( my_ssh_session, SSH_OPTIONS_FD, &proxysocket);

This about where I am stuck, because it is unclear to me how to signal
to the libssl library (in sshmasterconnection.cpp) that the socket is
already connected.

The changed coding is available at
http://www.xypron.de/viewvc/svn/x2go/x2goclient/branches/proxy/
svn co http://www.xypron.de/svn/x2go/x2goclient/branches/proxy/

Best regards

Heinrich

---

From: "glpk xypron" <[email-masked]>
Date: Mon, 24 Sep 2012 15:26:02 +0200

I raised the follwing issue to the libssh list:
http://www.libssh.org/archive/libssh/2012-09/0000033.html

Regards

Heinrich

> Hey.
> 
> On 2012-09-23 22:15, Xypron wrote:
> I'm afraid at this point Alex needs to support you.
> 
> >
> Hmm, no git? ;)
> Morty

---

From: Xypron <[email-masked]>
Date: Mon, 24 Sep 2012 23:22:38 +0200

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

---

From: Oleksandr Shneyder <[email-masked]>
Date: Tue, 25 Sep 2012 01:17:56 +0200

> only be shown if a proxy is used and a login provided.

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:  [email-masked]
web: www.obviously-nice.de

--> X2go - everywhere@home

---

From: "glpk xypron" <[email-masked]>
Date: Tue, 25 Sep 2012 05:08:19 +0200

Dear Oleksandr,

> distributions like squeeze. Such distributions should be also supported
I have sent a bug report to Debian to include the missing patch.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688700

> code of HttpBrockerClient class in X2Go Client, which can use HTTPS

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

---

From: Mike Gabriel <[email-masked]>
Date: Tue, 25 Sep 2012 10:12:16 +0200

Hi Alex, hi Heinrich,

> 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)

> code of HttpBrockerClient class in X2Go Client, which can use HTTPS

HTTP should not be available... only HTTPS.

> distributions like squeeze. Such distributions should be also supported

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

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Mike Gabriel <[email-masked]>
Date: Tue, 25 Sep 2012 10:14:43 +0200

Hi Guys,

On Di 25 Sep 2012 05:08:19 CEST glpk xypron wrote:

> 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

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Mike Gabriel <[email-masked]>
Date: Tue, 25 Sep 2012 10:25:25 +0200

Hi,

> 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

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Oleksandr Shneyder <[email-masked]>
Date: Tue, 25 Sep 2012 10:47:08 +0200

Am 25.09.2012 10:25, schrieb Mike Gabriel:
> 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...

> 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

---

From: Moritz Struebe <[email-masked]>
Date: Tue, 25 Sep 2012 11:01:19 +0200

On 2012-09-25 10:47, Oleksandr Shneyder wrote:
>  Sure, it is a

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 : [email-masked]
WWW   : http://www4.informatik.uni-erlangen.de/~morty

---

From: Oleksandr Shneyder <[email-masked]>
Date: Tue, 25 Sep 2012 11:13:16 +0200

>> over Internet. But I don't even give them a possibility to make such
Sorry, here should be "I don't want to give" instead of "I don't give"

> 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.

Alex
-- 
Oleksandr Shneyder
Dipl. Informatik
X2go Core Developer Team

---

From: Mike Gabriel <[email-masked]>
Date: Tue, 25 Sep 2012 11:21:23 +0200

hi Alex,

> 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

GnuPG Key ID 0x25771B31

freeBusy:

---

From: "glpk xypron" <[email-masked]>
Date: Tue, 25 Sep 2012 15:08:08 +0200

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

---

From: "glpk xypron" <[email-masked]>
Date: Tue, 25 Sep 2012 15:10:58 +0200

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
> CC: Oleksandr Shneyder <[email-masked]>
> Betreff: Re: [X2Go-Dev] Bug#34: SSH_OPTIONS_FD

---

From: Oleksandr Shneyder <[email-masked]>
Date: Tue, 25 Sep 2012 15:14:32 +0200

> 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 ?

-- 
Oleksandr Shneyder
Dipl. Informatik
X2go Core Developer Team

---

From: Moritz Struebe <[email-masked]>
Date: Tue, 25 Sep 2012 16:22:50 +0200

> 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_connection

Tel   : +49 9131 85-25419
Fax   : +49 9131 85-28732

---

From: "John A. Sullivan III" <[email-masked]>
Date: Tue, 25 Sep 2012 10:40:49 -0400

> data as used on other servers.
<snip>
I very much agree with Alex here.  Although we can absolve ourselves of
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