Share via

I keep seeing phrases like "secure firewall friendly connection" on products - what does it really mean?

  • Article

Like many of you I keep seeing and hearing statements like "secure firewall friendly connection" on numerous products.

Just think about what this really means - the firewall has little chance of doing anything useful as traffic is being tunnelled through in encrypted form. This is not necessarily a problem but it's important to be aware that your threat profile changes as a result.

It means that application traffic will be transmitted through the firewall via a protocol that's highly likely to be allowed through - namely HTTP using SSL to encrypt the data (and authenticate the server to the client) hence HTTPS.

A small number of firewalls such as Microsoft's Internet Security and Acceleration Server (ISA) can be configured to intercept INBOUND HTTPS and inspect the content to ensure it complies with policy. Most firewalls still limit their inspection to just the packet headers and ignore the content. Inbound inspection is achieved by configuring ISA to take on the identity of the web server via it's certificate and associated private key. Optionally ISA can be configured to re-establish the SSL tunnel between itself and the internal webserver.

The OUTBOUND scenario is rather different. If someone in your organisation establishes an outbound connection to a remote webserver via SSL (HTTPS) then the firewall can't inspect it without breaking the protocol as the required private key for the target webserver is not available.

As you may be aware many vendors (including Microsoft) advocate tunnelling as it's often an effective way to easily deploy client server applications (like Outlook and Exchange) either side of firewall infrastructure.

The term "secure firewall friendly" used in this way is almost an oxymoron. Of course using SSL in the prescribed manner gives authentication of the server to the client and encryption of the data in transit - both potentially good things - but it generally negates the effectiveness of your firewall.

Note: In days of old such applications used to use their own ports and required the firewall administrator to open up holes accordingly for each giving granularity. Firewall admins generally became viewed as obstinate people who resisted change "in the name of security" and therefore applications started tunnelling over existing ports.

Comments

  • Anonymous
    January 01, 2003
    I've not tried ClearTunnel. Presumably it establishes and SSL connection between itself and the target server. How does it impersonate the target server's cert as it won't have the associated private key?

  • Anonymous
    January 01, 2003
    "gerbilferrit"> I'm guessing that pointing out the plethora of sites that provide the means to tunnel outbound and circumvent such security wouldn't be the best place to start then?! I know that you can't reason with some people but if you get the opportunity ask them to consider what threat they're trying to mitigate, and explain that if they enable you to be more effective @ your work then they're HELPING the business and are likely to be better respected and listened to more often.

  • Anonymous
    January 01, 2003
    Adam> Thanks for the info.

  • Anonymous
    May 24, 2007
    From the enterprises point of view, I love the idea of being able to do outbound SSL bridging as is allowed by a product such as Collective Software's ClearTunnel... generating certificates on the fly between the user and the ISA server to impersonate the actual SSL server they're talking to - thereby allowing inspection and filtering of the outbound SSL. Of course, as a user, I hate the idea of this and really wouldn't want to do my banking from the office of an organisation that used it. I wonder if MS have any plans to incorporate a feature like this directly into ISA?  It seems like such a trivial thing to be able to do.

  • Anonymous
    May 25, 2007
    It can issue certs on behalf of the enterprise CA - which all the clients trust.  So when a user visits www.commbank.com.au (for example) it creates a server cert for it & impersonates it... the client is happy because its talking to a www.commbank.com.au using a cert that it trusts.  The proxy can then establish another SSL connection to the real www.commbank.com.au... of course it won't work if the webserver requires client (certificate) authentication. I think it fills a nice niche for those organisations who want to allow access to HTTPS sites but have strict policies that may otherwise prevent it.

  • Anonymous
    May 25, 2007
    The comment has been removed