HTTP vs HTTPS filtering and blocking

[Migration User]

Could someone please confirm the following operation of the Symantec Gateway Server.

I have setup, configured and am testing a Symantec Web Gateway appliance running in Inline/Blocking mode.  User's web browsers are not configured with any Proxy settings.

We have a lot of Facebook users which we are trying to block (at least during business hours).

I put the appliance on our production network and turned on URL Filtering and blocked the Social Media category (which includes Facebook).  Initial tests worked as expected, and found that http://www.facebook.com is blocked by the Symantec Web Gateway.

I got a call 5 minutes later saying someone already found another way into Facebook by using the secure address (https://www.facebook.com/login.php).

In reading the instructions, it seems that the SWG cannot natively filter HTTPS/SSL traffic in INLINE mode (thus the reason why users can still access Facebook through HTTPS... while the HTTP access to Facebook is blocked).   Upon further reading...  I read that to filter HTTPS/SSL traffic... that PROXY mode must be activated on the Gateway, and that all user's web browsers proxy settings must be configured to point to this Gateway.

One of the criteria in choosing a web filtering appliance or solution is that we would NOT configure or make use of user's Internet browser proxy settings.  We have too many transiant users between various offices, and it becomes a logistical nightmare keeping track of... and changing user's proxy settings. Thus the reason why we purchased the SWG appliance as it was our impression by the sales information is that we could run the Web Gateway appliance in Inline mode, which wouldn't require changes to user proxy settings to each and every web browser we have, and therefore was seamless and transparent to the end user and no additional configuration work was required on our part.

So... Is this correct?  If I only want to filter HTTP traffic, then INLINE mode is fine.  If I also need to filter HTTPS/SSL traffic, then the Gateway must run in PROXY mode, and all of our 1000+ user's web browser proxy settings will need to be configured to point to the Gateway... just so I can stop SSL traffic to Facebook???   If this is the case... then this would be unacceptable solution in our case, and I would have to look for other providers or solutions which could filter both HTTP and HTTPS traffic seamlessly.

[SMLatCST]

What you have is correct I'm afraid.  Without some kind of proxy (whether an external one, or the SWG's own inbuilt one), the SWG is unable to filter HTTPS.

Here's a breakdown of the HTTPS options:

http://www.symantec.com/docs/TECH98131
http://www.symantec.com/docs/HOWTO54200

TBH though, from a technical standpoint, I don't believe a fully transparent (i.e. no proxying, no certificate spoofing) filtering solution is possible for HTTPS.  The only way anything can properly filter HTTPS traffic is if it is able to decrypt the data being transmitted, and the only reliable way of doing that is if it has the key.  This is normally accomplished using the man-in-the-middle model, which the SWG uses (and requires proxy mode to work).

If you do come across products that can do this fully transparently, please let me know (I'd be curious to hear how they work)

[Migration User]

by my side if you block HTTPS traffic PROXY mode, but the trouble is that the figure does not show lock SWG.

any recommendation

Thank you.

[Migration User]

I notice that myself.   On blocked HTTP traffic, there is a Symantec notice that comes up on the screen that says the site is block (and the reason why).   When filtering HTTPS traffic in Proxy mode, there is no indication to say that the site is blocked, except the web browser displays a "Page cannot be displayed" message.   I don't know why this is...

[Migration User]

Exactly the idea is that you should know, since I've had this same problem with other devices from other brands ... : (

[Migration User]

Make sure you have an intercept action enabled for the category in your SSL policy. Also, Symantec does have some guidance in a TECH article on how to show the blocking message in the HTTPS stream.

http://www.symantec.com/business/support/index?page=content&id=TECH175244