[squid-users] Detecting invalid CONNECT requests

From: HAND,Nathan <Nathan.HAND@dont-contact.us>
Date: Thu, 23 Feb 2006 20:40:44 +1100 (EST)

Hi,

I have a question about CONNECT statements. Squid doesn't try to
interpret the contents of CONNECT statements - how could it, when the
contents are encrypted? - and some applications are abusing that fact by
using CONNECT statements to tunnel non-SSL protocols. The biggest
offender is Skype which uses CONNECT to get a connection to a peer, but
doesn't bother with TLS or SSL on that connection.

I've seen the tutorial on using Squid ACLs to block Skype by matching
CONNECT <ipaddr> and dropping those requests. That's fine. However I was
wondering if it is possible for Squid to be more generic and block all
CONNECT requests that don't look like a TLS or SSL connection. Although
Squid can't view the encrypted contents it should be possible to detect
a valid TLS session being setup (eg, the negotiation and key exchange).

It would be really nice if I could write something similar to

  acl TLS_proto proto TLS
  acl SSL_ports port 443 563
  acl CONNECT method CONNECT
  http_access deny CONNECT !SSL_ports
  http_access deny CONNECT !TLS_proto

I can't find anything like this with a quick Google search but I'm
hoping more knowledgeable people can point me towards a suitable patch
or module.

Thanks,
Nathan Hand

NB: Somebody suggested I could achieve something similar with an
auth_helper that attempted an openssl s_client and looked for a
certificate, but I think that would open an undesirable second
connection for every HTTPS request.

Notice:
The information contained in this e-mail message and any attached files may
be confidential information, and may also be the subject of legal
professional privilege. If you are not the intended recipient any use,
disclosure or copying of this e-mail is unauthorised. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete all copies of this transmission together with any attachments.
Received on Thu Feb 23 2006 - 02:40:45 MST

This archive was generated by hypermail pre-2.1.9 : Wed Mar 01 2006 - 12:00:03 MST