Windows: Timeout bei TLS-Verbindungen, Workaround

[English]Bei Windows 7, Windows 8.1 und diversen Server Versionen kann es durch eines der letzten Updates zu Timeouts bei TLS-Verbindungen kommen. Dann gibt es diverse Fehlermeldungen wie Fehlercode 0x8009030f (SEC_E_MESSAGE_ALTERED) oder ein SCHANNEL Event 36887 mit dem Code 20 in der Ereignisanzeige.


Anzeige

Microsoft hat zu diesem Problem am 30. Oktober 2019 einen entsprechenden Supportbeitrag 4528489 (Transport Layer Security (TLS) connections might intermittently fail or timeout when connecting) veröffentlicht.

Das Fehlerbild

Beim Versuch, eine Verbindung [mit einem Server] herzustellen, können Transport Layer Security (TLS) und Secure Sockets Layer (SSL) zeitweise ausfallen oder auf einen Timeout laufen. Dann werden ein oder mehrere der folgenden Fehler angezeigt:

  • "Die Anfrage wurde abgebrochen: SSL/TLS Secure Channel konnte nicht erstellt werden"
  • Fehlercode 0x800903030f  (SEC_E_MESSAGE_ALTERED)
  • Im Systemereignisprotokoll wird für das SCHANNEL-Ereignis 36887 ein Fehler mit dem Alarmcode 20 und der Beschreibung "A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 20.​" eingetragen.

Die Ursache ist darin begründet, dass Microsoft im Augst 2019 die Schwachstelle CVE-2019-1318 per Update geschlossen hat. Genau dieser Fix scheint nach Installation der Oktober 2019-Updates jetzt die TLS-Timeouts zu verursachen.

Welche Windows-Versionen sind betroffen

Dummerweise wurde der Fix durch verschiedene Updates an Windows 7, Windows 8.1 und diverse Windows Server-Versionen, die noch im Support sind, verteilt. Betroffen sind folgende Windows-Versionen, die kumulative Updates und Rollups zum 8. Oktober 2019 (oder später) erhalten haben:


Anzeige

  • KB4519998 LCU for Windows Server, version 1607 and Windows Server 2016.
  • KB4520005 Monthly Rollup for Windows 8.1 and Windows Server 2012 R2.
  • KB4520007 Monthly Rollup for Windows Server 2012.
  • KB4519976 Monthly Rollup for Windows 7 SP1 and Windows Server 2008 R2 SP1.
  • KB4520002 Monthly Rollup for Windows Server 2008 SP2

Zudem sind auch Systeme betroffen, die folgende Security-only Updates vom 8. Oktober 2019 erhalten haben.

  • KB4519990 Security-only update for Windows 8.1 and Windows Server 2012 R2.
  • KB4519985 Security-only update for Windows Server 2012 and Windows Embedded 8 Standard.
  • KB4520003 Security-only update for Windows 7 SP1 and Windows Server 2008 R2 SP1
  • KB4520009 Security-only update for Windows Server 2008 SP2

Wer also diese Updates auf den Maschinen installiert hat und TLS-Fehler erhält, sollte reagieren und folgenden Workaround versuchen.

Ein Workaround für das TLS-Problem

Microsoft gibt im Supportbeitrag zwei Workaround an, mit dem sich das TLS-Timeout-Problem eventuell abschwächen lässt.

  • Aktivieren Sie die Unterstützung für Extend Master Secret (EMS) Erweiterungen, wenn TLS-Verbindungen sowohl auf dem Client als auch auf dem Server-Betriebssystem durchgeführt werden. EMS gemäß RFC 7627 wurde 2015 zu den unterstützten Versionen von Windows hinzugefügt.  Jedes Update, das am oder nach dem 8. Oktober 2019 veröffentlicht wird, hat EMS standardmäßig für CVE-2019-1318 aktiviert.
  • Oder: Für Betriebssysteme, die kein EMS unterstützen, entfernen Sie die TLS_DHE_*-Cipher Suites aus der Liste der Chiffriersammlungen im Betriebssystem des TLS-Clients. Anweisungen dazu, wie Sie dies unter Windows tun, finden Sie unter Prioritizing Schannel Cipher Suites.

Microsoft empfiehlt nicht, EMS zu deaktivieren. Wenn EMS explizit durch Administratoren deaktiviert wurde, kann es wieder aktiviert werden, indem man folgende Registrierungseinträge setzt. Im Schlüssel:

HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel

sind auf dem TLS-Server und –Client die folgenden Werte auf 0 zu setzen:

On TLS Server: DisableServerExtendedMasterSecret: 0
On TLS Client: DisableClientExtendedMasterSecret: 0

Damit sollten die TLS-Verbindungsprobleme weg sein. (via)


Anzeige

Dieser Beitrag wurde unter Problemlösung, Update, Windows Server abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

6 Antworten zu Windows: Timeout bei TLS-Verbindungen, Workaround

  1. RedOne sagt:

    Gibt es durch dieses Timeout ein Sicherheitsproblem?

    Was bedeutet es wenn Transport Layer Security (TLS) und Secure Sockets Layer (SSL) zeitweise ausfallen oder auf einen Timeout laufen?

    Muss man den Workaround aus Sicherheitsgründen machen?
    Oder kann man bis zum Patchday am 12.11.2019 abwarten?

    • acvolker@gmx.de sagt:

      Auch nach dem Patchday November taucht ab und zu der Fehler

      Ereignis 36887: "Es wurde eine schwerwiegende Warnung vom Remoteendpunkt empfangen. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 20."

      auf.

  2. Roli sagt:

    Muss uns/mir doch keiner heilig-predigen, dass die da noch normal sind. Eher lachhaft die Qualitätsarbeiten von den Windows-Kaputtmacher. Bin froh mache ich die vermöbelten Patches längst nicht mehr mit.

  3. Anonymous sagt:

    Hallo,

    ich bin durch Zufall auf diese Seite gestoßen.
    Ich muss einige Updates für Windows 7 nachholen, die ich bisher vermieden habe.

    Gibt es eine Art Liste welche Updates man haben sollte und welche nicht? Da es wohl Updates gibt die Fehler herbei rufen.

    Würde das via Update Paket von WinFuture machen und dort dann die unnötigen Updates abwählen.
    Würden Updates ab 2016 betreffen.

    Vielen Dank
    Eric

  4. Michael sagt:

    Hallo, ich habe aktuell dieses Problem auf einem Server2012, nach Abschaltung der alten TLS 1.1 durch Provider, musste ich die TLS 1.2 über die Reg Einträge aktivieren. Leider kann dennoch keine Mail mehr über den Exchange rausgesendet werden und der Schannel Fehler 70 ist zigfach im Ereignislog.
    "Es wurde eine schwerwiegende Warnung vom Remoteendpunkt empfangen. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 70."
    Hab dann nach den oben genannten beiden Einträgen geschaut, aber die sind hier garnicht vorhanden! Sollte ich die dann händisch eintragen? Und noch eine Frage, wie kann ich den Exchange überprüfen ob TLS 1.2 nun aktiv ist?

    • DW sagt:

      Das Thema hierbei ist, dass das SSL/TLS Protokoll (z.B. TLS !.2) alleine nicht ausschlaggebend ist. Sondern es müssen natürlich auch noch die entsprechenden Cipher Suites verfügbar und ggf. konfiguriert werden. Und damit es nicht zu einfach in der Microsoft Welt wird, wird noch zwischen Server und Client unterschieden. :-)

      Microsoft verfolgt hierbei die klassische Variante: Es werden eigentlich TLS Versionen und Cipher Suites immer nur in neuen Version von Windows Server (2016, 2019 und 2022) hinzugefügt, aktualisiert. Was in der heutigen Zeit einfach nicht mehr.

      Prüfen kannst du das mit Tools wie OpenSSL oder testssl.sh.

Schreibe einen Kommentar

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.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.