HTTPS Scanning

Unanswered Question
Dec 19th, 2008

Hey folks - Are there any downsides to turning this feature on? Also, has anyone seen these tunneling proxy apps? For example Ultrasurf. Basically it tunnels out 443 to a random IP and directs all IE traffic out the tunnel. It completely bypasses all WSA blocks. Will the WSA detect this traffic with HTTPS decryption on?

-Tim

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jowolfer Mon, 12/22/2008 - 16:46

Tim,

HTTPS decryption is a dual edged sword. It provides great functionality, but it does require some intentional configuration and network design.

The positives are:
------------------------------------------
Detection and scanning for all objects, not just HTTP.

This means that the WSA can see inside the HTTPS traffic for category blocking, WBRS score filtering, signature scanning so forth. This will most likely address the Ultrasurf issue, since the "Proxies & Translators" category is updated regularly.
------------------------------------------

The negatives:
------------------------------------------
HTTPS certificate warnings on clients:
Since the WSA is, for all intents and purposes, performing an HTTPS / SSL 'Man in the Middle' attack on your clients, by default the clients will receive a browser warning about HTTPS decrypted sites being compromised.

The only way to work around this issue is to install the Root CA certificate that the WSA uses, into each client.

This can be tricky since each client manages it's own certificate store.

For example: Internet Explorer uses the Windows Trusted CA certificate store, but FireFox, Opera, and do not. So even though you can push the root certificate from the Domain Controller and make IE trust the WSA, you have to manually install the root certificate into other browsers.

Compliancy Issues:
The other complicating factor is that not all port 443 traffic is HTTP over SSL compliant. Some apps send 1/2 compliant SSL, or establish SSL and then send a custom protocol instead of HTTP.

In some cases, this non-compliant traffic will break when going through a decrypting WSA. There are workarounds to this.

The WSA can be configured to use HTTPS "Pass through" for certain sites. This will work with most problematic sites. For sites / apps that are so far non-compliant that they break in "pass through" mode as well, there is the "proxy bypass" list. This will in essence, force the WSA to re-route packets for specified destinations, back to the router.
------------------------------------------

I apologize for the long winded answer, but I have a feeling this is what you were looking for.

The positive of HTTPS decryption is pretty big, but the deployment caveats of being a 'man in the middle attack' need to be planned for proactively.

I also recommend upgrading to the latest 5.6 release if you will be using HTTPS decryption.

Hope this helps,

Actions

This Discussion