Padding Oracle On Downgraded Legacy Encryption - kurz POODLE (CVE-2014-3566) beschreibt einen Angriff auf das Protokoll SSL 3.0, welches ein Vorgängerprotokoll der aktuellen Protokolle TLS 1.x ist. SSL 3.0 ist veraltet, TLS 1.0, 1.1 und 1.2 spezifiziert und schon lange implementiert, bessere Verschlüsselungsalgorithmen inklusive. Es gibt also keinen Grund mehr, SSL 3.0 einzusetzen, wenn sichergestellt ist, dass alle Komponenten einer Applikation mindestens TLS 1.0 unterstützen.

Dies ist für Soft-Clients, die unter Windows Vista/Server 2008 oder neuer laufen, kein Problem, somit auch nicht für Lync 2010/2013 (Server und Client). Aber wie sieht es mit der Lync Phone Edition aus? Die auf einer ARM-Plattform aufsetzenden Geräte laufen unter Windows Embedded CE 6.0. Wie sieht es also aus mit der Deaktivierung von SSL 3.0 in Bezug auf Desktop-IP-Telefone mit Lync Phone Edition? Das ist die Frage, vor der ich stand.

Man kann es einfach ausprobieren, hier sind ein paar Hintergrundinformationen, die ich bisher nicht gefunden habe. Daher nun der Artikel.

Windows/Lync Server/Client
Die Deaktivierung auf Windows Servern ist hinreichend beschrieben, hier einige Links zu Seiten von Microsoft.

• Microsoft-Sicherheitsempfehlung 3009008: https://technet.microsoft.com/de-de/library/security/3009008.aspx
• Deaktivieren von PCT 1.0, SSL 2.0, SSL 3.0 oder TLS 1.0 in Internet Information Services: http://support.microsoft.com/kb/187498/de
• AS: 59.-63. SSL 2.0 / SSL 3.0 / TLS 1.0 / TLS 1.1 / TLS 1.2 verwenden: http://blogs.technet.com/b/iede/archive/2010/09/27/as-59-63-ssl-2-0-ssl-3-0-tls-1-0-tls-1-1-tls-1-2-verwenden.aspx

HLB
Hat man die notwendigen beschriebenen Maßnahmen umgesetzt ist Lync erst einmal sicher. Setzt man Hardware Loadbalancer ein, sollte man auch diese im Blick behalten, genauso wie den Reverse Proxy für den externen Zugriff mittels Lync Edge Server. Bei Nutzung der Application Delivery Controller von F5 Networks sieht das so aus wie in Solution 15702 beschrieben, ab BIG-IP Release 11.5 ist SSL 3.0 standardmäßig abgeschaltet:

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

Lync Phone Edition
Bleibt die Frage: Was machen wir mit den Tischtelefonen von Aastra, HP, Polycom CX und LG Nortel? Zunächst einmal muss man verstehen, dass das Problem behoben ist, wenn Client oder Server die Nutzung von SSL 3.0 unterbinden. Es gibt also keinen zwingenden Grund, die Telefone anzupassen. Die Frage ist, ob das verwendete Windows Embedded CE 6.0 TLS 1.0 unterstützt. Bei der Gelegenheit kann man auch noch einen Blick auf die Cipher Suites werfen.

Ich habe mir konkret den SSL/TLS-Aufbau des CU6 (.4100 von Juni 2012), CU7 (.4363 bzw. .4372 von Dezember 2012) und CU11 (.4420 von Januar 2014) angesehen. CU7 ist die Mindestversion mit Support für Lync 2013.

Alle getesteten Versionen können sich mit Systemen verbinden, bei denen SSL 3.0 deaktiviert ist. Es gibt aber dennoch eine interessante Kleinigkeit. Da TLS 1.0 eigentlich so etwas wie SSL 3.1 war, gibt es keine saubere Definition für den Handshake bzw. es sind mehrere zugelassen und interessanterweise verhält sich der Client nicht einheitlich.

Man sieht recht gut, dass beim ersten Client-Hello die Verbindung als SSL 2.0 announced wird, aber mit TLS 1.0 als Protokoll. Entsprechend werden auch etliche veraltete und unsichere Ciphers mit angeboten. Der Server wählt aus diesem dann aber die aus seiner Sicht stärkste Cipher aus, leider ist das immer noch eine mit RC4, das sollte man daher in diesem Fall wohl serverseitig auch nicht abschalten.

In allen nachfolgenden Verbindungsversuchen wird direkt eine reine TLS 1.0-Verbindung angeboten, ein interessantes Verhalten.
In beiden Fällen wird am Ende aber eine TLS 1.0 Verbindung mit TLS_RSA_WITH_RC4_128_SHA ausgehandelt. Nicht gerade das stärkste an Verschlüsselung das auf dem Markt ist. Offensichtlich unterstützt Windows CE 6.0 aber kein AES, an Perfect Forward Secrecy ist auch nicht zu denken, obwohl die Diffie-Hellman Ciphers, z.B. eine DHE-RSA, theoretisch auch in diesen Protokollversionen machbar wären.

Factory Reset
Ein wichtiger Punkt noch. Bei einem Factory Reset wird die Fimware geladen, die vor dem letzten Update installiert war, welche das genau ist lässt sich vorher nicht genau sagen, siehe auch http://blog.schertz.name/2014/06/resetting-polycom-phones/. Wenn man keinen DNS-Eintrag ucupdates-r2.<sip domain> konfiguriert hat, damit das Gerät vor einem Anmeldeversuch ein Update durchführen kann, ist man darauf angewiesen, dass das Gerät sich zunächst anmelden kann, bevor es ein Update bezieht. Es muss also im Zweifelsfall mit seiner Originalfirmware TLS 1.0 unterstützen. Ich kann nur Aussagen ab CU5 (März 2012) für die Aries Serie (genaugenommen nur für Polycom CX600 und CX3000) treffen, alle Experimente geschehen auf eigene Gefahr, meine Aussagen sind im Falle eines Falle keine belastbare Aussage, ich übernehme für nichts eine Garantie!

Update 1
Ich bin eben nochüber einen Post von Richard Brynteson gestolpert, der nun auch noch Aries LPE Telefone getestet hat. Unter http://masteringlync.com/2014/10/23/poodle-testing-results-for-lync/ ist seine Matrix mit Testergebnissen für verschiedene Lync Clients und Plattformen zu finden.