[English]Kleine Information für Blog-Leser, auf die mich Maksymilian gerade hingewiesen hat. Microsofts Entwickler haben zum 19. April 2024 den Edge-Browser auf die Version 124.0.2478.51 aktualisiert. Der macht aber Probleme mit den (unsicheren) http-Seiten und blockiert beispielsweise Downloads. Doof, wenn so etwas in einem Intranet in einer Unternehmensumgebung passiert. Das gilt übrigens auch für das Chromium-Pendant. Aber es gibt einen Workaround, den mir Maksymilian gleich mitgeliefert hat (danke dafür).
Edge 124.0.2478.51 streikt bei http-Seiten
Microsofts Edge, und Googles Chromium-Entwickler sind immer wieder für Überraschungen gut. Die Edge Version 124.0.2478.51 soll diverse Bugs und Schwachstellen schließen. Zudem werden einige neue Features eingeführt. Heute hat mich Maksymilian per E-Mail kontaktiert und schrieb:
Hallo Günter,
ich wollte auf eine Sache aufmerksam machen, die seit dem 19.4.24 mit dem neusten Edge Update Version 124.0.2478.51 auftritt:
Seiten, die noch als HTTP fungieren (oftmals in Unternehmen als Intranet Seiten) und die Benutzer daraus Dateien herunterladen wollen, wird das geblockt. Leider wurde das im Changelog nicht erwähnt, sondern durch Frust der Community aufgedeckt.
Maksymilian hat mir gleich mehrere Fundstellen im Web mitgeliefert, wo das Problem angesprochen wird. Auf Reddit.com findet sich dieser Beitrag mit folgendem Inhalt:
Edge 124.0.2478.51 PDF cant be downloaded. Since the newest update we cant download Pdf files which are viewed through the edge. If you can press the save button and it will start to download, but after that it will show you an error message that it cant be downloaded. Has anyone else this issue?
Im konkreten Fall kann der Betroffene keine PDF-Dateien mehr mit dem Edge 24.0.2478.51 herunterladen. Der Download startet, aber es gibt einen Fehler, dass die Datei nicht herunter geladen werden kann. Ein anderer Nutzer bestätigt dies und schreibt, dass er dieses Problem auch in seiner Arbeitsumgebung habe. Es wirkt sich auf Dateidownloads von allen internen http-Sites aus, wobei unklar ist, ob alle Dateitypen betroffen sind oder nur eine Auswahl.
In der Microsoft Techcommunity gibt es den Nutzerbeitrag Mixed mode content download warning, der sich ebenfalls mit dem Thema befasst. Der Betroffene schreibt, dass er nach dem jüngsten Update auf den Edge v124 Stable plötzlich das Problem hat, dass eine Reihe interner Websites, die Warnungen vor dem Herunterladen von Inhalten im gemischten Modus ausgeben und das Herunterladen von Dateien blockierten. Jemand schrieb, dass es auch den Chromium-Browser betrifft und hat diesen Bug-Report bei Google gepostet.
Workaround für das Problem
Die Betroffenen aus dem reddit.com-Thread schrieben, dass sie hoffen, das Problem mit einer GPO-Änderung lösen zu können. Maksymilian hat in seiner Mail gleich den Link zur betreffenden Richtlinie Control where security restrictions on insecure origins apply von Microsoft mitgeliefert. Mit dieser Richtlinie können Administratoren zulässige Ursprünge für Legacy-Anwendungen angeben, die kein TLS bereitstellen können. Dazu ist eine Liste von Quellen (URLs) oder Hostnamenmustern (z. B. „*.contoso.com“) anzugeben, für die die Sicherheitseinschränkungen für unsichere Ursprünge nicht gelten.
Diese Richtlinie verhindert auch, dass der Ursprung in der Omnibox mit „Nicht sicher“ gekennzeichnet wird. Das Setzen einer Liste von URLs in dieser Richtlinie hat den gleichen Effekt wie das Setzen des Kommandozeilen-Flags ‚–unsafely-treat-insecure-origin-as-secure‘ auf eine kommagetrennte Liste derselben URLs. Wenn diese Richtlinie aktiviert wird, hat sie Vorrang vor dem Befehlszeilen-Flag. Vielleicht hilft es jemandem weiter.
Problem mit SSL-Inspection bei https-Seiten
Ergänzung: Blog-Leser Dirk hat mich noch im Nachgang per E-Mail kontaktiert, weil er den Beitrag gelesen hatte. Er schreibt, dass in seiner Unternehmensumgebung seit gestern Probleme bei https-Seiten auftauchen, die einer SSL-Inspection unterzogen werden. Das betrifft Chromium-Browser, während es beim Firefox funktioniert. Das Problem tritt zufällig auf, schreibt Dirk und ergänzt: „Seltsamerweise sehen wir es derzeit nur auf Windows 10/Windows 11, nicht jedoch auf den Servervarianten unter Citrix bei gleichem Proxy und Edge-Versionsstand.“ Hat jemand aus der Leserschaft ähnliche Beobachtungen gemacht?
Ergänzung: Auf Facebook schrieb mir ein Leser, dass ihn das Thema mit der SSL-Inspektion auch bei einigen Clients getroffen habe – allerdings nicht bei allen, trotz neuster Chrome und Edge Version. Der Leser ist noch am Suchen, warum das so ist, vermutet aber das das Flag enable-tls13-kyber im Chrome das Problem darstellt, weil es per default nun auf aktiv steht. Deaktiviert man die Option, haben die betroffenen Clients keine Probleme mehr.
Microsofts Bestätigung und Rücknahme
Ergänzung 2: In den Release Notes zum Edge Version 124.0.2478.67 hat Microsoft am 26. April 2024 das Problem bestätigt und angegeben, dass die Warnung unbeabsichtigt erfolgte. Dazu schrieb Microsoft:
Announcement: Insecure downloads over HTTP
Users that download potentially dangerous content on HTTP sites will receive a UI warning, (for example, „sample.exe can’t be downloaded securely“). The user can still choose to proceed by selecting „Keep“ on the downloaded item’s „…“ menu. Admins can also use the InsecureContentAllowedForUrls policy to specify HTTP sites where the warning will be suppressed. The warning’s enablement in Edge 124 was accidental. We have reverted the warning in this Stable Release. Admins can use the
InsecureDownloadWarningsfeature flag to test the impact of this upcoming feature.
In einer Anmerkung schreibt Microsoft aber, dass geplant sei, die Warnung vor http-Seite im Microsoft Edge Version 127 wieder einzuschalten (danke an den Blog-Leser für den nachfolgenden Hinweis).
Ähnliche Artikel:
Microsoft zieht Edge 123.0.2420.53 zurück – es gibt Ärger
Microsoft Edge Bug CVE-2024-21388 erlaubte beliebiger Erweiterungen zu installieren
Windows: Edge 123.0.2420.65-Update vom März 2024 bringt ungewollt Copilot-App; keine „Spionage-Funktion“
Komisch das das erst jetzt auftaucht, bei Chrome wurde das doch schon vor Ewigkeiten schrittweise eingeführt
https://blog.chromium.org/2020/02/protecting-users-from-insecure.html
Meines Erachtens, macht der Edge hier nur das was er machen soll: Vor unsicheren http-Downloads warnen. Der Download kann ja trotzdem durchgeführt – muss halt nur nochmals bestätigt werden.
Warum er das jetzt auf einmal macht und nichts davon in den Release Notes steht, ist eine andere Sache.
Hier noch eine schöne Übersicht von 2021, dass die Warnungen eigentlich immer schon da waren: https://textslashplain.com/2021/10/14/moartls-non-secure-download-blocking/
Bleibt vielleicht die Frage, warum das jetzt so überraschend kam und was zwischendurch so im Edge passiert ist bzw. wurde nicht gewarnt?
Es wird Zeit, das sich die Leute mal umstellen.
Das das kommt, wurde schon lange angekündigt.
Auch beim FireFox wird es kommen.
In diversen Forensystemen gibt es das auch schon.
Wird das Forum über https aufgerufen, werden z.B. verlinkte Bilder von http-Seiten nicht angezeigt.
Und beim Firefox ist es auch schon in der Pipeline, das http generell geblockt wird.
Den Modus kann man in den Einstellungen schon seit einiger Zeit aktivieren.
Es wird Zeit, das sich Webseitenbetreiber mal darum kümmern, ihren Kram auf https umzustellen, denn in spätestens 5 Jahren wird kein Browser mehr http-Seiten aufrufen können, auch nicht mit irgendwelchen Tricks oder Einstellungen.
Aha, eine weitere Anwender-Bevormundung also, die bei Firefox in der Pipeline gärt. Die Mozillas sind offenbar auch überzeugt, dass ihren Browser nur ganz Blöde nutzen, denen man keine Entscheidung selbst überlassen darf.
Als ob damit was sicherer würde: Wer weiterhin http-Seiten nutzen will/muss, greift dann eben auf einen alten Browser zurück, bei dem aktuelle Angriffspunkte noch nicht gestopft sind. Das passiert, wenn man Leute zu ihrem Glück zwingen will.
Das gärt nicht nur bei Firefox in der Pipeline.
Auch die anderen Browser werden das genauso machen.
Und wenn man Pech hat, funktionieren dann auf vielen Seiten alte Brwoser nicht mehr.
Das haben wir jetzt schon im geschäftlichen Umfeld, das bei bei bestimmten Sachen alte Browser nicht mehr funktionieren.
Da kommt dann so etwas wie „Sie benutzen einen veralteten Browser, unsere Seite/Anwendung funktioniert nur mit aktuellen Browsern“. Und da nimmt man dann eben einen aktuellen Brwoser, wenn da sehr sehr viel Geld dran hängt.
http wird bleiben, gerade für interne, abgeschottete Netze
Bei internen, abgeschotteten Netzen sollte ja auch kein Zugriff per Browser geschehen. Und wenns doch benötigt wird, Proxy mit Cert davor und Abfahrt. Alles kein Problem, man muss nur wollen.
und wenns total abgeschottet (also wirklich keinerlei Internetzugang) ist kann man auch nen alten Browser nutzen.
aber auch dort ist https mit einfachsten Mittel aktivierbar.
(auch @Dom)
mag ja alles sein, aber es führt eine zusätzliche, unnötige und ungewollte Komplexität ins Netz ein. Und/oder Kosten für CA-signierte Zertifikate (meine Android-Browser z.B. meckern jedes Mal bei selbstsignierten Certs, weil sie nicht wie auf dem Desktop importieren kann).
Natürlich kann man Cert auf Android importieren (auch ungerootet!)
Und LetsCrypt Certs sind kostenlos.
OK, wie mache ich das denn in Bromite?
In Bromite unter chrome://flags kannst du das einstellen.
Danke, aber die einzige dahingehende Option ist bei mir „Allow invalid certificates for resources loaded from localhost„, das wirkt nicht für Geräte im LAN.
Wie ich meine Webseiten innerhalb meines Netzwerks verteile, ist allein meine Sache und nicht die irgendeines Unternehmens, dass sich nebenbei an den Zertifikaten, die es für https braucht, eine goldene Nase verdienen. Wird Zeit, dass die Masse da mal wach wird und sich nicht länger bevormunden lässt. Wenn jemand mein Geld will, wird er sich schon an mich anpassen, da bin ich sicher.
Satz 1: +1
Satz 2: Ha ha ha, guter Witz. Der Anbieter kann problemlos auf die paar „Querulanten“ verzichten – die breite Masse schluckt es weil sie es nicht besser weiss oder ihnen der Aufwand für Änderungen oder gar Kampf zu hoch ist.
Kostenlos:
https://letsencrypt.org/de/
Den Fehler mit dem SSL hatte ich auch mit den 124er Versionen erst von Chrome und dann von Edge. Firefox machte keine Probleme.
Bei uns funktionierte keine einzige, externe Webseite mehr, kam nur eine Fehlermeldung.
Wenn die SSL Inspection der Firewall aus war, ging es.
Mit diesen GPO Einträgen läuft es wieder, dafür die neuesten admx-Files laden:
Computer Configuration > Policies > Administrative Templates > Google > Google Chrome > Enable post-quantum key agreement for TLS > Disabled
Computer Configuration > Policies > Administrative Templates > Microsoft Edge> Enable post-quantum key agreement for TLS > Disabled
Alternativ manuell im Browser (chrome) edge://flags eingeben und nach TLS suchen dort „TLS 1.3 hybridized Kyber support“ deaktiveren
Danke! Wird ausprobiert
@Makara
Super, vielen Dank, das löst das Problem. Getestet habe ich den direkten Eintrag in Edge, GPO folgt noch.
passt – auch GPO funktionieren. Die Settings lassen auch im User-Context setzen, es muss nicht unter „Computer Configuration“ sein. Neue ADMX sind erforderlich.
Firefox wurde heute auch von 125.0.1 auf 125.0.2 aktualisiert. Mit dem Update wird auch eine Sicherheitsfunktion im Zusammenhang mit Downloads wieder zurück genommen, weil sie noch nicht richtig funktioniert. In anderen IT-News-Portalen findet man dazu Details, da der Fehler kein CVE hat, finde ich ihn aktuell nicht wichtig genug, um das Update netzweit zu verteilen, und beschwert hat sich auch noch keiner über Downloadprobleme, kann aber auch damit zusammenhängen, dass unser Proxy den Download übernimmt und die Datei(en) erstmal durch die Sandbox schleift und erst dann heruntergeladen werden können.
Sehe das Problem nicht. Wer keine Transportwegverschlüsselung nutzt – auch im Intranet – sollte seine Adminschuhe an den Nagel hängen. Und kommt mir jetzt nicht mit „dafür ist keine Zeit“. Macht euren Job richtig oder gar nicht.
Dem kann ich nur zustimmen!
Das gilt für den Admin im Unternehmensnetz, für das Heimnetz der Familie ist es aber plain BS und die betrifft es besonders (der Admin weiss ich schon einen Workaround zu bauen, z.B. ein alte Browserversion als Portable).
Wenn im Heimnetz der Familie in irgendeiner Form Browserdownloads angeboten werden, ist da meist auch ein Admin. Was soll das sonst sein? Der Rezeptdownload vom IoT Kühlschrank?
Es gibt so einige Geräte im SoHo-Bereich, die nur HTTP-Interfaces anbieten, SoHo-Switches von TP-Link z.B. und dort kann man die Config exportieren.
Et voila! Ein HTTP-Download.
Und das müssen die Browser dann unterstützen? Oder müssen die Schrotthersteller vielleicht mal ihren Allerwertesten hochbekommen und ihren Müll ordentlich ausliefern? :-)
HTTP wird ja zwingend sowieso unterstützt – man muss es nur nicht ‚böswillig‘ abschalten.
Es wäre grundlegend zu begrüssen, wenn die Hersteller für Endverbraucher konzipierter Hard-/Software nicht ihre jeweilige Idee von „Sicherheit“ den Usern aufzwängen. Sie kann schwerlich auf ganze die Breite der Anwendungsszenarien zutreffen.
Und von den Fachleuten und ‚Fachleuten‘ wünschte ich mir, weniger elitär, stattdessen inklusiver, zu denken. IT soll nicht nur für den Fachmann anwendbar sein, sondern für die möglichst breite Masse. Ein schönes Beipiel ist das [zensiert] MS-Ribbon – Profis und Eingearbeitete (insb. die Tastaturnutzer) hassten, Anfänger und DAUs (insb. die Mausschubser) liebten es und da Letztere in der übergrossen Mehrzahl sind war es die korrekte Entscheidung (so weh sie auch mir tat).
„Der macht aber Probleme mit den (unsicheren) http-Seiten und blockiert beispielsweise Downloads. Doof, wenn so etwas in einem Intranet in einer Unternehmensumgebung passiert.“
Das hatte der Firefox in Version 125.0.1 auch drin, ist bei uns bei internen Diensten auch aufgefallen. Da offenbar das negative Echo größer war als erwartet kam dann mit Version 125.0.2 das Rollback – aber nur temporär, mittelfristig soll der Block von Donwloads über HTTP trotzdem eingeführt werden.
Changelog FF 125.0.2 :
“ Reverted the changes recently shipped in Firefox 125 that more proactively blocked downloads from potentially untrustworthy URLs. The changes caused unexpected problems with downloading files in some situations. We plan to fix and re-enable these protections in a future release. (Bug 1892069)“
Wenn man in der GPO für den Edge das Sternchen in die erwähnte Ausnahmeliste setzt , sollte der Spuk generell abgeschaltet werden können..
Ist nicht optimal, aber zur Not…
Natürlich ist ein Zugriff per Browser vollkommen üblich in nicht-verschlüsselten Intranets. Fast alle Druckerumgebungen laufen ohne Zertifikat via http Web Embedded. Diverse Passwordmanager laufen via http. Und oft gibt es http Dienste(z.B. eingebundene Videos) auf https Seiten.
Tatsache ist, dass die meisten Unternehmen keine Verschlüsselung für Ihre internen/ extra programmierten Webdienste nutzen. Der Grund ist klar. Zertifikate sind ein Glied in einer langen Kette von potentiellen Fehlern die den Arbeitsfluss stören was massiv Geld kostet. Das ständige hin und her mit dem immer noch völlig veralteten Zertifikatsystem, die User die sich dauernd wegen den Fehlermeldungen beschweren und nicht wissen was der Grund ist.
Fakt ist auch das zig Webseiten da draußen http(301) Dienste nutzen um Nutzer auf https Endpunkte zu weisen, was immer noch genug Angriffmöglichkeiten für session hijacking oder man in the middle SSLstrip gibt. HSTS Checks sind abhängig von der hinterlegten Datenbank bzw. hstspreload. Intranets sind da logischerweise nicht dabei.
Aufgrund dessen sind derlei aufwendige Verschlüsslungen für viele Unternehmen sehr fragwürdig, zumal ein Satz immer gilt: Wenn man jemanden hacken oder die Identität stehlen will, geht das immer, sowie es immer Nutzer geben geben wird, die sich leichter täuschen lassen als andere.
Sehe ich ähnlich.
Und das ganz retour (bis zum edge v127)
https://learn.microsoft.com/en-us/DeployEdge/microsoft-edge-relnote-stable-channel#version-1240247867-april-26-2024