Re: Firewall best practices

[Dave Piscitello <dave () corecom com>]

John, you conflate two issues.

First, it's true that only the holder of the private key can decrypt 
data encrypted by the complementary public key in the pair.
But in the scenario discussed here, the holder of the private key uses 
that key for SSL/TLS connections terminated at his firewall, i.e., 
between a customer's client browser and the https server operating on 
the firewall. The https server on the firewall decrypts the traffic, 
does application traffic inspection, and then forwards traffic 
(encrypted in a separate SSL connection or in the clear) to an 
application server the firewall is "protecting".

Any hacker could buy such a firewall but if he didn't know the private 
key and couldn't situate his firewall to intercept customer traffic it 
would not matter. This is really no different from any hacker buying a 
server, running apache, and running the SSL/TLS libraries. He'd still 
have to obtain the private key.

Firewalls and other middle boxes of this sort exist today. Some are 
active proxies as I describe above and others are inline/passive 
monitors. The latter are used for transaction monitoring/performance 
analysis and I understand that they can be programmed to partially 
decrypt traffic (e.g., only application packet headers so that PII, 
financial, or other sensitive data are not expose to 3rd parties).

John Morrison wrote:
> My understanding of https (and other PKI-based encryption) is that
> only the holder of the private key can decrypt the data encrypted with
> the other (public) key in the pair. My view is that the firewall can
> only decrypt and inspect https traffic if it is acting as the server
> to the external client. It can't intercept and decrypt https traffic
> destined for another device - the real server. If it did https would
> be worthless. Any hacker could buy such a firewall to sniff and
> decrypt all https traffic.
>
> On 23 April 2010 20:18,  <david () lang hm> wrote:
> > On Fri, 23 Apr 2010, Martin Barry wrote:
> >
> > > $quoted_author = "Marcus J. Ranum" ;
> > > > That's why firewalls need to go back to doing what they
> > > > originally did, and parsing/analyzying the traffic that
> > > > flows through them, rather than "stateful packet
> > > > inspection" (which, as far as I can tell, means that
> > > > there's a state-table entry saying "I saw SYN!")
> > > Marcus, are you referring to DPI or proxies or both or something else
> > > entirely?
> > >
> > >
> > > > If the firewall doesn't understand the data it's passing,
> > > > it's not a firewall, it's a hub.
> > > If an application emulates HTTPS traffic and is proxy aware, how do you
> > > tell
> > > the difference?
> > There are firewalls on the market that can decrypt HTTPS traffic (and I
> > believe be configured to block any traffic that they can't decrypt)
> >
> > David Lang
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards () listserv icsalabs com
> > https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

Attachment: dave.vcf
Description:

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards