Re: [fw-wiz] Application Proxy/L7 Firewall Recommendation?
From: Carson Gaspar (carson@taltos.org)
Date: 09/06/02
- Next message: Carson Gaspar: "Re: [fw-wiz] pix 515 failover"
- Previous message: Daniel Linder: "Re: [fw-wiz] pix 515 failover"
- In reply to: John Adams: "Re: [fw-wiz] Application Proxy/L7 Firewall Recommendation?"
- Next in thread: Adam Shostack: "Re: [fw-wiz] Application Proxy/L7 Firewall Recommendation?"
- Reply: Adam Shostack: "Re: [fw-wiz] Application Proxy/L7 Firewall Recommendation?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Carson Gaspar <carson@taltos.org> To: firewall-wizards@honor.icsalabs.com Date: Fri Sep 6 06:19:15 2002
--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
- Next message: Carson Gaspar: "Re: [fw-wiz] pix 515 failover"
- Previous message: Daniel Linder: "Re: [fw-wiz] pix 515 failover"
- In reply to: John Adams: "Re: [fw-wiz] Application Proxy/L7 Firewall Recommendation?"
- Next in thread: Adam Shostack: "Re: [fw-wiz] Application Proxy/L7 Firewall Recommendation?"
- Reply: Adam Shostack: "Re: [fw-wiz] Application Proxy/L7 Firewall Recommendation?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|