Im Juni und Juli 2016 gab es kumulative Updates für den Internet Explorer 11. Bei Blog-Leser Axel H. gab es danach Probleme in einer Intranet-Umgebung (Sharepoint), in der plötzliche Webseiten nicht mehr korrekt dargestellt wurden. Aber es gab wohl weltweit weitere Probleme und Administratoren haben mit den Updates zu kämpfen.
Anzeige
So werden Probleme mit der Anmeldung an bestimmter SAP-Software berichtet, wo die Anmeldungen der Benutzer plötzlich verweigert wird. Oder die TLS-Kommunikation liefert Fehler. Blog-Leser Axel H. hat mir die Infos stückweise, nach Erkenntnislage, zukommen lassen, so dass ich diese einfach mal hier einstelle. Vielleicht gibt es von der Leserschaft noch Hinweise, wie man die Probleme umgehen kann – oder Dritte profitieren von den Hinweisen.
Erste Mail mit Hinweisen auf die IE 11 Probleme
Die Mail erreichte mich bereits am 3. August 2016 – da war aber Windows 10 Anniversary Update angesagt, so dass ich die Info "auf Halde" gelegt und Axel H. entsprechend informiert habe. Hier seine Infos:
Hallo Hr. Born,
uns ist aufgefallen, wenn wir diese Patche [kumulative IE 11-Updates Juni/Juli 2016, siehe folgender Absatz] installieren, dass wir manche Seiten im Intranet (über Internetseiten haben wir noch keine Infos) nicht mehr öffnen können und auf unserem SharePoint manche Seiten etwas verschoben angezeigt werden.
MS16-063(Juni) und/oder MS16-084 auf unseren W7 Clients bzw. die Kumulativen Windows 10 Patche vom Juni und/oder Juli, die die jeweiligen Patche auch enthalten
Die IE Version ist anschließend entweder 11.0.32 (Juni) oder 11.0.33 (Juli). Mit der Version 11.0.31 gab es weder auf W7, noch auf W10 diese Probleme. Bei Deinstallation des Patches unter W7, funktioniert der Zugriff zu den Seiten wieder und auch die SharePoint Seiten sehen wieder lesbar aus.
Die einzigen Meldungen über Probleme oder interessante Hinweise auf die Patche habe ich bislang hier gefunden:
Windows update KB3170106 messes up sharepoint (Link gebrochen)
An update to our SHA-1 deprecation roadmapDer erste Link ist nur ein ärgerlicher Kommentar (so ähnlich haben wir auch geschimpft :-)), der zweite Link ist schon etwas interessanter, wobei ich dies derzeit noch nicht ganz verstehe… (aber vielleicht können sie damit mehr anfangen :-)…
Da das Problem wohl recht virulent war (mir war noch nichts unter die Augen gekommen), hat Axel weiter gebohrt und mir am 4. August 2016 noch weitere Links zu Fundstellen per Mail zukommen lassen.
wir haben inzwischen doch weitere Kommentare und ähnliche Hinweise gefunden. Zum Teil sogar mit Workarounds (im SAP Umfeld):
update KB3170106 which changed the way ASP objects are handled
windows 10 update 15 Jun 2016
Could not establish secure channel for SSL/TLS with authority
June 2016 Update KB3163018 – TLS 1.0 support removed/blocked?
In den Beiträgen wird bestätigt, dass das diverse IE 11 Updates wie KB31616086 und KB3161608) vom 15. Juni 2016 wohl einige Seiteneffekte verursacht, weil Server-Zertifikate ausgetauscht wurden. In anderen werden SSL-Fehler bemängelt. Nach Deinstallation der Updates sind die Probleme weg.
Anzeige
SAP-Anmeldeprobleme
Axel hatte mir noch einen Link auf den Beitrag Server's Security Certificate Windows 7 mit Hinweisen auf ein SAP-Problem zukommen lassen. Dort konnten sich Nutzer nicht mehr an SAP-Software auf dem Server anmelden. Im von ihm angehängten SAP-Dokument gab es die Bestätigung, dass es Probleme mit Zertifikaten gäbe. Leider liegt das PDF-Dokument nur als Grafik vor – hier mein Screenshot:
Der Inhalt wird in diesem Beitrag SAP B1 – There is a problem with the server's security certificate – Windows 10 thematisiert. Dort gibt es erneut den Vorschlag, die Sicherheits-Updates KB3163017/KB3163018 zu deinstallieren. SAP empfiehlt dagegen den Umstieg auf neuere Versionen der SAP Business One Clients.
Erste Lösungsansätze
Da es sich um Sicherheits-Updates für den IE 11 handelt und deren Deinstallation sowie ein Browserwechsel im Intranet eher ausscheiden, hat sich Axel weiter auf die Suche gemacht. Letzten Freitag kam dann folgende Information von ihm.
Hallo,
so wie es derzeit aussieht, konnten wir unsere SharePoint Probleme auf eine Einstellung in der Sitelist des Enterprise Mode (Unternehmensmodus) zurückführen.
Eine Unterseite war über diese Sitelist vom Enterprise Mode ausgeschlossen und funktionierte anstandslos, bevor die Kumulativen IE Patche vom Juni/Juli auf W7/W10 installiert wurden. Anschließend jedoch war diese Unterseite nach links verschoben (man sah nur noch die Hälfte). Nimmt man nun die Sitelist heraus und setzt für die Unterseite den Enterprise Mode manuell, so sieht alles so aus, wie ohne die Patche.
Wenn am Montag diese Sitelist angepasst worden ist, werden wir sehen ob es funktioniert.
Heftigere Probleme haben wir dagegen weiterhin mit Anwendungsseiten, insbesondere mit dem HP Service Manager, dieser funktioniert derzeit weiterhin nicht mehr unter W10 nach dem letzten kumulativen W10 Patch. (unter W7 funktioniert die Seite/Anwendung dagegen). Wir vermuten es ist ein TLS 1.0+SHA-1 handshake Fehler, der aber nur unter W10 mit dem IE zu Problemen führt, mit Chrome gibt es auch unter W10 keine Probleme.
Vorläufiges Fazit:
Ja, die Kumulativen IE Patche haben Auswirkungen auf das Design von Seiten, wenn man mit dem Enterprise Mode „herumspielt" und verändern das Verhalten des selbigen nach dem Update.
Ob diese IE Patche auch für die Probleme unter W10 alleine verantwortlich sind, oder ob noch ein anderer W10 Patch verantwortlich ist, ist nicht ganz einfach zu ermitteln, da man die Patche leider nicht mehr einzeln installieren kann. Die Wahrscheinlichkeit aber, dass es sich um ein Zertifikatsproblem handelt ist allerdings sehr hoch…
Und gestern kam dann noch eine ergänzende Information per Mail mit weiteren Präzisierungen.
so wie es aussieht, haben meine Kollegen in Portugal das Problem gefunden.
Mit dem neuen Patch wurden zwei „Cipher-Suite"-Einträge hinzugefügt (s. KB3161639), diese scheinen die Reihenfolge bei der Verwendung der Zertifikate zu stören (oder was auch immer).
Löscht man die Einträge
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHAhier
HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\
Configuration\Local\SSL\00010002hat man mit dem Zugriff von Windows 10 auf alte Web-Server nicht mehr die Probleme, sie werden wieder angezeigt.
Vielleicht reicht es auch die neuen Einträge an das Ende der Liste zu hängen und nicht in die Mitte…
Wäre natürlich einfacher, die Web-Server hätten diese ebenfalls eingebunden…
Wir vermuten weiterhin, dass wir das Problem auch auf Windows 7 Clients bekommen würden, wenn wir das Juni Roll-Up KB3161608 installieren würden… was wir aber bislang geblockt haben…
So weit die Beschreibung der Problematik. Mein Dank an Axel für das bereitgestellte Material (sowie an Mark Heitbrink, der im Hintergrund wohl auch mit herum werkelte). Nun die Frage in die Runde: Kann sich da jemand einen Reim drauf machen? Gibt es weitere Betroffene? Gibt es ggf. eine bessere Lösung?
Nachträge vom 10. August 2016
In einer weiteren Mail hat mich Blog-Leser Axel über die weiteren Erkenntnisse informiert. Ich gebe diese einfach mal weiter:
wir haben inzwischen weitere Informationen zu den Roll-Up-Patchen.
Die Liste der „Cipher-Suites" wird auch unter W7 durch den Patch mit weiteren Einträgen neu erstellt. Letztes Jahr hat MS die Priorisierung der Verschlüsselungssamlungen geändert (s. https://technet.microsoft.com/library/security/3042058.aspx). D. h., ändert man die Reihenfolge der Einträge, so ändert man auch deren Priorität:
Unter W10 half es den Eintrag
TLS_RSA_WITH_AES_128_CBC_SHA
vor den beiden neuen Einträgen
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHAeinzufügen, damit wir unseren HP ServiceManager wieder nutzen konnten.
Die Liste der „Cipher Suites" auf der Microsoft Seite sieht bei uns etwas anders aus und wir fürchten, dass sie durch diverse Patche auch Neusortierungen oder weitere Ergänzungen erfahren könnte, daher suchten wir nach einer Alternative.
Inzwischen wissen wir auch mehr über die „DHE" (Diffie-Hellman Ephemeral) Einträge. Microsoft erhöhte die Länge der Schlüssel von 512 auf 1024 Bit https://support.microsoft.com/en-us/kb/3061518 und damit kamen die Probleme, da ältere Web-Serverinstallationen diese nicht verarbeiten können (solange sie nicht auch diese Einstellungen/Keys benutzen)…
In dem obigen Artikel beschreiben sie einen Registrykey „ClientMinKeyBitLength", den man wieder auf den Wert 512 zurücksetzen kann. (ggfs. ist anschließend ein Reboot nötig!)
HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Control\SecurityProviders\
SCHANNEL\KeyExchangeAlgorithms\
Diffie-Hellman
ClientMinKeyBitLength DWORD 00000200Allerdings setzt man dann natürlich wieder die Security herab… (getestet unter W10 LTSB, Tests unter W7 folgen noch)
Ein paar Links zum Thema:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx
https://msdn.microsoft.com/library/windows/desktop/mt767769.aspxhttps://www.kuketz-blog.de/nsa-abhoersichere-ssl-verschluesselung-fuer-apache-und-nginx/
Hinweise zu den Rollups: https://blogs.technet.microsoft.com/windowsitpro/2016/05/17/simplifying-updates-for-windows-7-and-8-1/
Soweit der neueste Stand. Falls ihr eigene Erkenntnisse habt, könnt ihr diese ja hier in den Kommentaren nachtragen.
Anzeige
Hallo Herr Born,
ich selbst habe dieses Problem ebenfalls im Unternehmen feststellen können. Derzeitig sieht es danach aus, als ob der Workaround mit der Anpassung des Regkeys ebenfalls bei uns funktioniert.
Eine Beeinflussung von internen Sites durch den Enterprise-Mode konnte ich bisher nicht nachvollziehen.
Wir haben das Problem bei unserer int. Anwendung Lucanet gehabt, welche ebenfalls einen int. Webserver verwendet.
Eine bessere Lösung ist mir bisher leider nicht bekannt.
Mit freundlichen Grüßen
Julian K.