You can create an additionl proxy port to point skype to and then add an exception to the SSL Scanner rule set using Proxy.Port (ex: Proxy.Port does not equal <new proxy port>). You may also want to take it a step further and apply further restrictions to that new proxy port in your policy such as blocking HTTP protocol and placing restrictive category blocks so that it is.
I just did this as a matter of fact I am clicking "save changes" now as I type. There's a KB article here somewhere I used for this so it's not an original idea and it's pretty much what pbrickey suggested. Use another port then create a policy mapping and rule set to limit what that new policy can do. I locked it down to only users in a specific skype AD group and then blocked all traffic not IP to IP based. Works like a champ.
All the ideas above are good, however they all open up security holes and add complications like making the user change their proxy settings. SSL scanning and Skype are not very compatible as noted. However, simply turning off SSL scanning significantly compromises your security posture, and is highly discouraged as a solution for allowing Skype. There is no unique Skype property, and not all HTTPS requests from the client are by IP if explicit proxy is set in the client. Regardless of the proxy settings in the client, Skype will also try and go direct, so MWG based blocking will not work if clients are allowed out direct through the firewall using ports 80 or 443. If you are going to use the dedicated proxy port method be sure you block everything that doesn't match the skype criteria on that port, so that your end users don't use that port to reduce their filtering restrictions for general browsing.
In transparent deployments other than McAfee Client Proxy authentication is also a challenge. The best way I've found to control Skype is to block all direct ports on the firewall, enable SSL scanning, and being very specific on the criteria that allows requests to bypass SSL scanning. Also, do the bypass with stop ruleset rather than stop cycle so that at least the URL filtering will apply based on host name. Using a specific dedicated proxy port helps immensly but has the downside of requiring clients / end users to change their browser settings. Using McAfee Client Proxy is highly recommended as it provides the transparent authentication and redirection for Windows clients without requiring end users to change their Skype settings. Other clients could continue to use the explicit proxy port, Skype settings method.
Now for the criteria for bypass....
Proxy.port equals <port being used> AND
URL.Port equals 443 AND
(Host.IsIP equals true OR
URL.Host.BelongsToDomains(Skype Host Domains) equals true) AND required if you want Skype Home to work for explicit proxy
(Authentication.UserName is in list Skype Authorized Users OR requires authentication before SSL scanner
Authentication.UserGroups at least one in list Skype Authorized User Groups) AND
URL.ReputationString<Default> is in list Skype Allowed Reputations AND
(URL.Categories<Default> equals Empty Category List OR allows uncategorized sites
URL.Categories<Default> at least one in list Skype SSL Bypass Categories)
Skype Host Domains are: skype.com, skypeassets.com, facebook.net
Skype SSL Bypass Categories are: Internet Services, Web Phone, Instant Messaging, Residential IP Addresses, Content Server, Web Meetings, Web Mail (Content Server required for Skype Home to work, Web Meetings and Web Mail may not be required)
Note that if you use Stop Ruleset as recommended, you will also make sure that these categories and uncategorized sites are allowed in your URL category filter as well
Again note that this opens up a significant security hole for clients that are allowed to use Skype. That is, traffic on port 443 that is requested by IP and is uncategorized (or is in one of the bypassed categories) will be allowed without any filtering! However, this is still a much more secure solution than simply bypassing SSL scanning anything referenced by IP
Message was edited by: jebeling on 7/24/14 8:06:35 AM CDT
Message was edited by: jebeling on 7/24/14 8:29:40 AM CDT
Message was edited by: jebeling on 7/29/14 2:44:09 PM CDT
Message was edited by: jebeling on 7/29/14 2:47:11 PM CDT