[English]Am 11. Oktober 2022 ist Patchday bei Microsoft, und auch Windows 10 wird sein monatliches Sicherheitsupdate erhalten. Vorsorglich mache ich auf ein Thema aufmerksam, was möglicherweise in einigen Stunden unter Windows 10 20H2 bis 21H2 für Ärger sorgen könnte: Microsoft deaktiviert mit dem Sicherheitsupdate für diese Windows 10-Versionen voraussichtlich TLS 1.0 und 1.1. Andererseits sieht es so aus, als ob die TLS 1.3-Implementierung unter Windows 10 Probleme bereitet. Es könnte also bei Remote Desktop-Anwendungen und allen Anwendungen, die auf TLS 1.0/1.1 angewiesen sind, Probleme geben.
Anzeige
Preview Update deaktiviert TLS 1.0/1.1
Ich hatte es bereits im Blog-Beitrag Windows 10 20H2-21H2 Preview Update KB5017380 (20.9.2022) erwähnt. Mit dem optionalen, kumulativen (Vorschau-) Update KB5017380 hat Microsoft bereits im September 2022 TLS 1.0 und 1.1 in Windows 10 Enterprise Version 20H2, Windows 10 Education, Windows 10 IoT Enterprise Version 20H2 sowie Windows 10 Version 21H1 bis 21H2 deaktiviert. Da die Änderungen der Preview-Updates im Folgemonat in die entsprechenden Sicherheitsupdates einfließen, wird zum Patchday, am 11. Oktober 2022, die Unterstützung für TLS 1.0 und 1.1 flächendeckend wahrscheinlich abgeschaltet (es sei denn, Microsoft hat bereits soviel negatives Feedback aus der Preview bekommen, dass die Funktion herausgenommen wurde).
An dieser Stelle erinnere ich vorsorglich an meinen aktuellen Blog-Beitrag Bug: Outlook stellt keine Verbindung mehr zum E-Mail-Server her (Oktober 2022). Microsoft Outlook streikt unter Windows 10, wenn TLS 1.3 verwendet wird. Microsoft schlägt als Workaround vor, die Unterstützung für TLS 1.3 zu entfernen, damit Outlook wieder synchronisieren kann.
Eine Lesermeldung zu Remote Desktop
Das Thema ist durch eine Leserrückmeldung von Antonio Francisco Vanucchi aus Brasilien bei mir erneut in den Fokus gerückt. Antonio hatte einen englischsprachigen Kommentar hinterlassen, weil er auf ein Problem gestoßen ist. Er regte an, dass ich dies im Blog aufgreife, um andere Administratoren zu warnen. Dazu schrieb er mir:
Nachdem ich das optionale Update KB5017380 auf den Arbeitsstationen meines Kunden installiert habe, funktioniert die Einrichtung von Remoteapp nicht mehr. Nachdem ich mit der URL *https://mydomain]/rdweb/feed/webfeed.aspx in Systemsteuerung/Remoteapp und Desktop-Verbindungen eingegeben habe, erhielt ich die Meldung:
"Es ist ein Fehler aufgetreten. Wenden Sie sich an den Administrator Ihres Arbeitsplatzes, um Hilfe zu erhalten.".
Antonis schreibt, dass in der Ereignisanzeige keine Fehler gemeldet wurden. Bei einer Recherche stieß er auf meinen Blog mit dem Beitrag zum Preview-Update – und er fand auch den Hinweis, dass KB5017380 TLS 1.0 und 1.1 standardmäßig auf allen Windows 10 Maschinen deaktiviert. Die Remote-App für Windows Server 2016 hängt aber, laut seiner Aussage, stark von TLS 1.0 ab. Das ist laut Antonio der Grund, warum der oben genannte Fehler gemeldet wird.
Antonio hat mir den Link auf den (bereits vor 2 Jahren erschienenen, aber noch aktuellen) reddit.com-Thread Error when adding remoteapp connection url in control panel geschickt, wo das Problem beschrieben wird.
Anzeige
Error when adding remoteapp connection url in control panel
Hello,
I have a Remote Access server set up in our domain that pushes out some applications for users. Traditionally, we have been asking users to log into the web portal to access the rdp files so they use our apps.
However, I want to simplify this by pushing them out via GPO. To test this, I used my pc (Windows 10) as a test. I went to control panel > remoteapp and desktop connections and added the url: https://[mydomain]/rdweb/feed/webfeed.aspx and I continuously get this:
"An error occurred. Contact your workplace administrator for assistance."
I can resolve that link in a browser, as it asks me for my credentials, and then downloads a file.
I can not for the life of me find anything in Event Viewer that is giving me any errors whatsoever. Nothing in system, nothing in RemoteApp and Desktop Connections. Nada.
I know it should be asking for credentials, but it doesn't even give me that option.
I tested this on one of our testbench servers (a vm) and it worked (Windows Server 2016) just fine.
Whats even more hilarious is it works on the rdp client on my mac with no issues as well!
Tested it with several other client pc's and I am getting the same thing. I'm at a loss, I have no idea on how to procceed.
Dort skizziert jemand auch den nachfolgenden Workaround. In der Techcommunity gibt es einen Eintrag vom 4. Oktober 2022, der auf das potentielle Problem hinweist.
KB5017380 Breaks RemoteApp
I installed KB5017380 on a brand new machine to bring it up to date. When it came time to set up RemoteApp, I entered an URL to my RemoteApp server and got an error that said "An error occurred. Please contact your Administrator." (paraphrased).
No information was given in Event Viewer or anywhere else. I have several other machines and they work just fine, although has no KB5017380 installed.
Googled for an answer and very few came up. In fact, only 2 article came up and they both pointed the problem to KB5017380. I then uninstalled that, rebooted, and tried RemoteApp again. RemoteApp now works!
You've been warned. This update breaks RemoteApp, or at least won't let you set up new RemoteApp connections. I hope Microsoft pulls this out and fix it before returning it back into the updates. I'm posting that information here to hopefully save you hours figuring out why you can no longer create new RemoteApp connections. Good luck!
Es gibt also zwei Fundstellen, die zu diesem Thema Informationen bereithalten.
TLS-Workaround scheitert (noch)
Antonio hat dann weiter gegraben und schrieb: Wenn Sie das Update nicht deinstallieren möchten, sollten Registrierungsänderungen das aktivieren von TLS 1.0 ermöglichen. Microsoft beschreibt den Ansatz im Support-Beitrag Managing SSL/TLS Protocols and Cipher Suites for AD FS aus dem Jahr 2021. Um TLS 1.0 erneut zu aktivieren, muss der Registrierungseditor regedit.exe über Als Administrator ausführen gestartet werden. Dann ist zum Schlüssel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocolszu navigieren. Dort muss dann ein neuer Unterschlüssel TLS 1.0 anzulegen. In diesem Unterschlüssel ist ein weiterer Unterschlüssel Client zu erzeugen und dann ein neuer DWORD Wert DisabledByDefault, auf 0 gesetzt, hinzuzufügen. Nach einem Neustart von Windows sollte TLS 1.0 wieder unterstützt werden.
Liest sich zwar ganz gut, aber Antonio schrieb mir dazu, dass dieser Ansatz bei ihm nicht funktioniert habe. Er war gezwungen, das optionale Preview-Update KB5017380 zu deinstallieren. Dann musste er das Sicherheits-Update KB5017308 vom 13. September 2022 erneut installieren, damit die Einrichtung von Remoteapp wieder funktionierte. Er hofft, dass das kommende Oktober 2022-Sicherheitsupdate das Problem bei ihm korrigiert.
Zum Update KB5017308 ist anzumerken, dass dieses für die im Artikel Windows 10 Update KB5017308 verursacht Probleme beim Erstellen/Kopieren von Dateien per GPO beschriebenen Probleme verantwortlich ist. Es bleibt also spannend, was der Oktober 2022-Patchday so bringt – jedenfalls habt ihr vorab eine Information zu möglichen Problemen. Danke an Antonio für den Hinweis.
Ähnliche Artikel:
Patchday: Windows 10-Updates (13. September 2022)
Windows 10 Update KB5017308 verursacht Probleme beim Erstellen/Kopieren von Dateien per GPO
Windows 10 20H2-21H2 Preview Update KB5017380 (20.9.2022)
Bug: Outlook stellt keine Verbindung mehr zum E-Mail-Server her (Oktober 2022)
Übersicht: TLS-Support in Windows
Anzeige
Update Aussetzen!
Auf die enthaltenen Sicherheitsupdates muss man wegen der verschärften Standard-TLS-Einstellungen nicht verzichten. Am besten die Clients/Server per Gruppenrichtlinie im Vorfeld auf den gewünschten Sollzustand bringen (z.B. TLS 1.0 und 1.1 explizit aktivieren). Es gibt sogar inoffizielle ADMX Vorlagen derer man sich bedienen kann. Diese hier enthält m.M.n. alles Wesentliche (TLS Client/Server und .NET Framework Strong Crypto):
https://github.com/Crosse/SchannelGroupPolicy
Vielleicht sollte man das hier zur Hand haben
https://www.nartac.com/Products/IISCrypto/Download
zu beachten: nartac ist leider, warum auch immer, nicht TLS 1.3 kompatibel
Das hilft zum Beispiel auch, wenn Outlook nicht mehr per POP3/IMAP/SMTP auf die Server von GMX zugreifen kann – sowohl Win7 als auch Win10. Best Practice-Button anklicken, fertig.
Wurde denn beim RDS auch TLS 1.0, 1.1 deaktiviert und TLS 1.2 aktiviert per Registry? Oder ist das aus bestimmten Gründen nicht gewollt?!
TLS 1.0 und 1.1 sind katastrophal unsicher und sollten schon seit Jahren deaktiviert sein. seit langer Zeit (20 Jahre?) gibt es TLS 1.2 und bei den neuesten Betriebssystemen endlich auch TLS 1.3, was vor allem für den Zugriff auf Webserver im Internet interessant ist, weil die MITM-Firewalls in vielen Unternehmensnetzen das (noch) nicht können.
wenn man nicht gerade mit Windows XP auf neuere Server zugreifen will, sollte es keine Probleme geben
So ist es. TLS 1.0/1.1 sollte längst deaktiviert sein.
Bei den Updates hier geht es ja eigentlich nur um Client-seitigen TLS-Support. Solange die zugegriffenen Server TLS 1.2 und 1.3 unterstützten, sollte das ja nicht mehr weiter tangieren.
Woran erkenne ich denn, welche Anwendungen bei mir auf TLS 1.0/1.1 angewiesen sind?
Testen kannst du das u. a. mittels:
– Nmap: "nmap –script ssl-enum-ciphers -p 443 myservice.contoso.com"
– SSLyze (Python) -> https://github.com/nabla-c0d3/sslyze
– PowerShell Skript -> https://www.sysadmins.lv/blog-en/test-web-server-ssltls-protocol-support-with-powershell.aspx
Danke für die Antwort.
Allerdings bin ich "Normal-Endanwender" und kein System-Administrator oder etwas in der Art. Insofern sagen mir die entsprechenden links leider wenig.
Ich nutze keine "Remote Desktop"-Anwendung(en) (mir jedenfalls nicht bewusst).
Was könnte denn so an "Allwerwelts-Software" betroffen sein?
Für die Mitleserschaft ein heißer Tipp aus einer FB-Gruppe, wo die Nacht jemand auf entsprechende Fragen mit einem Tipp zum Nartac-Tool reagiert hat.
Vielleicht hilft es.
also zumindest Firmen/Behörden/Admins sollten da nirgends blind reinlaufen, schließlich war die Abschaltung schon lange lange kommuniziert.
Wer da nix getan hat ist gelinde gesagt selbst Schuld!
Privatleute? Naja so ist das halt wenn man blindlinks Technik nutzt die man nicht versteht! Dann funzt das halt mal nicht und man muss sehen wo man bleibt.
MS hat immer wieder unvorhersehbare Lücken und Bugs,die einem vor echte Probleme setzen, diese gehört jedoch nicht dazu.
Wie immer hast Du Recht und liegt doch wieder scharf daneben.
Natürlich konnten die Firmen, Behörden, Admins sich da vorbereiten …
Und wie immer gibt es dann die berühmte Ausnahme, dass da irgend etwas übersehen wurde und plötzlich ein Anwender auf der Matte steht und meckert "geht mal wieder nicht" …
Der kluge Blogger baut vor und macht einen Artikel "Hömma, da könnte euch Admins dies und jenes drohen. Behaltet es auf dem Radar, wenn es am 12.10.2022 vorna Bild zur Morgen-Kaffee und vor der 10:00 Uhr Semmel User-Mecker gibt."
Der wirklich kluge Admin liest das und denkt "Ups, hätte ich fast vergessen gehabt, haben wir doch vor zwei Jahren schon gewuppt" – oder "heilige Scheiße, dass wäre mir doch fast durch geslippt". Ich fürchte, die wenigsten kommen mit "Ich habe nicht getan, ich Depp, wie komme ich da wieder raus …" – obwohl mich deuscht, ich hätte um Mitternacht da in einer FB-Gruppe genau diese Reaktion vernommen – und nun laufe ich in Kawissenskonflikte, ob ich hätte warnen sollen oder nicht (von wegen kein Mitleid) … ich schlimmer Finger ;-)
Nix selbst schuld. Windows Server 2016 ist noch offiziell im Support und dessen Feature/Rolle "Remoteapp" nutzt TLS 1.0
Da kann MS doch nicht einfach ein Update schicken zum deaktivieren einer noch benötigten Funktion!
OK, ich, "Endanwender", bin dumm und habe mir vor Jahren zwei, drei NAS zugelegt.
Bei diesen kann ich leider das Protokoll nicht "anheben"!
Nutze Windows 10 und wenn dort die Unterstützung von TLS 1.0/1.1 abgeschaltet wird, bzw. jetzt durch das Update lahmgelegt wird, habe ich keinen Zugriff mehr auf meine Daten!
Hat ein "oberschlauer" Luzifer oder ein anderer netter Nutzer dafür eine Lösung?
Moin Mira,
schau mal, ob es für deine NAS Firmware Updates oder generell Updates gibt.
I.d.R. bleiben Hersteller am Ball, was Sicherheitsstandards angeht.
Es sei denn, du hast dir irgendein Tschechenkonstrukt auf Wish bestellt =)
Danke für den Tip.
Leider ist das WDMyCloudMirror aus dem Firmware Support gefallen, und zwar schon recht lange. "Does not support the upgrade to OS 5"
https://support-en.wd.com/app/answers/detailweb/a_id/31757#subject103
jaa gut, alte Hardware halt. Produkte zu nutzen, die End-of-Life sind, können, müssen aber nicht funktionieren.
Schau dir mal das Tool an, was ich da in den Kommentaren verlinkt habe. Kenne es selbst nicht – aber der Beschreibung nach müsste man TLS 1.x zu- bzw. abschalten können. Vielleicht hilft es.
Danke Günter.
Derzeitige Strategie ist,
auf meinem Hauptrechner das Update blockieren, Backup.
Auf anderem Rechner Update machen und testen was da so kommt.
Geht das denn nicht ebenfalls über Systemsteuerung -> Internetoptionen -> Erweitert, indem man dort wieder die Haken bei TLS 1.0 und TLS 1.1 setzt?
Denn ausgegraut ist dort ja nichts, oder?
Ne VM mit nem OS wo TLS1/2 noch läuft? Zugriff über anderes Protokoll? TLS/1.x über Drittsoftware? Nur weil das OS das nicht mehr nativ bietet, bedeutet das ja nicht das es nicht mehr möglich ist.
Lösungen gibt es derlei viele.
Setzt dann aber vorraus das man sich damit auseinandersetzt.
Da du hier zwar als Endanwender postet. aber hier mitliest kannst du davon ja auch nicht überrascht worden sein. Bekannt und angekündigt ist das seit Monaten und wurde auch hier schon "breitgetreten"
Und bitter aber wahr: Irgendwann ist Hardware eben auch mal "EOL"
Zitat:"Und bitter aber wahr: Irgendwann ist Hardware eben auch mal "EOL""
Ja, wenn sie ausfällt, nicht vorher!
Und auch nicht, wenn es einfach ein anderer so will!
Nur weil das Haus asbachuralt ist, eine Sanierung sich nicht lohnt,
wird es nicht abgerissen.
Es wird gemacht was noch sinnvoll erscheint und
es bleibt stehen und wird weiter genutzt.
In den Release-Notes scheint das Thema nicht erwähnt zu werden. Wird das also doch nicht scharfgeschaltet? Hat das mal einer getestet?
Neee, Mira, das alte Haus wird nicht mehr genutzt, wenn es sinnvolle Vorgaben nicht mehr erfüllen kann, z.B. mit Dämmung allein nicht mehr zu verhindern ist, dass Du zum Fenster raus heizt. Da verpestest du die Allgemeinheit, deswegen muss das weg.
Zum NAS: Du kannst ja machen, was sinnvoll erscheint: Lass dir gegen Bares ein sicheres Firmware-Update programmieren. Aber das ist vermutlich teurer als ein neuer :)
Spätestens, wenn Du mit alter Hardware der Allgemeinheit Schaden zufügst, weil sich Virenschleudern einnisten können, dann muss die weg.
Bei solchen Kommentaren ….
Einfach nur dumm!
Das besagte NAS hat keinen Internetzugang! Gesperrt!
Der Rechner sitzt auch hinter einer FW und ist somit aus dem I-Net nicht ansprechbar!
Und DU schreibst nur dummes Zeug!
Schonen Tag noch.
Also, ich hatte den Eindruck, dass seine Antwort eher ironisch gemeint war.
Also bei unseren Kunden (bisher nur zwei, aber der Tag ist ja noch jung…) zerlegt das Update die komplette Verbindung zur TS-Farm (bzw. auch bei 1-Server Installationen mit Session-Broker auf einem anderen Server).
Es kommt die RDP-Fehlermeldung die man sonst angezeigt bekommt wenn man sich (fälschlicherweise) statt auf den Farm-Namen auf einen einzelnen TS verbinden will.
Kleiner Nachtrag, das Problem hängt nicht mit TLS 1.0 zusammen. Es sind die gespeicherten Zugangsdaten für die RDP-Verbindung. Gibt man das Passwort "manuell" ein, dann klappt die Verbindung.
Betroffen waren bzw. sind Verbindungen von intern als auch von extern über's RD Gateway.
KB5018410 verhindert die Verbindung mit gespeicherten Zugangsdaten. Gleiches gilt für die Oktober-Updates für Win11.
Wir nutzen RemoteApp auf Windows Server 2016 (Hier ist TLS 1.0 und TLS 1.1 bereits seit längerem über IISCrypto auf dem WebAccess Server – stellt den Feed zur Verfügung – deaktiviert)
Auf unseren Clients Win 10 21H2 mit LCU 10/22 kann ich den Fehler bei RemoteApps nicht reproduzieren.
Egal ob bereits bestehende RemoteApp Verbindung (über GPO oder manuell angelegt) noch bei neuen Usern die sich am Client anmelden, kommt es zu Problemen.
Sehr seltsam!
Der Tippgeber hat sich im englischsprachigen Blog mit einem Kommentar gemeldet. In seiner Umgebung hatte er mit dem September Preview-Update Probleme, aber mit dem Sicherheits-Update von Oktober 2022 läuft wohl alles.
Ich habe jetzt mal ein wenig getestet und mir scheint, dass mit den aktuellen Updates KEINE Änderungen bezüglich TLS passieren.
Bei mir ist der Fall das die CITRIX Workspace App bzw. die RemoteDesktop App frür AVD sich nicht mehr öffnen lassen bzw. kann keine Session mehr aufbauen. Nach DeInstallation funktioniert wieder alles.
Nur zur Ergänzung, die Diskussion hier kennst Du.
Hallo, kannt ich tatsächlich nicht allerdings betrifft das Update nicht nur CITRIX sondern auch die RDP App für Azure Virtual Desktops .
Hallo an alle Allmächtigen ;-)
Auch ich musste seit heute feststellen, dass nachdem sich mein Win 10 auf die 21H2 (Build 19044.2006) aktualisiert hat, ich plötzlich beim verbinden über Remote auf den Rechner nicht drauf komme.
Beim Clientrechner wird angezeigt: Es ist ein interner Fehler aufgetreten!
Auf dem Remoterechner komme ich nicht mal als Admin drauf, kommt nach dem anmelden: Remoteprozeduraufbau fehgeschlagen!
Bestätige ich auf ok, bin wieder im Anmeldebildschirm.
Wenn ich aber das letzte Qualitätsupdate deinstalliere läuft alles wieder.
Hat den jemand eine Idee oder kann ich irgendwie nach dem update per abgesichertem Modus irgendwas anpassen bezüglich TLS oder liegt es am was anderem?
Vielen dank in Voraus!
Achtung: verhindert ebenso Verbindungen zu NPS/Radius Server die auf 2012 R2 laufen
Beim NPS muss TLS1.2 explizit aktiviert werden, sonst gehen die Verbindungen bei 802.1x bzw. bei WPA2-Enterprise nichtmehr.
https://warlord0blog.wordpress.com/2017/02/09/tls-and-nps/
Bei mir ging folgendes wegen den TLS-Varianten unter WIN10 nicht:
– neuen Nutzer anlegen
– MS Store
– News-Feed
– Adobe Installation
Bei den Internetoptionen waren alle Protokolle ausgegraut und konnten nicht enabled werden.
Folgende Änderungen in regedit haben das Problem behoben:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings
DWORD-Eintrag SecureProtocols gelöscht
DWORD-Eintrag EnableLegacyAutoProxyFeatures = 1 hinzugefügt