[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SSh Tunnel Over Squid

On Fri, 2005-05-13 at 15:08 +0200, Pablo Navas wrote:
> I have a GW that gives access to uncontrolled users by means of a proxy 
> SQUID that supports protocols HTTP and HTTPS. Beside this and the DHCPD 
> the rest is closed strictly.
> My question is: Have you ever had this problem? How did you solve it? Is 
> there an effective way to detect and deny SSH tunnels on HTTPS?

I don't think there's any possible solution that a sufficiently skilled
user couldn't bypass in your case.

For example, if you block ssh with CONNECT by using a filter, the user
could set up an https+cgi to ssh gateway on a remote machine. The only
unencrypted traffic would be the https handshake, the ip address of the
remote machine, the ip and mac of the local machine. Except for the
handshake, all of it can be changed by the user, and the handshake would
show no info that you could block (except maybe the client and/or server
certs, which could be changed anyway).

In a much stricter example, let's say you disable https or actively
maintain a block list of ips, macs, and certs. It's no longer feasible
for the user to use ssh over https, but there's still a way s/he could
get access to ssh.

The remote machine runs a mail server that will deliver mail to
ssh@hostname to a program that will decode the message and feed it to an
ssh server with a very long timeout. Extensions are used to keep track
of connections, host, return email user, and return email domain (i.e.
ssh+host=conid=user=webmail.tld@hostname). The program sends mail to the
specified return address with ssh responses.

The local machine runs a program that handles ssh connections over mail
by parsing the html of a webmail program.

This method would be very slow and take a long time to code, but I think
would work. If you decide to block the emails by filtering a signature,
the programs could be modified to mathematically encrypt (encrypted
message looks like random data and only has a pattern once it's
decrypted) the messages. The user could easily switch from one mail
provider to another, including ones that use https.

Once you allow encryption, there's not much to stop the user.

The attachment "signature.asc" (if it exists) is a digital signature.
Unless you know what that is, you can completely ignore it. It is mostly
harmless and very small.

Fri May 20 20:41:11 UTC 2005

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: