TLS Security

Auf der MSXFAQ habe ich kein Zertifikat (Shared Hosting) aber andere Zugänge sind natürlich per SSL abgesichert, z.B. OWA, VPN, Direct Access, RDP-Gateway etc. Und da möchte ich schon einen "sicheren Zugang" haben. Zumindest sollten allzu schwache Verschlüsselungsverfahren besser nicht verwendet werden. Diese Seite soll ihnen helfen ihren aktuellen Status zu ermitteln und einfach die Sicherheit zu erhöhen.

Siehe dazu auch TLS 1.2 Enforcement

Diese Seite behandelt die verschiedenen Kryptografie-Algorithmen und Handshake-Protokolle in Bezug auf die Kompatibilität von Clients und Servern. Eine dritte hier nicht weiter behandelte Komponente sind die Zertifikate selbst. Auch hier gibt es unterschiedliche Schlüssellängen und Hash-Verfahren (SHA1, SHA2, SHA256 etc.).

Die erste Version dieser Seite hat die Aktivierung von TLS 1.2 gefordert aber ältere Stände zugelassen. Mittlerweile würde ich TLS 1.2 und höher fordern und alte Verfahren nur noch in klar bekannten Ausnahmefällen anbieten. Das Risiko, dass ein Angreifer ein "Downgrade" vorgibt, ist real.

TLS 1.2 ist Pflicht

Zumindest Microsoft macht in Office 365 zum 1. März 2018 ernst damit und erzwingt auf den Servern die Nutzung von TLS 1.2. Die früheren Varianten TLS 1.1, TLS 1.0, SSL 3.0, SSL 2.0 etc. werden abgeschaltet. Damit verhindert Microsoft, dass System zwischen Client und Server die Verschlüsselung beeinflussen, damit schwache Verfahren zum Einsatz kommen, die der Angreifer dann aufbrechen kann.

„Der Mindeststandard TLS fordert konkret den Einsatz von TLS 1.2 in Kombination mit Perfect Forward Secrecy (PFS). Alternativ kann auch bereits die Version TLS 1.3 mit PFS genutzt werden.“
Quelle: Mindeststandard des BSI zur Verwendung von Transport Layer Security (TLS) https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Mindeststandards/TLS-Protokoll/TLS-Protokoll_node.html

Aus meiner Sicht ist dieser Schritt logisch und sollte auch On-Premises als Default überlegt werden. TLS 1.2 mit sicheren Cipher-Suiten ist schon viele Jahre implementiert. Allerdings sind alte Clients vielleicht nicht kompatibel.

Weiterführende Informationen und Links zur Umsetzung habe ich auf der Seite TLS 1.2 bereit gestellt

Wie unsicher ist unsicher?

Auf der Webseite https://www.ssllabs.com/ssltest/ können Sie ganz einfach eine Web-Adresse eintragen und sehen, was passiert.

Leider ist dieser Test nur gegen Systeme möglich, die aus dem Internet erreichbar sind. Zudem ist der Test auf HTTPS beschränkt. Andere Protokolle wie SMTP, POP, IMAP, SIP, FTP,SSH etc. sind damit nicht zu testen.

BSI TR-02102-2 Verwendung von Transport Layer Security (TLS)
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html

Ein Windows 2008R2 Server, der per TMG 2010 eine Exchange OWA-Seite veröffentlicht, sieht da gar nicht gut aus:

Allerdings ist auch gut zu erkennen, dass zwei Dinge für die Einstufung als "F" zuständig sind. Der HTTP-Service bietet das SSLv2-Verfahren an und zudem erlaubt der "Man in the Middle"-Angriffe, da jemand dazwischen eine Neuverhandlung der SSL-Parameter anfordern könnte. Also Zeit zu handeln.

Der gleiche Test gegen einen Windows 2012R2 Server, auf dem Direct Access 2012 , Web Application Proxy und RRAS aktiv ist, ist schon in der Standardauslieferung deutlich sicherer:

Aber nicht jeder kann gleich alle externen Dienste auf Windows 2012R2 hochziehen. TMG2010 läuft z.B. gar nicht auf Windows 2012. Hier ist bei Windows 2008R2 Schluss. Dennoch können und sollen Sie dafür sorgen, dass die Schwächen beseitigt werden. Teilweise ist es einfach eine Konfiguration und manchmal noch ein Update (Speziell KB 977377)

Update für Windows Server 2008 R2 x64 Edition (KB977377)
http://www.microsoft.com/en-us/download/details.aspx?id=24360
Für Win2000, XP, 2008, 32bit, Win7 siehe 977377 Microsoft Security Advisory: Vulnerability in TLS/SSL could allow spoofing

SSL 3.0 und POODLE

Im Herbst 2014 wurde bekannt, dass SSL3 eine Schwäche enthält. Ein Angreifer wird zuerst versuchen, die besseren Verfahren zu stören, so dass der Client das schwächere SSL3 verwendet. Der Name POODLE (Pudel) sind die Anfangsbuchstaben von "Padding Oracle On Downgraded Legacy Encryption". Die Lösung besteht darin, dass der Server SSL3 gar nicht mehr anbietet und damit der Fallback nicht weiter möglich ist.

Alle Programme, die den Windows SSL-Stack verwenden, können so auf einmal gefixt werden. Nach der Änderung auf dem Server ist ein Neustart erforderlich. Programme, die einen eigenen SSL-Stack (z.B. OpenSSL) mitbringen, müssen separat konfiguriert werden.

Prüfen Sie aber, ob alle Clients dann auch die neuen Protokolle unterstützen. Wer z.B. den FIPS140-2 Standard nutzt, hat SSL3 schon abgeschaltet. Ein erster Hinweis kann daher eine FIPS140-2 Zertifizierung der Software sein.

Lync Server 2013 and Microsoft Exchange Server 2010 Service Pack 1 (SP1) operate with support für Federal Information Processing Standard (FIPS) 140-2 algorithms if the Windows Server 2008 R2 operating systems are configured to use the FIPS 140-2 algorithms für system cryptography. To implement FIPS support, you must configure each server running Lync Server 2013 to support it. für details about FIPS-compliant algorithms and how to implement FIPS support, see Microsoft KNeinwledge Base article 811833, "System cryptography: use FIPS compliant algorithms für encryption, hashing, and signing security setting in Windows XP and in later versions of Windows at http://go.microsoft.com/fwlink/p/?linkid=3052&kbid=811833. für details about FIPS 140-2 support and limitations in Exchange 2010, see "Exchange 2010 SP1 and Support für FIPS Compliant Algorithms" at http://go.microsoft.com/fwlink/p/?linkId=205335.
Quelle: http://technet.microsoft.com/en-us/library/gg398577.aspx 

SSL mittels "Strict-Transport-Security" beim Browser fordern

Daten über unverschlüsselte Verbindungen zu übertragen, ist sehr leichtsinnig. Ein Zugriff per SSL ist daher immer zu raten. Das Problem ist aber, dass Anwender es gerne mal vergessen ein "HTTPS" davor zu schreiben. Wenn ein Anwender also ohne SSL auf eine Webseite zugreift, macht es einem Angreifer sehr einfach die Daten mitzuschneiden. Wenn der Webseitenbetreiber den Zugang ohne HTTPS verhindert oder eine Umleitungsseite installiert, hat immer noch keine Sicherheit, da ein Angreifer einfach einen Proxy installieren kann, so dass der Anwender weiterhin per HTTP zugreift und der Proxy zum Server HTTPS macht. Als Anbieter einer Webseite können Sie dies nicht sehen.

Daher gibt es seit einiger Zeit einen Hostheader, den immer mehr Browser unterstützen. Über diesen Header können Sie als Betreiber den Browser informieren, dass eine Seite nur per SSL erreichbar ist. Ein kompatibler Browser erkennt bei einer SSL-Verbindung diesen Eintrag und fordert dann zukünftig immer SSL an. Ein Zugriff ohne Verschlüsselung sollte er verhindern. Erforderlich ist dazu, dass Sie den HTTP-Header "Strict-Transport-Security" setzen. Das geht z.B. im IIS über die HTTP Response Headers

Addieren Sie hier einfach das Feld und die gewünschten Parameter:

In dem Beispiel soll der Browser den "SSL-Zwang für die aktuelle und alle Sudomains für 126 Tage speichern. Dennoch sollten Sie ihre Anwender darin schulen, einen Blick auf das Schloss zu werfen, denn auch die Information, welche Seite nur per SSL erreicht werden kann, wird beim Benutzer gespeichert und könnte durch einen Schadcode auch wieder entfernt werden.

Risiken und Lösung

Das obige Beispiel beschreibt auch gleich die beiden größten Probleme bei schwachen Verfahren:

  • Wechsel der Verschlüsselungsverfahren auf schwache Verschlüsselungsverfahren
    Ein Knackpunkt ist, dass per SSL das Verschlüsselungsverfahren ausgehandelt wird und selbst während der Verbindung das Verfahren geändert werden kann. Das öffnet natürlich den Weg, dass ein Angreifer absichtlich ein "schwaches" Verfahren forciert und damit die Daten zwar für den Anwender verschlüsselt übertragen werden (d.h. Schloss im Browser ist geschlossen) aber mit genug Rechenleistung kann auch die verschlüsselte Verbindung doch mit einem vertretbaren Aufwand entschlüsselt werden. Ein Kostensenker beim Entschlüsseln sind hier z.B. die Highend-Grafikkarten, die bei Spielern sehr viele Polygone berechnen aber ebenso gut andere mathematische Aufgaben lösen können.
    Die Lösung besteht also daraus, zu schwache Verschlüsselungsverfahren oder den Wechsel auf solche Verfahren zu unterbinden, indem der Server bzw. der Client diese gar nicht mehr anbietet.
  • Übertragene Krypto-Schlüssel
    Als Rechenleistung noch knapper war, hat ein Client einen symmetrischen Schlüssel sich überlegt und diesen mit dem PublicKey aus dem Zertifikat des Servers an den Server gesendet. Der Key zum Ver- und Entschlüsseln ist dabei aber über die Leitung übertragen worden. Eine "interessierte Person" musste also nur an den "privaten Schlüssel" des Servers kommen, z.B.: im Rahmen einer Durchsuchung und Beschlagnahme. Und dann konnte er auch früher  z.B. mit Wireshark aufgezeichnete Verbindungen nachträglich entschlüsseln.
    Die Lösung hierbei besteht in der Nutzung eines etwas aufwändigeren Verfahrens, bei dem dieser Schlüssel nicht mehr selbst übertragen wird.

Allerdings gibt es natürlich auch ein Risiko, was so nicht so einfach zu lösen ist: Wenn der "Man in the middle" sich ein Zertifikat auf den Zielnamen ausstellen kann, welchem vom Client vertraut wird. Dies ist ein durchaus "üblicher" Weg, um ,SSL-Verbindungen aufzubrechen und wird gerne bei Proxy-Servern innerhalb von Firmen genutzt. Wenn Sie also in einer Firma an einem Firmencomputer sitzen, dann kann der Administrator dort natürlich auch einen FirmenCA als "Trusted CA" installieren und der HTTP-Proxy auf dem Weg ins Internet kann on the Fly ein Zertifikat von dieser Firmen-CA erhalten und so den SSL-Tunnel noch intern terminieren. Der Proxy kann dann natürlich die Inhalte und URLs auf Schadcode inspizieren. Firmen lassen sich so ein Vorgehen natürlich durch Betriebsvereinbarungen absichern. Aber können Sie sicher sein, das die hunderte "trusted CAs" auch wirklich alle vertrauenswürdig sind. Speziell wenn sehr viele davon in den USA stehen und dortigen Gesetzen unterworfen sind ?.

Das gleiche gilt natürlich auch auf der Seite des Serverbetreibers. Wenn hier per SSL-Offloading der sichere Tunnel vor dem eigentlichen Server schon aufgebrochen wird um dann die Daten nach "hinten" unverschlüsselt zum Server zu geben, dann ist das Transfernetzwerk natürlich ein lohnendes Ziel. Das gilt um so mehr, wenn Geheimdienste etc. sich Zugang zu eben diesen internen Netzwerken verschaffen, z.B.: indem sie WAN-Verbindungen zwischen Datencentern anzapfen.

Standard Werte

Das Einstellen der verschiedenen Krypto-Verfahren unter Windows ist ohne Helfer gar nicht so einfach. Es gibt einen Zweig in der Registrierung namens "SCHANNEL", unter dem eine ganze Menge Optionen einstellbar sind:

Aber wenn nur wenige Server mit Internet-Zugriff anpassen wollen, dann werden Sie vermutlich nicht per RegEdit oder Gruppenrichtlinien gleich alle Defaults in ihrem Forest umstellen. Das ist auch gar nicht immer so einfach, da speziell ältere Systeme vielleicht gar nicht alle Verfahren unterstützen. für Verbindungen aus dem Internet sollte aber schon gelten, dass allzu alte Clients dann nicht mehr sich verbinden können. Sicherheit bedeutet auch schwache Clients auszusperren.

Ich habe keine Tabelle erstellt, welche Version von Windows mit welchem Update, IE-Version o.ä., welche Verfahren anbietet und per Default anwendet. Es sind zudem sehr viele Kombinationen aus Protokoll (SSL2, SSL3,TLS1.0, TLS11, TLS1.2), Ciphers (RC2, RC4, AES, DES unterschiedlicher Bitlängen), Hashwerte und Key Exchange Verfahren möglich. Die Tabelle wäre sicher nicht übersichtlich. Interessanter ist aber z.B. das Programm "NarTac IIS Crypto" (https://www.nartac.com/Products/IISCrypto/Default.aspx), welche mit dem kostenfreien Werkzeug die aktuelle Standardwerte anzeigt. Hier ein Windows 2008R2 Server.

Achtung
Die "Defaults", die beim Start angezeigt werden, entsprechend NICHT den aktuellen Einstellungen. Das gleiche Programm zeigt auf einem Windows 2012R2-Server, der wie oben mit einem A-  bewertet wird, das gleiche Bild, obwohl dort SSL 2.0 z.B. nicht aktiv ist.

Sie sehen schon, dass es eine ganze Menge Einstellmöglichkeiten gibt und selbst die Reihenfolge der "SSL Cipher Suites" relevant ist. In der Reihenfolge bekommen die Clients die Verfahren angeboten und die erste Übereinstimmung wird dann genommen.

A-Rating mit Windows

Basierend auf dem obigen Test möchte ich natürlich runter von dem "F"-Rating. Auch hierbei hilft das IIS Crypto-Tool von NarTac, welches nicht nur die aktuellen Werte anzeigt, sondern auch gleich die "sichereren" Werte anwenden kann. Dazu gibt es vier Buttons:

  • Best Practices
    Diese Einstellung sollte in den meisten Fällen die allzu schwachen Verfahren abschalten ohne halbwegs aktuelle Clients zu blockieren. Wenn dann ein Client nicht mehr sich verbinden kann, dann sollten Sie erst mal prüfen, ob der Client vielleicht zu alt oder falsch konfiguriert ist.
  • PCI und FIPS 140-2
    Strengere Einstellungen für Firmen, die diese Kriterien erfüllen müssen.
  • Defaults
    Stelle alle Einstellungen wieder auf den "Standard" zurück.

Hier sehen Sie die "unsicherste" Einstellung, die auf "Best Practices" basiert. Sie schaltet die Dinge ab, die wirklich unsicher sind ohne allzu streng zu sein., Firmen, die natürlich nach FIPS oder PCI zertifiziert sein wollen, müssen schon noch etwas strenger sein.

Achtung
Die höheren Anforderungen an die Sicherheit kostet etwas mehr CPU-Ressourcen. Von bis zu 20% CPU-Last wird berichtet. Gut, wer vorher schon per Monitoring auf Durchschnittswerte zurückgreifen kann und so die Zunahme auch wirklich quantitativ erfassen kann.

Der Default schaltet auch "NULL" als Cipher ab. Das führt natürlich zu doppelter Verschlüsselung, wenn die Daten innerhalb der Verbindung verschlüsselt werden (z.B. IPSEC bei Direct Access über https oder bei MAPI über RPC/HTTP mit Verschlüsselung. Lässt man "NULL" zu, dann lässt sich CPU-Zeit sparen. Da ich das "innen drin" aber nicht sicher bestimmen kann, wähle ich hier den sichersten Weg.

Ein Problem kann dieses Programm aber nicht lösen: Die mögliche Attacke, die von https://www.ssllabs.com/ssltest/ wie folgt gemeldet wird und zur Abwertung auf "F" führt.

Sie können nun geteilter Meinung sein, ob diese Problematik wirklich so kritisch ist. Aktuell gibt es noch keine Funktion dies auszunutzen und selbst wenn kann der Angreifer die Daten wohl nicht bekommen. Er kann aber stören und durchaus unerwünschte Aktionen ausführen. Sie müssen dazu aber das Update aus KB 977377 installieren. Lesen Sie dazu die Informationen, da bestimmte Dienste (z.B. IPHTTP, ActiveSync mit Zertifikaten etc. eventuell nicht mehr gehen)

Update für Windows Server 2008 R2 x64 Edition (KB977377)
http://www.microsoft.com/en-us/download/details.aspx?id=24360
Für Win2000, XP, 2008, 32bit, Win7 siehe 977377 Microsoft Security Advisory: Vulnerability in TLS/SSL could allow spoofing

Nachdem auch dieses Update installiert ist, kommt auch ein TMG2010 auf Windows 2008R2 auf ein A-Rating.

Das Bild ist eine Momentaufnahme vom 12. Feb 2014 und kann durch umbauten unsererseits oder Veränderungen der Anforderungen durch SSLLabs aktuell anders aussehen.

Ist es nicht gefährlich den Hostname "owa.netatwork.de" so offen zu zeigen ?
Nein, denn dass ich unter "netatwork.de" erreichbar bin, ist nicht geheim und Sie könnten auch "autodiscover.netatwork.de" nehmen. Auch ein Portscan auf IP-Adressen im Umfeld meines MX-Records führt Sie zu Webservern.
Sicherheit "durch Verstecken" gibt es nicht.

A+ Rating

"A" hört sich schon sehr gut an aber ein Blick auf die Balken zeigt, dass da noch etwas Luft bis zu 100% ist. Und sie können den ein oder anderen Balken noch etwas näher an die von SSL-Labs vorgegebenen 100% bringen.

Ein A+ Rating können Sie z.B. erreichen, wenn Sie "HTTP Strict Transport Security" aktivieren. Das ist ein Eintrag im Webserver, dass er im HTTP-Header den Wert Name: "Strict-Transport-Security" z.B. auf "max-age=31536000" setzt. Ein entsprechender Clietn kann dann URLs in der Antwort von HTTP auf HTTPS umschreiben und den Zugriff verhindern, wenn Selbstzertifikate zum Einsatz kommen. (http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

Wie sie letztlich alle Balken auf 100% bekommen, hat SSL-Labs in folgendem PDF beschrieben:

SSL Server Rating Guide 2009e
https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide_2009e.pdf

Hier eine Kurzfassung

  • Protocol Support
    Hier eine 100% zu erreichen, bedeutet auf TLS1.0 und 1.1 zu verzichten und nur noch TLS 1.2 anzubieten.
  • Key Exchange
    Die Keylänge muss 4096bit oder größer sein.
  • Cipher Strength
    256bit oder höher

Es gibt zusätzlich einige Faktoren, die das Rating nach oben beschränken, selbst wenn diese drei Kriterien eigentlich erfüllt wären.

Keylänge und CryptoSuite

Um die Sicherheit einer Verbindung zu bewerten, sind daher mehrere Faktoren zu berücksichtigen

  • Kein "unverschlüsselter Zugriff"
    Damit ein Client gezwungen ist, eine Verbindung zu verschlüsseln, dass es natürlich nicht aus "Kompatibilitätsgründen" noch einen unverschlüsselten Zugang geben. Man kann geteilter Meinung sein, ob ein Zugriff auf die unverschlüsselte Verbindung bei HTTP einen Redirect auf eine verschlüsselte Verbindung anbieten sollte.

Ich würde eine automatische Umleitung nicht nutzen, da Sie den Anwender nicht zwingt, das "HTTPS" selbst einzugeben. Einen ersten unverschlüsselten Zugriff könnte an Angreifer auch auf eine andere "ähnliche" Seite umleiten. Der Neinrmale Anwender erkennt dies nicht

  • Schlüsselänge
    Das vom Server gelieferte Zertifikat enthält einen PublicKey, mit dem dann dann die später zur symmetrischen Verschlüsselung genutzten Keys gesichert ausgehandelt werden. Eine Keylänge von 768 oder gar 1024Bit gilt mittlerweile als unsicher. Besser sind hier 2048bit oder sogar 4096Bit

Achtung bei 4096bit und mehr: Nicht alle Endgerät unterstützen diese Schlüssel. Dies betrifft z.B. auch Aries-Telefone, die anscheinend mit Schlüssellängen über 2048bit Probleme haben. 2048bit ist aktuell ein passabler Kompromiss.

  • Sichere Crypto-Suite
    Der Kay sagt noch nichts über die Verschlüsselung selbst aus. Hier handeln die Clients und Server eine passende Kombination aus. Auch hier gibt es "schwache" Verfahren, die als geknackt gelten. Sowohl der Client als auch der Server bieten entsprechende Schlüsselverfahren aus. Hier kann jeder Administrator dafür sorgen, dass zu schwache Cipher-Suites nicht mehr angeboten werden.

Sie sollten heute zumindest die schwachen RSA-Suiten deaktivieren. Es kann sein, dass sehr alte Clients keine besseren Suiten unterstützen. Deswegen aber alle Clients einem Risiko auszusetzen ist der falsche Weg.

Es gibt mehrere Möglichkeiten zu prüfen, wie lange der Key eines Servers und dessen Angebotene Cipher-Suiten sind. Dazu kann man einfach den TLS-Handshake des Zugriffs per NetMon 3 den TLS Handshake mitschneiden.

In Grenzen helfen auch NMAP und OpenSSL, um z.B. das Zertifikat abzuholen oder mit NMAP auch die Cipher Suites zu erhalten.

# Verbindung zu HTTP over SSL
openssl s_client -connect www.google.com:443

# Verbindung zu SMTP Port 25 mit StartTLS
openssl.exe s_client -connect microsoft-com.mail.protection.outlook.com:25 -starttls smtp

Die Ausgabe enthält die Informationen über die Zertifikatkette und die ausgehandelte Cipher Suite aber nicht die Liste der angebotenen Cipher Suites. Das geht aber mit NMAP für Dienste, die sofort mit dem TLS-Handshake starten. Leider unterstützt NMAP kein SMTP mit STARTTLS. Das folgende Bild ist eine Momentaufnahme vom 13. Neinv 2014)

C:\Nmap>nmap --script ssl-enum-ciphers -p 443 www.google.com

Starting Nmap 6.01 ( http://nmap.org ) at 2014-11-13 10:17 Mitteleuropõische Zeit
Nmap scan report für www.google.com (173.194.39.19)
Host is up (0.016s latency).
Other addresses für www.google.com (Neint scanned): 173.194.39.16 173.194.39.20 173.194.39.18 173.194.39.17
rDNS record für 173.194.39.19: ham02s13-in-f19.1e100.net
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3
|     Ciphers (9)
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - unkNeinwn strength
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - unkNeinwn strength
|       TLS_RSA_WITH_RC4_128_MD5 - unkNeinwn strength
|       TLS_RSA_WITH_RC4_128_SHA - strong
|     Compressors (1)
|       NULL
|   TLSv1.0
|     Ciphers (9)
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - unkNeinwn strength
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - unkNeinwn strength
|       TLS_RSA_WITH_RC4_128_MD5 - unkNeinwn strength
|       TLS_RSA_WITH_RC4_128_SHA - strong
|     Compressors (1)
|       NULL
|   TLSv1.1
|     Ciphers (9)
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - unkNeinwn strength
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - unkNeinwn strength
|       TLS_RSA_WITH_RC4_128_MD5 - unkNeinwn strength
|       TLS_RSA_WITH_RC4_128_SHA - strong
|     Compressors (1)
|       NULL
|   TLSv1.2
|     Ciphers (17)
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - unkNeinwn strength
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - unkNeinwn strength
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - unkNeinwn strength
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - unkNeinwn strength
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - unkNeinwn strength
|       TLS_RSA_WITH_AES_256_GCM_SHA384 - unkNeinwn strength
|       TLS_RSA_WITH_RC4_128_MD5 - unkNeinwn strength
|       TLS_RSA_WITH_RC4_128_SHA - strong
|     Compressors (1)
|       NULL
|_  Least strength = unkNeinwn strength

Nmap done: 1 IP address (1 host up) scanned in 51.32 seconds

Wenn der Dienst aus dem Internet erreichbar ist, helfen aber auch die ein oder anderen Webseiten. Die meisten bauen eine SSL-Verbindung auf uns zeigen z.B. Zertifikate und einige weitere Kennzahlen. Leider habe ich noch keinen gesehen, der auch die angebotenen Cipher Suites ausgibt.

Sicht des Administrators

Einzelne Server lassen sich noch mit einer Software interaktiv patchen aber wer gleich eine ganze Gruppe von Servern identisch absichern will, sollte sich die Gruppenrichtlinien genauer anschauen. Die Windows 2003 Templates haben noch nicht die Einstellungen eingebaut aber ab Windows 2008 können Sie mit Bordmitteln einfach die Cipher-Suites kontrollieren. Der Pfad ist recht kurz:

Policy -Computer Confiugration - Policies - Administrative Templates - Netzwerk - SSL Configuration Settings

Der dann folgende Dialog liefert aber fast keine Unterstützung, sondern erwartet einfach, dass Sie die gewünschten Cipher-Suites in der richtigen Reihenfolge als String eintragen:

Nicht sehr bequem aber sicher und in der Regel nur einmal durchzuführen. Wenn ich über "NarTac IIS Crypto" (https://www.nartac.com/Products/IISCrypto/Default.aspx) die "Best Practices" setze, dann sind folgende Einstellungen auf einem Windows 2008R2 Server gesetzt.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\AES 128/128]
"Enabled"=dword:ffffffff

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\AES 256/256]
"Enabled"=dword:ffffffff

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
"Enabled"=dword:ffffffff

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168]
"Enabled"=dword:ffffffff

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5]
"Enabled"=dword:ffffffff

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA]
"Enabled"=dword:ffffffff

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]
"Enabled"=dword:ffffffff

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS]
"Enabled"=dword:ffffffff

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Multi-Protocol unified Hello]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Multi-Protocol unified Hello\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002]
"Functions"="TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA"

In der letzten Zeile wurden zur Lesbarkeit Zeilenumbrüche addiert, die natürlich erst raus müssen. Nutzen Sie dabei besser die Download-Version:

REG-Datei zum Download
tlssecurity.reg

Interessant sind hierbei dann Skripte und Quellen im Internet, die entsprechende Strings schon vorgeben.

Nachdem Sie die GPO gespeichert und an die Computer zugewiesen haben, müssen Sie natürlich noch etwas warten, bis die Richtlinien auch angekommen sind. Aktiv werden die neuen Einstellungen aber erst nach einem Reboot des Systems.

Sicht des Programmierers

Wenn ein Entwickler heute TLS nutzt, dann kann er dies zwar auf Basis von OpenSSL-Binaries versuchen aber ich denke dass alle Windows Entwickler die Funktionen aus dem Windows Betriebssystem verwenden. Sie sind unter Windows und insbesondere im NET-Framework enthalten. Die Aufzählung können Sie per PowerShell mal schnell ausgeben lassen:

PS C:\> [System.Enum]::GetValues([system.security.authentication.sslprotocols])
Neinne
Ssl2
Ssl3
Tls
Default
Tls11
Tls12

Wenn ein Entwickler also beim TLS-Aufbau nichts vorgibt, dann kommt "Default" zum Einsatz. Was sich dahinter versteckt steht in der MSDN

Alle .NET Versionen nutzen per Default TLS 1.0/SSL 3 ist. Leider nutzt niemand TLS 1.2 als Default. Hier müssen Entwickler also explizit auch TLS 1.2 anfordern oder anbieten.

TLS 1.2 - ja bitte, TLS 1.0/1.1 optional

Die erste Version dieser Seite hat die Aktivierung von TLS 1.2 gefordert aber ältere Stände zugelassen. Mittlerweile würde ich TLS 1.2 und höher fordern und alte Verfahren nur noch in klar bekannten Ausnahmefällen anbieten. Das Risiko, dass ein Angreifer ein "Downgrade" vorgibt, ist real.

Um bestimmte bessere Cipher zu verwenden und nicht per Default auf schwache Verfahren zu setzen, sollte jeder Client und Server überhaupt erst einmal TLS 1.1 und TLS 1.2 unterstützen. Leider ist genau das bei Windows erst ab der Version Windows 2008R2 und Windows 7 und höher unterstützt aber nicht zwingend aktiv. Windows Vista, Windows 2008 RTM und älter unterstützen schon gar kein TLS 1.1/1.2 in der SCHANNEL.DLL. Hier können Sie die Funktion also gar nicht mit den folgenden Schlüsseln aktivieren:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000

Allein das Aktivieren von TLS 1.1/1.2 stellt aber noch nicht sicher, dass die Clients und Server das Protokoll auch nutzen müssen. Sie können es aber nutzen und moderne Clients werden dies auch bevorzugt tun.

Clients und TLS

Zum TLS-Handshake gehören immer zwei. Der Client muss natürlich mindestens eines der Verfahren unterstützen, sonst kommt es nicht zum Handshake. Knifflig kann hier sowohl die Protokollbasis (Also TLS 1.0, 1.1, 1.2) sein als auch die verschiedenen Cipher-Suites. Gute Cipher-Suites helfen nicht, wenn aufgrund von SSL3 oder TLS 1.0 Schwächen ausgenutzt werden können. Wer aber TLS 1.2 erzwingt, sperrt alle Clients aus, die das nicht können. Und da gibt es schon einige Client, Sie dürfen da nicht nur an die vier bekannten Browser (IE, Chrome, Firefox, Safari) denken, sondern auch Abhängigkeiten vom Betriebssystem beachten und al die vielen sonstigen Programme, die SSL nutzen, z.B. Mailclients oder Tools basierend auf Java, OpenSSL u.a. Wenn Sie ihre öffentliche Webseite nur per SSL erreichbar machen, dann sollten Sie prüfen, ob die Spider von Suchmaschinen per SSL ihre Webseite erfassen können.

Prüfen Sie aber, ob alle Clients dann auch die neuen Protokolle unterstützen. Wer z.B. den FIPS140-2 Standard nutzt, hat SSL3 schon abgeschaltet. Ein erster Hinweis kann daher eine FIPS140-2 Zertifizierung der Software sein.

Wenn Sie selbst analysieren wollen: Einfach NetMon starten mit folgendem Filter

TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.HandShakeType == 0x1

Dann sehen Sie alle TLS Starts und darin dann auch die TLS-Version und CipherSuites.

Siehe auch MSXFAQ.DE:TLS Handshake

User Agent TLS 1.2 Forward Secrecy Stapling Session Tickets

Android 2.3.7

Nein

Ja

Nein

Nein

Android 4.0.4, 4.1.1., 4.2.2, 4.3

Nein

Ja

Nein

Ja

Android 4.4.2

Ja

Ja

Nein

Ja

Chrome 37 / OS X

Ja

Ja

Ja

Ja

Firefox 24.2.0 ESR / Win 7

Nein

Ja

Nein

Ja

Firefox 32 / OS X

Ja

Ja

Ja

Ja

Googlebot Jun 2014

Nein

Ja

Nein

Ja

IE 6/8 auf XP

Nein

Nein

Nein

Nein

IE 7 / Vista

Nein

Ja

Ja

Nein

IE 8-10 / Win 7

Nein

Ja

Ja

Nein

IE 11 / Win 7

Ja

Ja

Ja

Nein

IE 11 / Win 8.1

Ja

Ja

Ja

Ja

IE Mobile 10 / Win Phone 8.0

Nein

Ja

Ja

Ja

IE Mobile 11 / Win Phone 8.1

Ja

Ja

Ja

Ja

Java 6u45

Nein

Ja

Nein

Nein

Java 7u25

Nein

Ja

Nein

Nein

Java 8b132

Ja

Ja

Nein

Nein

OpenSSL 0.9.8y

Nein

Ja

Nein

Ja

OpenSSL 1.0.1h

Ja

Ja

Nein

Ja

Safari 5.1.9 / OS X 10.6.8
Safari 6.0.4 / OS X 10.8.4

Nein

Ja

Nein

Nein

Safari 7 / OS X 10.9

Ja

Ja

Nein

Nein

Safari 6/7/8 auf iOS 6.0.1 und höher

Ja

Ja

Nein

Nein

Outlook 2007

Nein nur TLS1.0

 

 

 

Outlook 2010

Nein nur TLS1.0

 

 

 

Outlook 2013

Ja

 

 

 

Interessant ist z.B. dass der IE7 auf Windows 7 TLS 1.2 unterstützt, aber IE8-10 auf Windows 7 nicht, obwohl alle die gleiche SCHANNEL.DLL des Betriebssystems nutzen. Anscheinend muss eine Applikation auch die DLL korrekt parametrisieren. Welche Verfahren ein Client anbietet, könnte ihnen der Hersteller sicher sagen. Meist werden Sie wohl doch mit Wireshark oder NetMon3 den TLS Handshake betrachten müssen.

Achtung:
Es gibt durchaus auch "interne Kommunikationswege", die gestört werden könnten. So gibt es Hinweise, dass ein TMG keine Reports mehr nutzen kann, wenn TLS1.0 abgeschaltet ist wurde.

Server und TLS

Bei der Betrachtung der Server gibt es natürlich den "IIS" als den Service, auf dem viele andere Dienste aufbauen. Aber neben dem IIS gibt es z.B.: den Exchange SMTP-Dienst, Lync SIP-Server und viele andere Dienste die auch auf die ein oder andere Weite TLS unterstützen. Natürlich muss auch hier das Betriebssystem die Funktion unterstützen, wenn die Software auf SCHANNEL.DLL zurück greift. Was anderes ist es, wenn die Software ihre eigene SSL-Implementierung mitbringt, z.B. über die OpenSSL-DLLs.

Bei Servern ist aber nicht nur zu beachten, welche Verschlüsselung diese gegenüber den Clients anbieten, sondern einige Server Dienste verbinden sich ihrerseits auch mit anderen Servern. So kommuniziert ein Exchange CAS-Server als Proxy auch mit Diensten auf dem Backend und auch bei der Nutzung von Kalenderfederation:E2010/2013 spricht ein Exchange CAS-Server einen Exchange CAS-Server in einer anderen Organisation an. Technisch ist der Server dabei natürlich als Client zu betrachten. Ich führe diese Besonderen Konstellationen aber dennoch hier unter Server auf.

Wenn Sie weitere Server und Versionen ermittelt haben, dann können Sie mir diese gerne mitteilen,

Server API Server-TLS Client TLS

IIS 7.5

SCHANNEL

 

 

IIS 7.5

SCHANNEL

 

 

IIS 7.5

SCHANNEL

 

 

IIS 7.5

SCHANNEL

IIS 7.5

SCHANNEL

 

 

IIS 7.5

SCHANNEL

 

 

Lync 2013

SCHANNEL

 

 

Exchange 2010

SCHANNEL

 

 

Exchange 2013

SCHANNEL

 

 

Exchange 2016

SCHANNEL

TLS 1.2

 

Nur weil eine Applikation z.B. auch TLS 1.1 und TLS 1.2 unterstützt, dann bedeutet das nicht, dass sie auch TLS1.0/SSL abschalten können. Zum einen müssen Sie sicherstellen, dass alle Clients dann auch mit TLS 1.2 umgehen können. In der Hinsicht ist z.B. Exchange ja auch selbst wie ein Client zu sehen, wenn ein Server als Reverse Proxy auf einen anderen Server zugreift.

Weitere Links