The Advanced Connection Settings under the Lync 2010 RC client’s Personal Options still shows the old Connect Using TCP/TLS radio buttons, but those options are greyed-out even if Manual Configuration is selected.

This is actually a bug in the Release Candidate version of the client and will be removed in final release version, which will close the loop on a long process of completely fazing out unsecured connections between clients and servers in the Communications Server product.  Back in the original Live Communications Server 2005 release TCP connections were the default and most deployments did not opt to leverage the certificate-based TLS connection options. But at the arrival of Office Communications Server 2007 the default connection option was to use TLS, and OCS Front-End services would not even be able to start without the installation of at least one valid X.509 certificate.  TCP connections were still supported, but not recommended for production deployments.

Around this time one of the largest deployment blockers was the certificate requirement. Many companies (including some large organizations) had yet to deploy an internal Enterprise PKI Certificate solution and either had to (a) ramp up on the technology and deploy a Windows Enterprise Certificate Authority or (b) shell out hundreds of dollars on publically issued certificates for even internal use.

Fast-forward to today and the Communications Server team’s approach is with the wide usage of certificates for HTTPS secured internal websites (e.g. SharePoint) and messaging systems (e.g. Exchange Server 2007 and 2010) and the availability of many lower-cost certificates from trusted third party issuers that certificate availability is no longer an issue.

Another common use of unsecured TCP-only connections for clients was for troubleshooting connection or communications issues using a packet capture program like Network Monitor or Wireshark. Because TLS-secured connection will not allow the packet capture program to view information inside any of the encrypted TLS traffic then clients would be flipped over to TCP temporarily to easily see all captured data.  At this point even internal audio conversations can easily be captured by anyone with access to the listen to traffic between clients or clients and servers.  For example Wireshark has the ability to capture the audio stream and play it back as an audio recording.

Since using TCP is not an option in Lync 2010 there are two approaches to this issue. One, figure out how to capture and decrypt traffic or two, reevaluate the benefits of this troubleshooting approach and make sure the right tool for the job is being applied.

Decrypting TLS

So you want to do it the old-fashioned way?  Luckily both the popular packet capture utilities support the ability to decrypt TLS traffic if the certificate is available.  The benefit of the TLS limitation is apparent here at a security standpoint as now only personnel with access to the certificate used to encrypt the traffic, which is stored on the Lync Server, can decrypt the media communications and hear the conversation.

• For Wireshark here is a good walkthrough on Citrix’s support website detailing the steps to configure the SSL capture options: http://support.citrix.com/article/CTX116557
• For Network Monitor there is a new Export plugin called NmDecrpyt which can be used to Network Monitor 3.3 or higher: http://blogs.technet.com/b/netmon/archive/2010/03/08/expert-to-decrypt-tls-ssl-traffic.aspx

But Why Bother?

Realistically, other than as a proof of concept I have never needed to look at the encrypted portion of connections to troubleshoot issues at the packet level.  The important information to be leveraged at this level is SIP communications or other open network traffic like DNS requests.  If client connections are working and the root issue is not a port-filtering, name resolution or certificate problem then typically at this point different tools should be used.

For example, if the problem is a failure of an Enterprise Voice call to another internal user then looking at the raw network data is going to be much more work than it should be.  The proper approach here would be to use the Lync Server Logging Tool on the server and capture SIPStack information during the call attempt, then view the results with the Snooper resource kit utility for a much easier-to-read output.

As the product group has invested more resources into the built-in diagnostics (e,g, Logging Tool, Monitoring Server, client-side diagnostics, etc.) there is less of a reason to attempt to view this information at the more basic levels.  And as each product release brings more options and features, which in turn add more code, then trying to make sense of what is going on at the network level is slowly becoming more difficult and complicated.  Thus it can be argued that time and resources should be spent learning the diagnostics tools as they are written specifically for troubleshooting common deployment and operational issues.

The writing has been on the wall for some time to come, so if your environment still does not have some sort of PKI infrastructure deployed then