Re: UPDATE: [wcolburn () nmt edu: SMTP relay through checkpoint firewall]

[Mike Benham <moxie () thoughtcrime org>]

People use the CONNECT method from inside a LAN to make SSL/HTTPS
connections through a proxy.  I think it makes sense for proxies to
support the method by default, since browsing secure pages is very
common, but it shouldn't be accessable from outside the LAN.

- Mike

--
http://www.thoughtcrime.org

On Tue, 19 Feb 2002, Steve VanDevender wrote:

> It's not just Checkpoint Firewall that has a problem with HTTP CONNECT.
> From what I can tell default installations of the CacheFlow web proxy
> software, some Squid installations, some Apache installations with
> proxying enabled, and some other web proxy installations I haven't
> identified allow anyone to use the HTTP CONNECT method.  This is being
> used more and more often to relay spam.  This is a boon for spammers
> because unlike open SMTP relays which usually record some kind of useful
> Received: header, open web proxies don't put any information in the mail
> headers about the real origin of the spam.
>
> For those of you unfamiliar with the details of this problem, unsecured
> web proxies allow a remote user to use the HTTP connect method to make
> arbitrary TCP connections to a specified host and port, like this:
>
> $ telnet open.web.proxy.org 80 # or 8080, or maybe other ports
> Trying 192.168.1.1...
> Connected to 192.168.1.1.
> Escape character is '^]'.
> CONNECT victim.host.org:25 HTTP/1.0
>
> HTTP/1.0 200 Connection established
>
> 220 victim.host.org ESMTP Sendmail 8.11.6/8.11.6; Tue, 19 Feb 2002 14:16:51 -0800 (PST)
>
> I went around with someone at CacheFlow about this after unsecured
> proxies in the cacheflow.com domain were used to relay spam, and after
> seeing spam come from various unsecured CacheFlow proxies around the
> Internet.  Their position is that this is supposed to be prevented by
> putting the CacheFlow server behind a firewall, or using configuration
> options in the CacheFlow software to prevent connections to unwanted
> destination ports.  They seemed unreceptive to the idea of shipping a
> CacheFlow configuration that did not allow CONNECT by default.