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