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
[…] Lync 2010 Client Connections are TLS Only : Jeff Schertz’s Blog Posted on October 5, 2010 by johnacook http://blog.schertz.name/2010/10/lync2010-client-tls-only/?utm_source=feedbur… […]
Jeff,
On the troubleshooting part, there are certain scenarios when we would need a packet level/decrypted trace.
The Lync Logging Tool does obfuscates NTLM GSSAPI data when there are login errors due to credential validation issues. This is contrary to the behaviour in R2 Logging Tool from which we get the username used for authentication. In this case, for Lync, we would need to decrypt the network trace or use TCP based connection.
JB, I agree there will be some specific use-cases for decrypting the traffic, which you can do in either of the tools I discussed, there are others I have used it for as well. I don't believe the product team intends to assume it will never need to be performed, just that other steps should be tried first.
well it seems evern with the RTM version this issue remains since i have tested it on my laptop yesterday 🙂
regards,
The RTM version did not remove the TCP/TLS 'Connect using' buttons from the GUI, but the functionailty has been disabled as when you click on Manual Configuration both buttons are grayed-out.
Update: Tom Pacyk has published a blog article related to enabling the Lync Server to listen on TCP5060 for incoming connections: http://www.confusedamused.com/notebook/enabling-u…
Take note that this is intended for interoperability with other non-Lync system (e.g. third-party video conferencing bridge) where TLS is either not used or supported. This alone will not allow Lync clients to connect over TCP as the functionality is still disabled within the Lync client software.
well it seems it still the same with the RTM version of the client, they didn't fix it yet
regards,
I am sorry for my duplicate input
But, what is the simple solution for change TLS to TCP??
There is none, TCP is not allowed on the Lync 2010 client.
Hi Jeff,
Thanks for the post.
Please let me know if there is no way we can configure TCP instead of TLS on LYNC Client. As my application understands only TCP not TLS. Also when we look at the RTP pakcets the default audio codec they are using is MS Proprietary is there any way to use G.711 or G.279 internally betwen Client to Client calls. Please help me, i am cracking my head since few weeks.
The Lync client can only use TLS connections, this behavior is not configurable. If you need to enable the Front End server to listen for TCP connections on 5060 for custom applications then you can do so by following the direction in the TechNet documentation.