I keep seeing phrases like "secure firewall friendly connection" on products - what does it really mean?
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.