POODLE and Lync Server 2013

[UPDATE: 10/30/2014 – Microsoft has issued a statement that they are disabling SSL 3.0 in Office 365.]

[UPDATE: 11/20/2014 – Here are the test results.]

Starting on December 1, 2014, Office 365 will begin disabling support for SSL 3.0. This means that from December 1, 2014, all client/browser combinations will need to utilize TLS 1.0 or higher to connect to Office 365 services without issues. This may require certain client/browser combinations to be updated.


Let me start by saying I’m not a crypto genius.  This post is based on what I’ve been able to figure out based on my own research, talking to others and shouldn’t be considered the gospel.  If/when Microsoft releases an official statement, I’ll update this, eat crow, whatever it takes.  If you have any insight, feel free to drop me a note at richard@masteringlync.com or leave it in the comments and I’ll add your words to this post.  Let’s call this a community post.

After a conversation with another engineer this afternoon I decided I needed to take some time to learn SSL vs TLS vs what is going on.


SSL and TLS are not same thing.  TLS replaced SSL.  For a good overview of the two feel free to check out this Wikipedia article.  So from old to new, your versions are:

SSL2, SSL3, TLS 1.0 (sometimes referred to as SSL3.1), TLS 1.1, TLS 1.2.  TLS 1.3 is in draft but not yet available.

SSL 3 came out back in 1996.  I honestly had no clue it was that old.

Why Do We Care

Google announced four days ago a security vulnerability called POODLE which allows both a man in the middle attack by taking advantage of TLS Failback.  Essentially, every modern browser and server supports TLS 1.2 and would prefer that by default.  But just about every device still has SSL 3.0 enabled.  So the man in the middle attack basically makes the client unable to use TLS 1.2, TLS 1.1 or TLS 1.0 and go back to SSL 3.0.  Once there, apparently it easy to crack SSL 3.0.  According to this article (https://www.openssl.org/~bodo/ssl-poodle.pdf) it can take on average 256 requests using the BEAST attack to decrypt one byte of encrypted information.  Rinse and repeat you have the encrypted content.  I think sometimes being a crypto guy would be fun!

What has Microsoft said?

Thus far, not too much.  At this time, the only item I’ve found is this article:


It recommends to disable SSL 3.0 but it doesn’t call out Lync or Exchange.

What To Do?

Ideally we would just disable SSL 3.0 and never have the issue but it’s not that simple.  Based on everything I’ve read, Windows XP doesn’t support anything past SSL 3.0 – at least in the browser level.  It appears once IE7 was installed TLS 1.0 exists at the OS level.

So can we disable SSL 3.0 in Lync?  Based on my testing, I would say yes.  In my lab as a test, I have disabled SSL 3.0 on my Edge, Front-End, Reverse Proxy (IIS/AAR) and OWAS server and ran through a laundry list of tests and it works fine.  Additionally, Lync Server 2013 supports FIPS compliance (http://technet.microsoft.com/en-us/library/gg398577.aspx) and SSL 3.0 must be disabled for FIPS compliance so I think that is a tacit consent of support for disabling SSL 3.0.  As of this post, I haven’t tested Aries or other phone vendors to make sure those work as expected.

So let’s say we can do this.  Here are a few things you would need to be aware of.

Windows 2008 R2 supports TLS 1.1 and TLS 1.2 but it wasn’t enabled by default.  Below are the scripts to enable TLS 1.0, TLS 1.1 and TLS 1.2 can be found here:

[UPDATE: This information taken from here and here.  Looking for an official document of what was enabled by default in 2008 R2 still.]


Windows Server 2012 and Windows Server 2012 R2 have TLS 1.0 and 1.2 enabled by default, along with SSL 3.0.

To disable SSL 3.0 and 2.0  you can use these:

# Disable SSL 3.0 (PCI Compliance) and enable “Poodle” protection

md ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server’ -Force

New-ItemProperty -path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server’ -name Enabled -value 0 -PropertyType ‘DWord’ -Force

# Disable SSL 2.0 (PCI Compliance)

md ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server’ -Force

New-ItemProperty -path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server’ -name Enabled -value 0 -PropertyType ‘DWord’ -Force


You will need to reboot the server when completed.


If you want to test your server and make sure SSL 3.0 is actually disabled, you can use this site:



That test only works if your server is on Port 443.  If you have a single IP Edge server, you will need to use OpenSSL to test.

openssl.exe s_client -connect sip.contoso.com:5061 -ssl3

openssl.exe s_client -connect sip.contoso.com:5061 –ssl2

I hope that helps.  Again, if you have more to add, please let me know via e-mail or comments.


Scripts for Enabled/Disabling SSL in Windows comes from here.  This script also changes the crypto order to enable Perfect Forward Secrecy.  I don’t know if Lync cares about that part or not.  More testing needs to happen.


15 comments on “POODLE and Lync Server 2013”

  1. soder Reply

    The community is still waiting for the official Certificate support whitepaper from Microsoft. Ok, we dont hold our breath, as we know this is MS, the dont react fast.
    Well, hmm… right. MS in fact never admitted to release such document, but lets state this as a problem: there is simply no damn document for Lync 2010 since 4 years now.. of course this means not for Lync 2013 as well.

    The only thing is a lame 5 year old prehistoric document from Rick Kingslan: Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2 (http://bit.ly/1x3vrbp)
    This one is from the OCS 2007 R2 era, some content is deemed to be outdated, and anyway, lets be honest: who in their right mind would base any planning on a document, that was not written for the version we are using today in 2014??? I wont!

    Lync server is far the most picky MS server software, in terms of certificates. Do any change in your PKI, and Lync will probably die 5 mins later (or worst case during the night). If Lync survives it (ususally wont..) you can be assured the change wont harm anything else. Yes, the situation is as bad, literally.

    Just some questions from certificates topics:
    – does Lync 201(0/3) support SHA256+, like SHA384 / SHA512 for the Root CA, or the end-entity certificate? Hmm? Seems not really: http://ucken.blogspot.co.uk/2013/12/schannel-errors-on-lync-server.html –> SHA512 and TLS 1.2 just don’t play nice together
    – what about TLS 1.0+ in general regarding Lync? Any broken incompatibilty issue hidden deep in some Lync webservice?
    – enhanced Lync mobility certificate security may break signin capability completely: http://support.microsoft.com/kb/2965499
    – does Lync support Perfect Forward Secrecy (PFS), and more important: enabling this will break anything somewhere in Lync services?
    – what about exocitc signature hash algorithms, that any modern MS PKI CA supports, but Lync / Exchange will break if you use such a Root CA: http://bit.ly/1vGeGF1
    – broken Lync Install wizard for internal certificates: http://lyncuc.blogspot.hu/2014/08/lync-bug-remote-certificate-is-invalid.html
    -etc. etc. etc.

    I hope my post will raise some awareness among Lync MVPs, who may apply the necessary push on MS.

    • Richard Brynteson Reply

      I agree on the lack of official documentation in terms of this and certificate support in general. I’m pushing on people I know and already have some questions out that you listed but I’ll pile on yours and see if any answers come.

    • Rick Kingslan Reply

      Soder, good to see you’re still out here busting MS’ balls. To paraphrase the immortal words of one of our past presidents, “You don’t have Rick Kingslan to kick around anymore!!” I left Microsoft in March of 29013, but at least while I was there, I responded and I put out content, right?

  2. Pingback: POODLE Testing Results for Lync

  3. Pingback: Changelog: Set-Cs2013Features.ps1 - Ehlo World!

  4. Pingback: NeWay Technologies – Weekly Newsletter #118 – October 23, 2014 | NeWay

  5. Pingback: NeWay Technologies – Weekly Newsletter #118 – October 24, 2014 | NeWay

  6. Jim Reply

    TLS is not disabled by default in Windows operating systems. the only protocol disabled by default on Windows 2008 and newer operating systems is client side SSL 2.0.

    • Richard Brynteson Reply

      According to the release notes for Windows 2008 R2 RTM it said that TLS 1.1 and TLS 1.2 were not enabled by default. I can’t seem to find that document right this moment (although there are plenty of other non-MS blogs that state that it wasn’t enabled by default). Was it enabled in a patch potentially? I’ll clear up the language regardless.

    • Richard Brynteson Reply

      This appears to be a vendor specific implementation of TLS 1.0 and not a results of the standard per-say. Based on what I’ve found, Windows isn’t effected by this.

  7. kjstech Reply

    I disabled tls 3.0 on my 2012 R2 reverse proxy. Exchange works fine (owa, activesync). Lync works fine on the Lync 2013 desktop client from outside, and we have another website we are pointing to, but that also works fine. The only issue is the Lync 2013 iphone app. It just will not connect anymore. Logs from the lync mobile app show: CFNetwork SSLHandshake failed (-9806)

    Just for kicks I put my iphone on our INTERNAL wifi network and now the error is that it does not trust the certificate. our iphones are not supposed to be on our internal wifi network (we have a seperate ssid / route for them) so thats not a huge issue but it may point out to something. We purchased our certs from GoDaddy and they are SHA256 keyed.

    • Bernd Webster Reply


      Please note, that there exist not TLS 3.0 at the moment … so I think you disabled SSL 3.0 … just a small information if other will find that one later in some years 😉

Leave a Reply

Your email address will not be published. Required fields are marked *