TLS 1.2 Enforcement

Microsoft erzwingt eine sichere Verschlüsselung über TLS 1.2 für Exchange Online, ADSync, Yammer und andere Dienste in der Cloud. Frühere Verfahren wie SSL3/TLS 1.0 dürfen als kompromittiert gelten und auch TLS 1.1 ist nicht mehr sicher genug. Der im Jahr 2008 veröffentlichte TLS 1.2-Standard sollten alle neueren Systeme anbieten und unterstützen.

Update (Feb 2022): We have started to disable TLS1.0 and TLS1.1 for the default SMTP AUTH endpoints. If you have clients that can’t use TLS1.2, they should be configured to use the opt-in legacy endpoint by now.
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/new-opt-in-endpoint-available-for-smtp-auth-clients-still/ba-p/2659652

Laut Microsoft werden immer noch viele Verbindungen per TLS 1.1 und früher aufgebaut aber auch hier arbeitet Microsoft weiter:

Dennoch gehen Sicherheit und Compliance vor, so dass diese System Verbindungsprobleme bekommen könnten. Sie sollten daher prüfen und ggfls. handeln. Diese Vorgaben sollten Sie auch für eigene Server umsetzen.

BSI: „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

Risikobewertung

Der Zwang zu TLS 1.2 kann nur pro Server und Services und nicht pro Tenant oder Kunde vorgegeben werden. Microsoft kann in der Cloud daher nicht eine "Ausnahme" für ihre Firma machen und wird das schon laufende Rollout sicher nicht stoppen. Sie müssen also sicherstellen, dass ...

  • .. alle Clients TLS 1.2 unterstützen und anbieten
    Es gibt durchaus Konfigurationen bei denen die SSL-Libraries (Schannel, OpenSSL etc.) schon TLS 1.2 "könnten" aber die Software die Verwendung nicht anfordert, eine Systemeinstellung TLS 1.2 nicht per Default einschließt oder sogar verbietet.
  • Alle Firewalls/Proxyserver TLS 1.2 umsetzen
    Es reicht hier, wenn der Proxy nach extern TLS 1.2 macht und eine Firewall den Handshake nicht blockiert oder modifiziert.

Sie müssen auf jeden Fall die Verbindungen ermitteln die heute noch nicht TLS 1.2 verwenden, obwohl Office 365 dies schon lange anbietet. Quellen hierfür sind:

Wenn Sie schon am Thema TLS 1.2 arbeiten, dann sollten Sie auch überlegen, im gleichen Zug intern den Zwang zu konfigurieren.

Immer mehr On-Premises-Dienste, z.B. Exchange 2019, SQL 2019 erzwingen schon TLS 1.2 und daher sollten alle anderen Server zumindest TLS 1.2 aktiviert haben. Exchange 2013/2016 können mittlerweile auch TLS 1.2 aber es muss in erster Stufe aktiviert und später erzwungen werden.

Wenn Sie noch Clients haben, die TLS 1.2 nicht unterstützen, dann dürften diese immer mehr Probleme bekommen.

This POODLE Bites: Exploiting The SSL 3.0 Fallback
https://www.openssl.org/~bodo/ssl-poodle.pdf

TLS 1.2 und Microsoft 365

Microsoft macht ernst und weiter unten haben ich für verschiedene Protokolle und Dienste den Status hinsichtlich TLS 1.2 Zwang dokumentiert. Aber die Story ist nicht immer problemlos. Ursprünglich war das Update schon im Dez 2017 angekündigt und dann immer wieder verschoben worden. Hier nur ein Beispiel:

Der TLS 1.2-Zwang mit Office 365 wurde mehrfach verschoben. Aus der Planung 1. März 2018 wurde dann der 15. Okt 2020)

https://support.microsoft.com/en-us/help/4057306/preparing-for-tls-1-2-in-office-365
https://admin.microsoft.com/AdminPortal/home#/MessageCenter?id=MC218794

Mittlerweile haben wir April 2021 und es ist noch nicht überall aktiv. Aber nun wird es Ernst und viele Exchange Online Server haben nach meinen Checks nur noch TLS 1.2 aktiviert.

Windows 7 nutzt per Default nicht TLS 1.2. Wenn Outlook 2020-2016 per Autodiscover auf einen Server trifft, der nur TLS 1.2 anbietet, funktioniert Autodiscover nicht. Aktivieren Sie TLS auf dem WinHTTP-Stack mit REGEDIT auf dem Client.

So sieht das in Wireshark aus, wenn Exchange zu Exchange Online TLS 1.0 anbietet, während Exchange Online TLS 1.2 fordert.

Hier war dann klar, dass der On-Premises Exchange Server noch für TLS 1.2 aktiviert werden muss. Manchmal ist die fehlende TLS1.2 Freischaltung nicht sofort offensichtlich. Hier z.B. der Fehlermeldung bei der Einrichtung eines Agenten für Exchange Modern Hybrid.

Der Fehler 1603 verschwindet, wenn Sie auf dem Exchange Server TLS 1.2 aktivieren.

Aktivieren des Exchange Online-Endpunkts für TLS-Legacyclients mithilfe von SMTP-Authentifizierung
https://learn.microsoft.com/de-de/exchange/clients-and-mobile-in-exchange-online/opt-in-exchange-online-endpoint-for-legacy-tls-using-smtp-auth
Zugang für SMTP-Client ohne TLS 1.2

Andere Anbieter mit TLS 1.2-Zwang

Microsoft ist nicht der erste Anbieter, der TLS 1.2 erzwingt:

Ich bin sicher, dass auch andere Firmen, speziell Banken, sehr zügig nachziehen.

Einführungsphasen

Mittlerweile (Mai 2022) sollten alle Clients und Server TLS 12 anbieten und verstehen aber die Praxis zeigt, dass selbst ein Windows 2016 Server mit Exchange 2016 per Default immer noch TLS 1.0 nutzt. Damit sind Sie schon bei der "Einführung" von TLS 1.2, die in mehreren Phasen erfolgt:

Hinweis: Prüfen Sie vorher, ob die Server, Produkte und Clients überhaupt TLS 1.2 unterstützt. Windows 2008 oder Windows Vista können kein TLS 1.2 und bei Windows 7/2008R2 kommt es mit dem IE11-Update mit. Windows 8/Server 2012 können TLS 1.2 aber es ist abgeschaltet. Alle aktuellen Betriebssysteme sollten TLS 1.2 können aber müssen ggfls. dafür aktiviert werden.

  1. TLS 1.2/TLS 1.3 auf den Servern aktivieren
    Zuerst würde ich Server dazu befähigen, TLS 1.2 oder sogar TLS 1.3 zu machen. Das hilft allen Clients, die per Default eh schon TLS 1.2/1.3 nutzen. Auf den Servern kann ich dann nach einiger Zeit auch nachschauen, welche Clients noch TLS 1.1 oder früher nutzen, ehe ich das sichere TLS erzwinge. Denken Sie auch an Dienste, die z.B. auf Linux mit Apache einen WebServer über OpenSSL bereitstellen.
  2. TLS 1.3/TLS1.3 auf den Client aktivieren
    Natürlich sollte ich im gleichen Zeitraum auch TLS 1.2/1.3 auf den Clients aktivieren. Das ist leider nicht immer per Default aktiv. Denken Sie auch an "Nicht Windows Clients", z.B. Programme, die auf OpenSSL aufsetzen.
  3. Analyse/Inventory
    Ehe ich einen TLS 1.2 Zwang umsetzen würde, sollte ich prüfen, wer noch TLS 1.0 nutzt. Dafür gibt es je nach System entsprechende Reportmööglichkeiten.
  4. TLS 1.2 Zwang auf Server
    Schritt für Schritt gilt es dann auf den Servern die Nutzung von unsicheren TLS-Versionen und Cipher-Versionen abzuschalten.
  5. Clients härten
    Die Lösung wird perfekt, wenn sie die Client zwingen, nur noch sichere Verbindungen aufzubauen. Damit stellen Sie sicher, dass der Client auch zu keine fremden Servern noch unsichere Verbindungen startet. Wobei dann schon hinterfragt werden sollte, wie vertrauenswürdig der Server heute noch ist. Sie verhindern aber auch ein "Downgrade" von TLS-Verbindungen durch Angreifer.

Sie starten aber aus meiner Sicht immer erst mit der Aktivierung von TLS 1.2/TLS 1.3 als erlaubtes Protokoll mit den sichereren Cypher-Suiten als Default-Protokoll.

TLS 1.2 aktivieren

Der erste Schritt ist die Aktivierung von TLS 1.2 auf den Clients und Servern. das geht klassische per Eintrag in der Windows Registrierung.

  • Kein TLS 1.1 bei Windows 2008 Server und Früher oder Windows 7 und früher oder Windows XX und früher

TLS 1.2 cannot be enabled on Windows Server 2008. You need Windows Server 2008R2 or later. Make sure you have the .Net 4.5.1 hotfix installed for your operating system, see Microsoft Security Advisory 2960358. You might have this hotfix or a later release installed on your server already. If you use Windows Server 2008R2, then make sure TLS 1.2 is enabled. On Windows Server 2012 server and later versions, TLS 1.2 should already be enabled.
Quelle https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-prerequisites

  • TLS 1.2 fähig ist nicht TLS 1.2 Default
    Ältere Versionen von Windows können zwar TLS 1.2 oder bekommen es per Update nachgeliefert aber damit ist TLS 12 noch nicht per Default aktiv.

Windows 8.1, Windows Server 2012 R2, Windows 10, Windows Server 2016, and later versions of Windows natively support TLS 1.2 for client-server communications over WinHTTP. Earlier versions of Windows, such as Windows 7 or Windows Server 2012, don't enable TLS 1.1 or TLS 1.2 by default for secure communications using WinHTTP. For these earlier versions of Windows, install Update 3140245 to enable the registry value below, which can be set to add TLS 1.1 and TLS 1.2 to the default secure protocols list for WinHTTP.
https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client#bkmk_winhttp

Die Steuerung erfolgt wieder über Registrierungsschlüssel.

tls.1.2.reg - Addiert TLS 1.2 Support aber ändert nicht an SSL3, TLS 1.0/1.1 oder TLS 1.3
tls.12_13only.reg.txt - Aktiviert TLS 1.2/1.3 und deaktiviert TLS 1.1 und niedriger.
Nach dem Download die Extension".txt" entfernen. Eventuell müssen Sie die Text-Datei mit Notepad öffnen und als ANSI statt UTF-8 speichern.

Windows Registry Editor Version 5.00

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

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

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

Für das NET 2.0 Framework, insbesondere Exchange, kann eine Änderung der NET-Defaults noch erforderlich sein.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
“SystemDefaultTlsVersions”=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

Wenn Sie aber schon dran sind, dann können Sie ihren Client ja auch gleich ein neues "Default Protokoll" zuweisen. Die Wert werden wieder als BIT-Maske verwaltet.

DefaultSecureProtocols-Wert

DefaultSecureProtocols-Wert

Protokoll aktiviert

0000000000001000

0x00000008

Standardmäßiges SSL 2.0 aktivieren

0000000000100000

0x00000020

Standardmäßiges AKTIVIEREN von SSL 3.0

0000000010000000

0x00000080

Standardmäßiges Aktivieren von TLS 1.0

0000001000000000

0x00000200

Standardmäßiges Aktivieren von TLS 1.1

0000100000000000

0x00000800

Standardmäßiges Aktivieren von TLS 1.2

An by Default

An by Default

TLS 1.3

Damit ist zwar TLS 1.1 und älter noch möglich aber der Client verwendet schon mal per Default TLS 1.2.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000A80

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000A80

Diese Einstellung ist auch für Autodiscover mit Outlook auf Windows 7 relevant, wenn der Server nur TLS 1.2 erlaubt.

Die Einstellungen für den Internet Explorer sind wieder an einem eigenen Ort. Die folgenden Einstellungen erlaubten TLS 1.1 und TLS 1.2

Windows Registry Editor Version 5.00

[HKEY_CURRENT_User\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"SecureProtocols"=dword:00000A80

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings]
"SecureProtocols"=dword:00000A80

Die Einstellungen können Sie natürlich auch per Gruppenrichtline verteilen.

TLS-Verwendung analysieren

Sie fangen damit an, dass die internen Server TLS 12 anbieten und sie dann überwachen, wer trotzdem noch TLS 1.1 oder früher verwenden. Dazu müssen Sie natürlich intern entsprechende Quellen anzapfen, z.B.:

  • IISlogs
    Sie können mittlerweile den IIS anweisen, die TLS-Version zu protokollieren.
    New IIS functionality to help identify weak TLS usage https://www.microsoft.com/security/blog/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/ 
  • SChannel-Logging
    Auf Windows nutzen die meisten Dienste die SSL-Library von Windows. Sie können mittels CAPI2-Debugging auch die TLS-Dienste erkennen, die nicht mit HTTP.SYS arbeiten.
  • Exchange SMTP Logs
    Wenn Sie in den Exchange SMTP-Logs schauen, dann finden Sie hier entsprechende Strings mit dem Hinweis auf die verwendete TLS-Version, z.B. "TLS protocol SP_PROT_TLS1_0_SERVER", "TLS protocol SP_PROT_TLS1_1_SERVER´". "TLS protocol SP_PROT_TLS1_2_SERVER" oder auf dem Client "TLS protocol SP_PROT-TLS1_0_CLIENT", "TLS protocol SP_PROT-TLS1_1_CLIENT", "TLS protocol SP_PROT-TLS1_2_CLIENT"
  • Exchange Message Header
    Bei einer empfangenen Mails scheiben alle Mailserver eine "Receivedby"-Zeile in den Header der Mail, in dem auch die TLS-Version hinterlegt ist. z.B.
Received: from DBAEUR03FT011.eop-EUR03.prod.protection.outlook.com
 (2603:10a6:4:7b:cafe::ca) by DB6PR0601CA0003.outlook.office365.com
 (2603:10a6:4:7b::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.20 via Frontend
 Transport; Sat, 26 Nov 2022 11:38:04 +0000
Received: from 178.239.66.120 by netatwork.cloud.nospamproxy.com via connector
 NSP Cloud-Connector (Tls12, Aes256, Sha384, DiffieHellmanEllipticKey384);
 Sat, 26 Nov 2022 11:38:01 GMT

Zuerst "ertüchtigen" sie allen Client für TLS 1.2, dann schauen Sie nach, wer noch übrig bleibt ehe Sie dann TLS 1.2 erzwingen und die alten Verfahren unterbinden.

Am einfachsten kann die ein Anwender beim Aufruf einer Webseite testen, da mittlerweile die meisten Browser bei TLS 1.1/1.0 sogar warnen.. Der Browser verbindet sich mit dem Server und ein entsprechend konfigurierter Server kann auswerten, welche Verschlüsselungsverfahren der Client anbietet. Wenn der Browser keinen eigenen TLS-Stack mitbringt, sondern die vom Betriebssystem bereitgestellten Dienste nutzt, dann können Sie mit diesen Seiten schnell prüfen, welche Verfahren ihr Browser kann.

Das hilft natürlich für andere Protokolle wie z.B. FTPS, SSH, IMAP4S. Diese Dienste nutzen nicht WinHTTP sondern SCHANNEL.

Tod durch TLS 1.2

TLS 1.2 stellt höhere Anforderungen an die CPU und erfordert die Implementierung in der Software. Solange eine Software vom Hersteller noch gepflegt wird, könnte ein Update auch TLS 1.2-Support bringen. Es gibt aber sehr viele Produkte, die nicht mehr in der Wartung sind und aufgrund des Alters auch noch nichts von TLS 1.2 wissen. Solange Sie die Server noch selbst betreiben, können Sie unter Schwächung der Sicherheit auf den TLS 1.2 Zwang verzichten. Aber sie können sicher sein, dass mehr und mehr Produkte TLS 1.2 als Default umsetzen. Schon heute gibt es Produkte , die noch gar nicht so Alt erscheinen aber mit TLS 1.2 nicht mehr funktionieren.

  • Aries/Lync Telefone
    Hier tut es wohl am meisten weh, denn Telefone haben oft eine deutlich längere Lebensdauer als ein Smartphone oder PC. Aber auch hier ist nach 5 Jahren Support Schluss und mit dem Auslaufen des Support im April 2018 gibt es keine Funktionsupdates mehr. Microsoft wird schon wissen, warum Sie den TLS 1.2-Zwang in Office 365 vom März auf Oktober 2018 verschoben haben. So umgeht man die Entwicklung einer neuen Firmware
    Unter die Telefone fällt auch mein altes LG/Nortel IP 8540, CX700 - (Tanjay), welches nun nur noch als Türstopper fungiert.
  • Gigaset Maxwell 10
    Kein zertifiziertes Gerät aber Skype und Teams für Android liefen darauf, bis Office 365 dann TLS 1.2 erzwungen hat. Das Android 4.4 kann das noch nicht.

TLS 1.2 Support

Eine höhere Sicherheit erfordert, dass alle Server und Clients die entsprechenden Dialekte auch verstehen und unterstützen. Microsoft kann gerne auf ihren Server TLS 1.2 als Mindestversion voraussetzen. Für die Anwender ist erst einmal wichtig, dass ihre Client auch TLS 1.2 spricht. Es gibt mehrere Punkte, die mit hier einfallen:

  • Fehlender TLS 1.2 Support
    Je älter ein Client oder eine Software ist, desto eher ist es möglich, dass der dort vorhandene Code noch gar kein TLS 1.2 unterstützt und nur die schlechteren Varianten integriert hat
  • TLS 1.2 deaktiviert
    Es gibt durchaus Umgebungen, in denen TLS 1.2 nicht genutzt werden soll oder kann und man auch auf dem Client über eine entsprechende Konfiguration verhindert hat, dass der Client TLS 1.2 anbietet oder akzeptiert. Dann kann der Server ruhig TLS 1.2 zusätzlich anbieten. Der Client bleibt auf der früheren Version wenn der Server es auch noch unterstützt.
  • Proxy-Server
    Die meisten HTTPS-Verbindungen aus Firmen werden über einen HTTP-Proxy geleitet, welcher zusätzliche Filter und Authentifizierungen durchführt. Speziell wenn der Proxy "reinschauen" will, kann er das mit einem eigenen Zertifikate natürlich machen. Der Weg zwischen Client und Proxy kann dabei weiterhin TLS 1.1 oder älter verschlüsselt sein, zumindest solange Microsoft kein Zertifikat-Pinning oder HSTS einfordert. Der Proxy muss aber Richtung Office 365 ab dem Stichtag auf jeden Fall TLS 1.2 unterstützen

Gerade Firmen, die heute schon Office 365 nutzen, sollten sehr schnell die Anwender von unklaren Systemen darum bitten, die TLS 1.2 Funktion zu testen. Hierzu gibt es im Internet entsprechende Seiten, die der Anwender einfach ansurfen kann und dann einen Bericht über die Fähigkeiten des Browsers erhält:

Beide Seiten prüfen die TLS-Möglichkeiten des Clients.

Browser Support

Die meisten Programme und Dienste auf der Windows-Plattform implementieren SSL/TLS nicht selbst sondern nutzen natürlich die Funktionen und Module des Betriebssystem. Es gibt aber auch Lösungen, die z.B. die Module von OpenSSL nutzen. Für den Einsatz mit Office 365 müssen Sie zuerst einmal die Clients auf ihre Kompatibilität überprüfen. Hier eine Kurzfassung der Browser:

Client TLS 1.2 Support

IE9 Vista
IE9 Server 2008

Nicht verfügbar

IE 8-10 Windows 7
IE 8-10 Windows 2008

per Default deaktiviert

IE 11 Windows 7
IE 11 Windows 8.1
IE 11 Windows 2008R2
IE 11 Windows 2012R2

Ja

IE 10 Mobile auf Windows Phone 8.0

Per Default deaktiviert

IE 11 Mobile auf Windows Phone 8.1

Ok

Microsoft Edge

Alle

Chrome

Ab Version 33

Firefox

Ab Version 24 aber per Default deaktiviert
Ab Version 27

Safari Mac

Seit Version 7

Safari IOS

Seit IOS 5

Google Android Browser

Seit Android 5

Opera

Ab Version 15.18 (Presto)
Ab Version 17 (Webkit)

Probleme haben also auf jeden Fall folgende Clients:

  • Android 4.3 und früher
  • Firefox version 5.0 und früher
  • Internet Explorer 8-10 auf Windows 7 und früher
  • Internet Explorer 10 auf Win Phone 8.0
  • Safari 6.0.4/OS X10.8.4 und früher

Sie sollten also sicherstellen, dass diese Clients nicht mehr genutzt werden. Schon aus Sicherheitsaspekten dürften die meisten diese Endgeräte sowieso schon alle ausser Betrieb sein. Mit dem Zwang zu TLS 1.2 können Sie aber mit immer weniger Gegenstellen arbeiten. Als Workaround könnten Sie natürlich einen Proxy einsetzen, der TLS aufbricht und nach intern das schwache TLS spricht und nach extern mit dem Ziel per TLS 1.2 kommuniziert. Solange das Ziel kein Client-Zertifikat erfordert, ist dies möglich.

Library Support

Neben den Browsern gibt es natürlich noch viele andere Anwendungen und Libraries, die ebenfalls TLS nutzen.

Modul TLS 1.2 Support

SChannel / Vista

Nein

SChannel/ 2008

Deaktiviert KB4019276

SChannel / Windows 7/2008R2

IE11 aktiviert TLS 1.2

SChannel / Windows 8/2012

Per Default deaktiviert

SChannel Windows 8.1/2012R2/10

Aktiv

NET. Framework

3.5SP1 mit Update (3154520)
Auf Windows 7 SP1 und Windows 2008R2 SP1 ist es per Default off
Ab Windows 2012 und Windows 8.1 oder höher ist es an

WinHTTP

Ja, mit einem Update kann auch Windows 7 oder Windows Server 2008 R2 für TLS 1.2 freigeschaltet werden. Sie müssen es aber explizit noch freischalten.

OpenSSL

Ja

Windows Phone 6

Unterstützt maximal TLS 1.0

An der Tabelle kann man schon sehen, dass ein Windows 7 Client oder Windows 2008R2 Server ohne IE11 kein TLS 1.2 machen und selbst Windows 8 und Windows 2012 per Default TLS 1.2 deaktiviert haben.

Wenn Sie sich die Liste der Clients und Browser aber mal anschauen, dann ist TLS 1.2 nicht wirklich etwas "Neues" sondern sollte in den meisten Systemen schon vorhanden sein. Auf einigen Systemen wird man es noch aktivieren müssen. Aber die Systeme, die kein TLS 1.2 können, sind eigentlich auch nicht mehr sicher genug, um sich im Internet zu bewegen.

Die meisten Windows-"Clients", also auch ein Outlook oder Skype for Business nutzen die vom Betriebssystem bereitgestellten Funktionen und haben keinen eigenen "TLS-Code". Anders sieht es natürlich bei Programmen wie z.B. Putty, OpenVPN, Thunderbird etc. aus, die "Plattformunabhängig" dann auf OpenSSL oder andere DLLs verweisen.

TLS 1.2 und Server

Die meisten Windows Applikationen und Server nutzen entweder die WINHTTP/Scannel-Library des Betriebssystems oder OpenSSL oder eigene Bibliotheken. Daher ist es erst einmal wichtig zu wissen, welche Windows Server Version welche TLS-Version unterstützt.

Die Nutzung von SHA512 Zertifikaten bedarf weiterer Aktionen. Siehe KB2973337

OS-Version TLS 1.2 Bemerkung

Windows 2003 und früher

Not Supported

Meines Wissens gibt es kein Update von Microsoft für die Nutzung von TLS 1.2. Sie können natürlich andere Produkte nutzen, die eine eigene SSL/TLS-Implementierung z.B. auf OpenSSL mitbringen und damit TLS 1.2 unterstützen.

Windows 2008 SP2

Not Supported by Default

TLS 1.2 erfordert die Installation eines optionalen Updates.

Windows 2008 R2 SP1

Supported aber Disabled by Default

TLS 1.2 ist zwar schon im Code hinterlegt aber nicht aktiviert. Vor der Aktivierung per RegEdit sollten Updates geprüft werden.

Windows 2012

Enabled by Default

TLS 1.2 sollte ohne weitere Einstellung aktiv sein. Aber prüfen sie Updates.

Windows 2012 R2

Enabled by Default

TLS 1.2 sollte ohne weitere Einstellung aktiv sein. Aber prüfen sie Updates.

Windows 2016+

Enabled by Default

TLS 1.2 sollte ohne weitere Einstellung aktiv sein. Aber prüfen sie Updates.

Auf dem Betriebssystem setzen dann die Windows Diensts auf.

Hinweis: TLS 1.2 schreibt nicht die verwendeten Cipher-Suites vor. Die Aktivierung von eliptischen Kurven und deaktivierung von RC4 sind andere Einstellungen

TLS 1.2 und Services

Nachdem wir nun Betriebssysteme, Browser, Clients und Bibliotheken betrachtet haben, bleiben noch die Server übrig. Auch wenn Dienste auf Windows sich auf SCHANNEL oder die CryptoAPI-Funktionen des Betriebssystems stützen, so kann ein Entwickler über die Parametrisierung der Aufrufe bestimmte Optionen erzwingen oder auch verbieten.

Für Sie als Betreiber ist es natürlich auch interessant, zu gegebener Zeit ebenfalls TLS 1.2 vorzuschreiben

Produkt TLS 1.2 IIS

IIS

Ab Windows 7/2008R2

Der IIS ist eine Rolle des Betriebssystems und damit von der Version und den Komponenten des Betriebssystems abhängig.

Exchange Server

Ja

Exchange nutzt TLS in verschiedener Hinsicht. Zum einen ist es Server und wird von Clients über POP, IMAP, SMTP, HTTP angesprochen. Weiterhin ist der Exchange Server selbst "Client", wenn er per SMTP Mails zu anderen Servern sendet oder per Kalender Federation oder eine Postfachmigration mit anderen Exchange Server spricht. Bei Exchange ist das Betriebssystem darunter ein limitierender Faktor. Exchange 2010 kann noch auf Windows 2008 installiert werden und dort ist TLS 1.2 nicht verfügbar. Ansonsten kann es aktiviert werden.

AADConnect/
ADSync

am 30.7.21 erzwungen

Der Dienst verbindet sich per HTTP mit dem AzureAD um die Identitäten zu verwalten. Er hat bis Version 1.1.614.0 nur TLS 1.0 als Default genutzt. Ich bin sicher, dass er natürlich auch TLS 1.2 nutzt, wenn der Server es vorschreibt. Aber aus Sicherheitsgründen, speziell beim Einsatz mit der Funktion Office 365 Password Sync, sollten Sie TLS 1.2 vorschreiben.

Achtung: 30.6.2021: TLS 1.2 Zwang. Mindestversion 1.4.38.0 vom 9.12.2019 erforderlich

Azure DevOps

 31. Jan 2022

SQL Server

Ja mit Updates

Beim SQL-Server unterstützt Microsoft seit SQL2008SP4, SQL2008R2 SP3, SQL 2012SP2, SQL20014RTM auch TLS 1.2. Details dazu finden Sie in folgendem Artikel.

Skype for Business 2015

Ja ab CU5 HF2 auf Windows 2012 mit KB3140245+

TLS 1.0 und 1.1 können deaktiviert werden, wenn Sie einige Dinge beachten:

Wichtiger ist aber noch TLS 1.2 zu aktivieren, wenn der Server mit der Cloud sprechen soll, denn wenn dort TLS 1.2 erzwungen wird aber ihr Server noch kein TLS 1.2 anbietet, dann kommt die Verbindung nicht zustande

Skype for Business 2019

TLS 1.2 Zwang

Mit Skype for Business 2019 Server unterstützt Microsoft nur noch TLS 1.2 und TLS 1.3

https://docs.microsoft.com/de-de/skypeforbusiness/plan-your-deployment/security/encryption

Für eine Koexistenz muss SfB 2015 daher zumindest TLS 1.2 unterstützen.

Teams

Pending

Die Verpflichtung, dass alle Clients eine Verbindung zur Cloud per TLS 1.2 aufbauen müssen, wurde immer wieder verschoben. Viele Clients bieten TLS 1.2 schon an und es kann eine TLS 1.2 Verbindung etabliert werden. Aber noch sind nicht alle Clients kompatibel.

Ein Teams-Client nutzt für die Signalisierung natürlich TLS 1.2 aber die Medienübertragung RTP/TCP über STUN/TURN nutzte auch im Jan 2021 nur TLS 1.0.

Hier müssen Sie also bei Firewalls vorsichtig sein, wenn Sie hier TLS 1.1 oder 1.0 unterbinden

Yammer

TLS 1.2 Zwang Rollout

Siehe Admin center messages

MC126199 in Dec 2017, MC128929 in Feb 2018, MC186827 in July 2019, MC218794 in July 2020 and MC240160 in February 2021),

Teams Direct Routing

TLS 1.2 ab 3. April 2022

TLS 1.2 wird mit folgenden Cipher Suiten erzwungen.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 i.e. ECDHE-RSA-AES256-GCM-SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 i.e. ECDHE-RSA-AES128-GCM-SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 i.e. ECDHE-RSA-AES256-SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 i.e. ECDHE-RSA-AES128-SHA256

Weitere Applikationen müssen Sie natürlich individuell prüfen.

TLS und Loadbalancer

Wenn die zwischen Client und Server einen Loadbalancer steht, dann kann der natürlich auch SSL/TLS aufbrechen und eigene Zertifikate einsetzen. Dann kommen natürlich auch dessen TLS-Einstellungen zum tragen:

TLS Proxy

Es gibt natürlich immer noch Server, die kein TLS 1.2 oder höher können und daher nicht mehr von Clients erreicht werden, die TLS 1.2 als Minimum fordern. Wenn Sie die Hoheit über den Server haben, dann können Sie einen Reverse Proxy (Loadbalancer) davor schalten. Wenn es aber nur ein Server mit einem Post ist, dann ist dazu der Overhead vielleicht zu groß. Dann kann ein kleiner Proxy eine Hilfe sein, der Verbindungen mit TLS 1.2+ aufbaue und nach hinten weiter mit TLS 1.0 oder TLS1.1 kommuniziert. Sie sollten dann natürlich sicherstellen dass diese hintere Verbindung nicht abgehört werden kann. Prüfen Sie auch, ob der Server seinerseits noch Verbindungen zu anderen Servern per TLS aufbaut, z.B. LDAP/TLS. Auch hier könnte es ein Problem sein, wenn der Server kein TLS 1.2 macht während die Gegenseite TLS 1.2 fordert.

Auch auf der Clientseite könnte es hilfreich sein, mit einem TLS-Proxy die Inkompatibilität umzusetzen. Wenn ihr Client kein TLS 1.2 nutzt aber die Gegenseite TLS 1.2 erfordert, dann könnten Sie ihren Client auf einen lokalen TLS-Proxy umleiten, der die Verbindung noch per TLS 1.0/1.1 akzeptiert und ausgehend eine Verbindung zum Server mit TLS 1.2 aufbaut.

Beim Einsatz eines TLS-Proxy müssen Sie natürlich wieder die Frage der Zertifikate lösen, damit der Client bei einem aktiven Check das Zertifikat akzeptiert.

TLS Protokoll mit PowerShell

Normalerweise handeln Client und Server ein "passendes" TLS-Protokoll aus und versucht das "bester" zu nutzen. Als Client können Sie aber nicht sicher sein, ob nicht auf dem Weg jemand das "Angebot" des Servers beim TLS-Handshake absichtlich verändert, so dass Sie gar nicht wissen, was der Server kann. Sie können aber ihrerseits z.B. TLS 1.2 erzwingen und damit keine schwächeren Verfahren annehmen. Das geht z.B. wie folgt:

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12

Ab dem Moment nutzen Invoke-WebRequest und andere eben nur noch TLS 1.2. Wenn Sie aber auch ein Fallback auf schwächere Verfahren erlauben wollen, dann müssen Sie einfach mehrere Werte binär mit "oder" verbinden:

[Net.ServicePointManager]::SecurityProtocol = `
        [Net.SecurityProtocolType]::Tls `
   -bor [Net.SecurityProtocolType]::Tls11 `
   -bor [Net.SecurityProtocolType]::Tls12

Die Einstellungen gelten nur für die aktuelle Session

TLS 1.0/1.1 und Ciphers abschalten

TLS 1.0 ist wohl noch nicht geknackt aber es gibt Schwächen, die sie vermeiden, wenn Sie die alten TLS-Versionen generell unterbinden. Wenn alle Clients TLS1.2 oder höher mit entsprechenden Suites können, dann spricht nichts dagegen. Microsoft hat in der Microsoft365-Cloud schon TLS 1.2 erzwungen und sie können das auch. Auch gibt es einmal die Einstellungen getrennt nach SCHANNEL, NET-Frameworks und anderen SSL-Libraries wie OpenSSL:

Prüfen und testen Sie genau, ob diese Einstellungen in ihrer Umgebung keine Probleme verursachen.

Windows Registry Editor Version 5.00 

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

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

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server] 
"DisabledByDefault"=dword:00000001 
"Enabled"=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\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

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

Zudem können sie Clients aussperren, die ein TLS-Renegotiate nicht unterstützen.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"AllowInsecureRenegoClients"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"AllowInsecureRenegoServers"=dword:00000000

Ein weiterer Schutz besteht darin, dass ihr System die "schwachen Cipher-Suites" oder MD5-Hashes gar nicht mehr nutzt.

Windows Registry Editor Version 5.00

[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 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\RC2 56/56]
"Enabled"=dword:00000000

[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\RC4 128/128]
"Enabled"=dword:00000000

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

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

Microsoft hat auf https://learn.microsoft.com/en-us/exchange/exchange-tls-configuration?view=exchserver-2019#configure-cipher-suites-on-windows-server-2016 eine Liste von sinnvoll erlaubten CipherSuites bereitgestellt, die mit Windows 2016 per PowerShell aktiviert und deaktiviert werden können.

# Als Admin Ausführn !!!

$allowedciphersuites = @('TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384',
                         'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256',
                         'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384',
                         'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256',
                         'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384',
                         'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256',
                         'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384',
                         'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256')

foreach ($suite in (Get-TLSCipherSuite).Name) {
   write-host "Suite : $($suite)" -nonewline
   if ($allowedciphersuites.contains($suite)) {
      Write-Host "  Enable" -foregroundcolor green
      Enable-TLSCipherSuite -name $suite
   }
   else {
      Write-Host "  Disable" -foregroundcolor yellow
      Disable-TLSCipherSuite -name $suite
   }


#Elliptic Cures aktivieren
Disable-TlsEccCurve -Name "curve25519" 
Enable-TlsEccCurve -Name "NistP384" -Position 0 
Enable-TlsEccCurve -Name "NistP256" -Position 1

Weitere Links