Windows 10: Achtung vor einem möglichen TLS-Desaster zum Oktober 2022-Patchday

Windows[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.

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\Protocols

zu 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.


Anzeige

TLS-Workaround

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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Windows 10 abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

40 Antworten zu Windows 10: Achtung vor einem möglichen TLS-Desaster zum Oktober 2022-Patchday

  1. Mira Bellenbaum sagt:

    Update Aussetzen!

    • Anonymous sagt:

      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

  2. nk sagt:

    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?!

    • Robert Glöckner sagt:

      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

  3. 1ST1 sagt:

    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.

  4. Scyllo sagt:

    Woran erkenne ich denn, welche Anwendungen bei mir auf TLS 1.0/1.1 angewiesen sind?

  5. Luzifer sagt:

    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.

    • Günter Born sagt:

      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 ;-)

    • techee sagt:

      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!

  6. Mira Bellenbaum sagt:

    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?

    • Dennis sagt:

      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 =)

    • Günter Born sagt:

      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.

      • Mira Bellenbaum sagt:

        Danke Günter.
        Derzeitige Strategie ist,
        auf meinem Hauptrechner das Update blockieren, Backup.
        Auf anderem Rechner Update machen und testen was da so kommt.

      • Scyllo sagt:

        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?

    • Luzifer sagt:

      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"

      • Mira Bellenbaum sagt:

        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.

  7. riedenthied sagt:

    In den Release-Notes scheint das Thema nicht erwähnt zu werden. Wird das also doch nicht scharfgeschaltet? Hat das mal einer getestet?

  8. Thorsten sagt:

    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.

    • Mira Bellenbaum sagt:

      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.

  9. Jens sagt:

    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.

    • Jens sagt:

      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.

  10. Martin sagt:

    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!

    • Günter Born sagt:

      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.

  11. riedenthied sagt:

    Ich habe jetzt mal ein wenig getestet und mir scheint, dass mit den aktuellen Updates KEINE Änderungen bezüglich TLS passieren.

  12. Dirk Schurrat sagt:

    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.

  13. Alex sagt:

    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!

  14. Clemens sagt:

    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/

  15. Ralf sagt:

    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

Schreibe einen Kommentar zu riedenthied Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.