On Thursday 06 March 2003 23.26, Christoph Haas wrote: > I am sure that this 'feature' is well-known and there already a > common-understanding of how to deal with it. Proxy users can use > the squid to tunnel their SSH sessions any destination they like - > at least if the port is allowed for the 'CONNECT' method.
This is well known, and the reason to why the default Squid configuration only allows CONNECT to port 443 (https) and 563 (snews) which is the only two SSL services browsers normally use.. > So much for the theory. Now how do 'normal administrators' handle > this obvious security hole? I think that a handful of hackers at > our company know quite well that we use Squid and will set up an > ssh daemon on their home PC answering connection requests on port > 443. You can always use IDS tools like snort and the like to detect such strange traffic patterns. But you won't be able to detect anyone using tunneling other traffic over SSL without doign a man-in-the-middle approach where all SSL is decrypted by the proxy. Note: the man-in-the-middle approach makes it impossible for users to use private client side SSL certificates without entrusting the proxy as certificate store.. > Or shall I buy an expensive commercial third-party proxy which > is capable of doing a kind of > 'man-in-the-middle-SSL-understanding-proxy' to filter out non-HTTP > requests? If you like this you should in my eye consider investigating having the feature added to Squid. It is not very much missing from Squid to be able to provide such https proxy functionality. If you want a generic decrypting SSL proxy not actually restricted to https then Squid is probably not the correct tool for the job however. Regards Henrik
