Even Skype for Business (SfB) is a huge problem for web gateway control if SSL scanning is enabled (which it should be as now more than 50% of all web traffic is encrypted).
First, the current client will not accept even certs that are rewritten by a trusted certificate authority unless the rewritten cert includes OCSP and CRL information.
Secondly SfB runs non-HTTPS traffic (MS-TURN and SIP) using port 443 after the certificate has been verified by the client.
And thirdly, SfB requires on premise Skype servers with Internet access to essentially proxy the UDP and TCP SfB traffic that runs on ports other than 80 and 443, otherwise you have to open many additional holes in your firewall.
Regardless, you cannot currently use any web proxy to actually inspect Skype Consumer or Skype for Business traffic to any reasonable effect.
Furthermore the accommodations for allowing either version of Skype through a web proxy necessitates opening significant security holes as the proxy needs to take any indicators for inspection bypass directly from the client application with no verification. So, if a piece of malware assumes that the proxy is configured to allow Skype (either with exceptions to SSL scanning or no SSL scanning at all), then it can simply format its command, control, and exfiltration traffic to mimic MS-TURN and or SIP control traffic and by doing so completely avoid inspection unless rigorous certificate verification is performed on the web gateway which of course becomes even more challenging in transparent proxy deployments as there is nothing to enforce the client using SNI. (Yet another reason to use explicit proxy and client agents wherever possible)
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as a Solution in my reply so we can help other community participants?
You Deserve an Award
