Versions / Builds Affected
2015Status
ResolvedProblem Summary
Unable to block Skype even when HTTPS scanning is enabledTT / JIRAID
2007How to Identify
When a policy is created to block Skype the end users can still actively use Skype. This is a bug with Skype and RFC compliance.Workaround / Fix Details
Possible Workarounds
WebMonitor does have the capability to make exceptions for HTTPS inspection traffic which can be configured per IP /domain(destination) or user basis; However in this particular scenario, it would not work properly. Possible workarounds include:
1. Skype uses a concept of super nodes and uses P2P communication, so there is no list of main servers that Skype connects to, which could have been added to the HTTPS inspection exception list in WebMonitor. In effect, Skype would use the closest supernode (P2P) it finds and it would not be possible to know the IP of that beforehand. In addition, the following day, it can use another supernode someplace else.
2. Configuring user exceptions may work, but there is a caveat: Normally when one would create a dedicated user for Skype and ask users to perform a 'Run As...' using those credentials, and then the administrator would perform a user based exception for HTTPs inspection in WebMonitor. The issue lies in the fact that there is nothing preventing the users from using 'Run As...', and in turn using the Skype user to start up Internet Explorer, thus avoiding HTTPS inspection within Internet Explorer.
3. Another possible workaround that might work, is to set a default port within the Skype client configuration (via GPO) and allow that port in the firewall.
Reference: https://support.skype.com/en/faq/FA148/which-ports-need-to-be-open-to-use-skype-for-windows-desktopRequired Actions
Install all patches for WebMonitor