Apache content filtering for SSL connections?

Hello everyone,

I've recently written a virus scanning module for apache2 with
mod_proxy, but I'm now facing the next problem: virus scanning of
SSL traffic. The problem with SSL traffic is of course that we
cannot see inside the connection. With the recent flood of mail
based viruses, one of my customers had to close HTTPS access to
all webmail providers.

I believe there is a less drastic solution that would allow to
preform virus scanning nevertheless. However, Google hasn't
shown me a solution, and neither has mod_proxy/mod_ssl. I also
checked recent archives of the mailing lists. This may be
ignorance on my part, I'd be glad to learn that apache already
offers a simple solution.

When the proxy receives a CONNECT request, it is also told to
what host the client would like to connect. So the proxy could
generate a certificate matching that host name on the fly and
negotiate an SSL connection with the browser. Of course, we
would need a small proxy CA with a CA certificate that the
browser should have imported. The user will only notice anything
if she looks at the certificate.

The proxy can then read the request from the browser, which is
not a proxy request, but as we have read the hostname from the
CONNECT, we can synthesize an SSLproxy request: From

CONNECT trusted.server.com:443 HTT/1.0
[ssl handshake]
GET /some/path/file.html HTTP/1.0
Host: trusted.server.com
Accept: ...

construct

GET https://trusted.server.com:443/some/path/file.html HTTP/1.0
Host: trusted.server.com
Accept: ...

Sending this request to an SSL enabled apache2 proxy will return
the data in the clear, maybe virus scanned (preferably using
mod_clamav :-), and we can write it to the browser through the
SSL connection. So we get Https virus scanning.

There are, of course, some details that should be addressed:

1. The temperary certificates should all use the same key, as key
generation is the most expensive operation. And the
certificates should be cached also.

2. Since some sites require client authentication, we need a
configurable list of sites where we allow the CONNECT in the
traditional way, maybe dynamic as with mod_dnsbl.

3. We should do SSL session management for the client
connections. The correct solution would even maintain one SSL
session between proxy and server per SSL session between
browser and proxy.

Note that the third item implies that we need a tight coupling
between the SSL server part (connection to browser) and the SSL
client part (SSLproxy functionality).

I've written a small proof of concept proxy that accepts CONNECT,
negotiates SSL, builds the GET https request and returns the data
to the browser. Currently it only works for GET requests, but
that is a limitation of the request processing code, not a
problem of the principle. It uses the same certificate all the
time too, but again, this is just a momentary simplification.

So the concept seems to work, but as I'm not too familiar with
the internals of mod_proxy/mod_ssl, I'd like to ask the lists for
some assistance. In particular:

1. Would it be possible to implement this as a protocol filter in
order to bypass mod_proxy_connect? Or do we need to modify
mod_proxy_connect?

2. Would it be possible to reuse the mod_ssl session handling
code?

3. Can we influence mod_ssl's SSLProxy stuff for the `right'
session handling, so that we get one SSL session per browser
SSL session?

4. Would anyone like to help with this project?

Mit herzlichem Gruss

Andreas Mueller

--
Dr. Andreas Mueller, Beratung und Entwicklung
Bubental 53, CH - 8852 Altendorf
Email: andreas.mueller@othello.ch
Voice: +41 55 4621483 Fax: +41 55 4621485

Re: Apache content filtering for SSL connections?

afm wrote:

> When the proxy receives a CONNECT request, it is also told to
> what host the client would like to connect. So the proxy could
> generate a certificate matching that host name on the fly and
> negotiate an SSL connection with the browser.

What you're describing is effectively an SSL man-in-the-middle attack,
and although you're doing it for useful purposes, it is the wrong way to
go about this.

The correct solution is to set up your own reverse proxy, with your own
real SSL cert, which can reverse proxy the webmail site. The module you
described can then be used to virus scan the mail.

As a separate exersize, block access to the webmail systems, and inform
people they must use your reverse proxied website instead in order to
gain access.

Regards,
Graham
--

Re: Apache content filtering for SSL connections?

On Thu, 25 Mar 2004, Graham Leggett wrote:
> What you're describing is effectively an SSL man-in-the-middle attack,
> and although you're doing it for useful purposes, it is the wrong way to
> go about this.
I would only describe it as an attack on the known weakness of
certificate handling in current browsers, not on SSL. The problem
is that there is no canonical mapping from hostnames to CAs.

> The correct solution is to set up your own reverse proxy, with your own
> real SSL cert, which can reverse proxy the webmail site. The module you
> described can then be used to virus scan the mail.
This simple is not practical for a large corporation. And
standard security practices would really prefer to have it the
other way round: only sites explicitely excluded from scanning
should be spared the scanning. That's the way we generally handle
security policies for firewalls, why should it be the other way
round for SSL traffic? And there still are many other ways to
download infected stuff.

I think this all boils down to the question: what is more
important for a corporation: individual privacy for employees or
data security for the corporation? An Internet provider or home
user will of course have a different view than the corporate
security officer. Although employees have a right to use the
office phone for private calls, banks usually tape the majority
of phone calls for their own security. What's the difference?

> As a separate exercise, block access to the webmail systems, and inform
> people they must use your reverse proxied website instead in order to
> gain access.
In squid, a simple redirect to the reverse proxied webmail from
the webmail system would do, I guess.

Mit herzlichem Gruss

Andreas Mueller

--
Dr. Andreas Mueller, Beratung und Entwicklung
Bubental 53, CH - 8852 Altendorf
Email: andreas.mueller@othello.ch
Voice: +41 55 4621483 Fax: +41 55 4621485