firewall-wizards@listserv.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com
You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Re: Firewall best practices (Dave Piscitello)
2. Re: Firewall best practices (Carson Gaspar)
3. Re: Firewall best practices (Carson Gaspar)
4. Re: Firewall best practices (Fetch, Brandon)
5. Re: Firewall best practices (Paul D. Robertson)
6. Re: Firewall best practices (lordchariot@embarqmail.com)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Apr 2010 13:41:09 -0400
From: Dave Piscitello <dave@corecom.com>
Subject: Re: [fw-wiz] Firewall best practices
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Cc: mjr@ranum.com, Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <4BD721B5.30802@corecom.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dave.vcf
Type: text/x-vcard
Size: 220 bytes
Desc: not available
URL: <https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20100427/0b7b4da7/attachment-0001.bin>
------------------------------
Message: 2
Date: Tue, 27 Apr 2010 16:41:04 -0500
From: Carson Gaspar <carson@taltos.org>
Subject: Re: [fw-wiz] Firewall best practices
To: mjr@ranum.com, Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <4BD759F0.2040306@taltos.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Marcus J. Ranum wrote:
> I wasn't referring to anything in specific; I think, though,
> that we've moved past the point where we can think of firewalls
> as just source/dest IP source/dest port and we need to start
> characterizing genres and sub-genres of traffic. There was a
> time when Jon Postel said that "Email is the new datagram"
> but now "HTTP is the new IP" - we've lost the battle on trying
> to have HTTP just be a fetch protocol for data; it's now a
> much more complicated thing with genres and sub-genres and
> probably sub-sub-genres of traffic. We can't meaningfully
> "firewall" traffic if "permit source HTTP ANY" includes
> VPNs, bidirectional commands, voice data, and who knows
> what else?
Once upon a time I did some serious thinking about a signature based
firewall, that cared only a little about port numbers, and a lot about
packet content. It would necessarily involve an update cycle similar to
anti-virus signature updates.
I've seen some work on this, mostly from a traffic shaping / IPS / IDS
slant, but I haven't seen anything serious from the firewall front. But
then I haven't been doing firewalls for several years, so I may just be
behind the times.
> You're completely right about the "if the application
> emulates HTTPS traffic" problem. I don't have an answer
> to that one other than "we warned everyone that that
> was going to be a problem." At this point, it's less
> of technical problem than a social one. It seems to me that
> an organization cannot claim to be concerned about
> security while allowing user-oriented encrypted outgoing
> links to any target. That's just foolishness. The fact
> that "everyone does it" doesn't make it any less foolish.
> Back in the proxy days we advocated tying outgoing
> connections to an authenticated user; that's another
> important aspect of the problem that gets short shrift.
See my previous (or possibly next, post moderstion...) post re: SSL MITM
proxies. Of course that just puts you back at the first problem, except
you may detect rogue apps by their non-acceptance of your magic CA cert.
--
Carson
------------------------------
Message: 3
Date: Tue, 27 Apr 2010 16:34:16 -0500
From: Carson Gaspar <carson@taltos.org>
Subject: Re: [fw-wiz] Firewall best practices
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <4BD75858.3030100@taltos.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
Not entirely true. Way back when (1995/96) when I was hacking on
firewall proxies I postulated a benevolent dictator MITM proxy for HTTPS
(or other SSL services). This requires that you have your own signing CA
and install its key as trusted in your users' browsers (or other
software). The proxy can then impersonate the server and examine the
traffic.
Since then, several implementations of such a beast have been created,
some of which are open source.
--
Carson
------------------------------
Message: 4
Date: Tue, 27 Apr 2010 11:12:40 -0500
From: "Fetch, Brandon" <bfetch@tpg.com>
Subject: Re: [fw-wiz] Firewall best practices
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Cc: "mjr@ranum.com" <mjr@ranum.com>, Firewall Wizards Security Mailing
List <firewall-wizards@listserv.cybertrust.com>
Message-ID:
<A22AB7AA11C57342918639C100566F244E1FD35432@TXMAIL.texpac.com>
Content-Type: text/plain; charset="us-ascii"
Too late:
http://files.cloudprivacy.net/ssl-mitm.pdf
And these devices are already in deployment...now, imagine one of these with a wildcard certificate running at a coffee house, or at the aggregation point within a provider's CO POP...
-----Original Message-----
From: firewall-wizards-bounces@listserv.icsalabs.com [mailto:firewall-wizards-bounces@listserv.icsalabs.com] On Behalf Of John Morrison
Sent: Tuesday, April 27, 2010 5:45 AM
To: Firewall Wizards Security Mailing List
Cc: mjr@ranum.com; Firewall Wizards Security Mailing List
Subject: Re: [fw-wiz] Firewall best practices
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
This message is intended only for the person(s) to which it is addressed
and may contain privileged, confidential and/or insider information..
If you have received this communication in error, please notify us
immediately by replying to the message and deleting it from your computer.
Any disclosure, copying, distribution, or the taking of any action concerning
the contents of this message and any attachment(s) by anyone other
than the named recipient(s) is strictly prohibited.
------------------------------
Message: 5
Date: Tue, 27 Apr 2010 18:18:40 -0400 (EDT)
From: "Paul D. Robertson" <paul@compuwar.net>
Subject: Re: [fw-wiz] Firewall best practices
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <Pine.LNX.4.44.1004271812240.29939-100000@bat.clueby4.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 27 Apr 2010, Marcus J. Ranum wrote:
> scale between "nothing at all" and "utter crap" it's the SSL
> situation. I guess that having crypto that sucks so badly that
> it's breakable is easier than having to actually ask the question,
Oh, it's much, much worse than that- you're breaking the old red/black
network model by allowing encrypted and unencrypted packets to/from the
same device from different security domains without compartments. But
more importantly all the effort of the overengineered SSLcrap is that the
entire industry focused on the wrong end of the problem. It's not the
server that needs the protection (not to mention that still also breaks
the traditional crypto model- but I tried to advocate around that with a
trusted OS, "too much work" it seems *sigh*.
>
> In Marcus-land the way we'd do it is have crypto that didn't
> suck, and firewall rules that permitted outgoing crypto only
> to (say, if online banking was an authorized activity during
> office hours) a set of supported sites. Yeah, yeah, I know,
> Marcus-land isn't a real place...
Even with sucky crypto, the combination of allowing traffic only to
specific sites would be a *major* improvement over the status quo. Couple
that with only allowing trusted executables (Windows Software Restriction
Policies are still better than 98% of what's out there) and you get to a
pretty good place pretty quickly.
In Paul-land, Marcus land would have lots more beer, and Paul would be
allowed much more access!! ;)
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
paul@compuwar.net which may have no basis whatsoever in fact."
Moderator: Firewall-Wizards mailing list
Art: http://PaulDRobertson.imagekind.com/
------------------------------
Message: 6
Date: Wed, 28 Apr 2010 01:15:51 -0400
From: <lordchariot@embarqmail.com>
Subject: Re: [fw-wiz] Firewall best practices
To: "'Firewall Wizards Security Mailing List'"
<firewall-wizards@listserv.icsalabs.com>
Cc: mjr@ranum.com, 'Firewall Wizards Security Mailing List'
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <000001cae691$df9fd200$9edf7600$@com>
Content-Type: text/plain; charset="us-ascii"
Speaking of rogue root CAs. Mozilla recently discovered a CA they couldn't
account for that was presumably from RSA.
http://blogs.zdnet.com/security/?p=6016&tag=nl.e589
They have since confirmed its authenticity in an update, but can you imagine
if a nefarious CA got embedded into the browser?
Meh, it actually probably wouldn't make much difference anyway. Users are
just going to click OK anyway to bypass the warning...sigh.
-erik
> -----Original Message-----
> From: firewall-wizards-bounces@listserv.icsalabs.com [mailto:firewall-
> wizards-bounces@listserv.icsalabs.com] On Behalf Of Fetch, Brandon
> Sent: Tuesday, April 27, 2010 12:13 PM
> To: Firewall Wizards Security Mailing List
> Cc: mjr@ranum.com; Firewall Wizards Security Mailing List
> Subject: Re: [fw-wiz] Firewall best practices
>
> Too late:
> http://files.cloudprivacy.net/ssl-mitm.pdf
>
> And these devices are already in deployment...now, imagine one of these
> with a wildcard certificate running at a coffee house, or at the
> aggregation point within a provider's CO POP...
>
> -----Original Message-----
> From: firewall-wizards-bounces@listserv.icsalabs.com [mailto:firewall-
> wizards-bounces@listserv.icsalabs.com] On Behalf Of John Morrison
> Sent: Tuesday, April 27, 2010 5:45 AM
> To: Firewall Wizards Security Mailing List
> Cc: mjr@ranum.com; Firewall Wizards Security Mailing List
> Subject: Re: [fw-wiz] Firewall best practices
>
> 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
>
> This message is intended only for the person(s) to which it is addressed
> and may contain privileged, confidential and/or insider information..
> If you have received this communication in error, please notify us
> immediately by replying to the message and deleting it from your computer.
> Any disclosure, copying, distribution, or the taking of any action
> concerning
> the contents of this message and any attachment(s) by anyone other
> than the named recipient(s) is strictly prohibited.
>
> _______________________________________________
> 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
End of firewall-wizards Digest, Vol 48, Issue 14
************************************************
No comments:
Post a Comment