Padding Oracle On Downgraded Legacy Encryption - aka POODLE (CVE-2014-3566) describes an attack against the SSL 3.0 protocol, which is a predecessor to the current protocols TLS 1.x. SSL 3.0 is outdated, TLS 1.0, 1.1, and 1.2 are specified, have been implemented for a while, and also includes better encryption algorithms. There is no reason to use SSL 3.0 anymore, as long as all components of an application support at least TLS 1.0.

This is true for soft-phones that run on Windows Vista/Server 2008 or later, therefore no problem for Lync 2010/2013 (server and client). But what about the Lync phone edition? The devices run on Windows Embedded CE 6.0 on an ARM platform. So, what about disabling SSL 3.0 in regards to desktop IP phones with Lync phone edition? This is the question that I was confronted with.

You can simply test it, but here is some background information that I was not able to find when I was searching for it, so I had a reason for this article.

Windows/Lync Server/Client
How to deactivating SSL 3.0 on Windows systems has been described in detail on other pages, here are some links to Microsoft’s resources>

• Microsoft security advisory 3009008: https://technet.microsoft.com/en-us/library/security/3009008.aspx
• How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in Internet Information Services: http://support.microsoft.com/kb/187498/en

HLB
If the required measures have been taken Lync is secured. If you use hardware load balancers you should also have a look at them, and also don’t forget the reverse proxy used for the external access together with the Lync Edge server. If using application delivery controllers from F5 Networks you can follow the measures described in solution 15702, starting with BIG-IP release 11.5 SSL 3.0 is been switched of by default:

• SOL15702: SSLv3 vulnerability CVE-2014-3566: https://support.f5.com/kb/en-us/solutions/public/15000/700/sol15702.html

Lync Phone Edition
But there still is one question left open: What do we do with the desktop phones from Aastra, HP, Polycom CX series, and LG Nortel? First of all you need to understand that the problem itself is resolved when the client or server refuses to use SSL 3.0. So there is no explicit reason to adjust things on the phones. The question is whether Windows Embedded CE 6.0 as base system supports TLS 1.0. And if we look at that we can also have a look at the cipher suites.

I analyzed the SSL/TLS-negotiation of CU6 (.4100 dated June 2012), CU7 (.4363 and .4372 dated December 2012) und CU11 (.4420 January 2014). CU7 is was the first version with official support for Lync 2013.

All versions tested can connect to the Lync systems that have SSL 3.0 deactivated. But, there is an interesting trivia. TLS 1.0 was also referenced as SSL 3.1, and there is no clear definition of the handshake or better said there are more ways how to implement the handshake. The trivia is that the client does not behave consistently.

You can see clearly that the connection gets announced as SSL 2.0 in the first client Hello, but with TLS 1.0 as protocol. With this the client also announces several outdated and insecure ciphers. The server nevertheless choses the strongest cipher from its perspective, but unfortunately this still is a cipher that uses RC4, therefore it seems that you should not disable that on the server side.

All subsequent connection attempts will directly announce a pure TLS 1.0 connection, interesting behavior. In both cases a TLS 1.0 connection will be negotiated with a TLS_RSA_WITH_RC4_128_SHA cipher. This is not the strongest encryption on the market today, it is rather weak. Apparently, Windows CE 6.0 does not support AES, and you also do not even should start to think about perfect forward secrecy, although Diffie/Hellman ciphers, such as DHE-RSA could be used with this protocol in theory if it had been implemented.

Factory Reset
There is another important point. If you factory reset a device the firmware used previously before the last update will be activted again. You cannot determine which one it will be before you do it, see http://blog.schertz.name/2014/06/resetting-polycom-phones/ for details. If you do not have a DNS record configured for ucupdates-r2.<sip domain> so that the device can obtain an update before the first logon attempt you need your device to be able to logon before it can update itself again. So in the worst case the firmware that was installed in the factory must support TLS 1.0. I can only talk about versions down to CU5 (March 2012) for the Aries series (and to be more specific I only have Polycom CX600 and CX3000 at hand), all your experiments are at your own risk. In case that something goes wrong you are on your own. I do not take any responsibility for it!

Update 1
I just came across another post by Richard Brynteson who finally also tested Aries phones. See http://masteringlync.com/2014/10/23/poodle-testing-results-for-lync/ for his test result matrix with several Lync clients and platforms.