Re: Application Proxy/L7 Firewall Recommendation?

[Carson Gaspar <carson () taltos org>]

--On Thursday, September 05, 2002 11:17 AM -0700 John Adams 
<jna-dated-1031681827.333800 () retina net> wrote:

> On Thu, 5 Sep 2002, Balazs Scheidler wrote:
>
> > And yes SSL means that you can peek into decrypted SSL streams. (url
> > filtering in HTTPS, anyone?) You can limit CONNECT, or stack in a
> > decrypting HTTPS proxy within the CONNECT method to avoid instant
> > messengers to go through your firewall.
>
> How do they implement this?
>
> Consider this: I attempt to connect to a site via HTTPS, and the
> certificate presented by your decrypting proxy doesn't match the expected
> certificate of the site I'm connecting to. Therefore, I know that there's
> a man-in-the-middle attempting to decrypt my session. This is exactly the
> sort of action that SSL was designed to prevent.

When I did my design, I did the following:

- The proxy must be a CA able to automatically sign certificates (or must 
be able to request certificates from another system)
- The client must trust this CA
- When a client requests a connection, the proxy initiates the connection, 
and captures the certificate information. It then checks it's cache of 
spoofed certs, and generates a new one if the cache lookup fails, or 
returns an expired cert
- The generated cert is then used to initiate a TLS session with the client

There are some technical issues with this:

- I don't think it's possible to make client cert-based auth work 
end-to-end (although I didn't try very hard). The proxy could present a 
certificate to the server on behalf of the client, however.
- Cert generation is computationally expensive. This is mitigated by 
caching the certs.

Then there are the security implications:

- If the proxy is compromised, so is the security of all sessions passing 
through it
- The proxy must implement TLS, which is non-trivial to do, and thus there 
is a strong possibility that the implementation will be flawed (see the 
recent issues with OpenSSL and CryptoAPI)
- The cert validation must be done on the proxy. The proxy must have some 
mechanism of communicating issues with the client. If the policy allows a 
user to override a cert warning (as many sites have certs that do not 
validate), there is added complexity to caching which non-validating certs 
have been approved, and for whom. For this to work from shared systems, or 
in many DHCP environments, it requires users to authenticate to the proxy.

> Note also that there's many other ways to tunnel illegitimate traffic
> inside of legtimate traffic; these sorts of L7 proxies only prevent
> people  who don't know what they're doing from establishing a connection
> to where  they want to go.

Of course. However, what I call a "Benevelent Dictator Man-in-the-middle 
Attack" does provide protection for legitimate users. IDS and Anti-virus 
can be applied to encrypted data streams, protecting end-users from many 
classes of attack.

--
Carson

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards