Firewall Wizards mailing list archives
Re: Firewall best practices
From: Mathew Want <imortl1 () gmail com>
Date: Thu, 29 Apr 2010 11:37:30 +1000
Cian, I agree that it would generate a warning but the issue you then have is users go "Huh?, what?" and click on allow anyway. To quote a presenter at a security course I attended "If the user is given the choice between security and seeing a dancing snowman, the snowman wins every time!". The "advantage" that SSL had for the general populous for nonEvil(tm) purposes was that we could say that if the little padlock was there when they went to their internet banking site that their data was safe*. These new technologies, although neccessary for a host of other reasons such ad data leakage, covert communications etc etc etc unfortunately push the responsibility for the security of personal data closer to the people that it important to. Unfortunately they are the least able to deal with it in general and as much as we TRY to teach them ( and I do really try). We do try to protect users from themselves, but there is only so much we can do. I am not saying that the MITM function is not without its merrit (in whatever form you see as the best for security) but it does then pose other interesting positions to consider. Just my $AU0.02 worth! M@ * Yes I know "safe" is a relative term in this context, but youget the idea! :-) On 28 April 2010 18:13, Cian Brennan <cian.brennan () redbrick dcu ie> wrote:
On Tue, Apr 27, 2010 at 11:12:40AM -0500, Fetch, Brandon wrote: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...Where it would generate cert errors for every user? These only make sense where you can install the proxy's wildcard cert on all of the client machines. Neither coffee houes, nor ISPs can do this.-----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
-- "Some things are eternal by nature, others by consequence" _______________________________________________ firewall-wizards mailing list firewall-wizards () listserv icsalabs com https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Re: Firewall best practices, (continued)
- Re: Firewall best practices Dave Piscitello (Apr 28)
- Re: Firewall best practices ArkanoiD (Apr 28)
- Re: Firewall best practices Nate Itkin (Apr 27)
- Re: Firewall best practices Dave Piscitello (Apr 27)
- Re: Firewall best practices Carson Gaspar (Apr 27)
- Re: Firewall best practices Fetch, Brandon (Apr 27)
- Re: Firewall best practices lordchariot (Apr 28)
- Re: Firewall best practices Bruce B. Platt (Apr 30)
- Re: Firewall best practices Cian Brennan (Apr 28)
- Re: Firewall best practices Fetch, Brandon (Apr 28)
- Re: Firewall best practices Mathew Want (Apr 30)
- Re: Firewall best practices ArkanoiD (Apr 30)
- Re: Firewall best practices Marcus J. Ranum (Apr 30)
- Re: Firewall best practices ArkanoiD (Apr 27)
- Re: Firewall best practices Dave Piscitello (Apr 22)
- Re: Firewall best practices Marcus J. Ranum (Apr 15)