[English]Es geschehen noch Zeichen und Wunder – zum 1. April 2022 (kein April-Scherz) scheint Microsoft sein Download-Angebot für Updates endlich so angepasst zu haben, dass diese durchgängig über das https-Protokoll durchgeführt werden. Hier eine kurze Übersicht über den Sachverhalt.
Anzeige
Das http-Update-Download Chaos
Seit Jahren wird von Google & Co. propagiert, dass die Kommunikation mit Webseiten doch bitte über das https-Protokoll erfolgen möge, damit die Integrität der Kommunikation über die Verschlüsselung gewährleistet und die Server über SSL-Zertifikate ausgewiesen wird. Bei Microsoft war es aber seit vielen Jahren so, dass Downloads von Update-Paketen über das unverschlüsselte http-Protokoll abgerufen – oder zumindest zum Download angestoßen – werden mussten. Ich verlinke mal auf diese Diskussion hier im Blog:
Blog-Leser Bolko: Microsoft setzt beim Update-Catalog auf HTTP statt HTTPS und da meckert dann Chromum und weigert sich.
Mit Firefox kann man hingegen "Weiter mit HTTP" anklicken.Da sollte Microsoft mal nachbessern und auf HTTPS-Downloads umstellen.
Günter Born: Das ist schon vor Jahren von Stefan Kanthak kritisiert worden – Microsoft kennt das Problem. Da laufen teilweise wilde Umleitungen – aber nicht immer.
Und im Diskussionsbereich des Blogs gab es zum 29. September 2021 die denkwürdige Diskussion:
Anonymous: der neue MS Edge (v94) blockiert jetzt MSU Downloads vom *https://www.catalog.update.microsoft.com/
da die Downloadslinks nur "http" sind *LOL*G. Born: Dann hat es Microsoft also endlich erwischt. Stefan Kanthak haut mir seit Jahren die http-Links, die ich aus den Supportbeiträgen für Updates herauskopiere, um die Ohren.
Lange Lese, kurzer Sinn: Es wäre längst an der Zeit gewesen, dass Microsoft den Download seiner Update-Pakete durchgängig auf das https-Protokoll umstellt, um Konsistenz und Sicherheit zu erhöhen.
Bezüglich Sicherheit: Ja, die Update-Pakete sind mit einem SHA-Schlüssel und einer digitalen Signatur versehen, und so vor Manipulation geschützt. Inzwischen machen die meisten Browser aber bei http-Adressen Probleme und die obigen Kommentare zeigen das auf. Auf Twitter sind mir auch die nachfolgenden zwei Fundsplitter mit dem gleichen Tenor auf die Füße gefallen. Selbst Martin Geuß fühlte sich im Januar 2022 bemüßigt, WindowsUpdate auf Englisch über dieses Problem zu informieren.
Anzeige
Es wurde wohl umgestellt
Am heutigen Samstag-Morgen (2.4.2022) wäre mich fast der Kaffee aus dem Gesicht gefallen, als ich bei den Kollegen von deskmodder.de auf diese Meldung und nachfolgenden Tweet gestoßen bin. Ein Blog-Leser hat im Blog-Beitrag Probleme mit dem Microsoft Update Catalog ebenfalls auf diese Meldung hingewiesen (danke dafür).
Zum Sachverhalt: Der ist ziemlich schnöde – man sollte seit dem 1. April 2022 alle Update-Downloads von den Update-Servern und aus dem Microsoft Update Catalog durchgängig über das https-Protokoll erhalten. Für Downloads aus dem Microsoft Update Catalog gelten dann URLs mit dem Schema:
*https://catalog.s.download.windowsupdate.com/c/msdownload/update
statt der alten Nomenklatur:
*http://download.windowsupdate.com/d/msdownload/update/
Man hat also nicht nur das https-Protokoll erzwungen, sondern leitet den Download auch von einer Unterdomain catalog.s ein, wobei das s in der URL vermutlich für secure steht. Für die Downloads aus dem Microsoft Update Catalog ändert sich nichts – lediglich direkte Download-Links, die im Internet auf die Microsoft-Server verweisen, müssen wohl angepasst werden – bzw. dürften von Microsoft mit einem Redirect versehen werden. Die Download-Probleme mit diversen Browsern auf Grund der http-Protokoll-Problematik dürften damit auch behoben sein. Ihr könnt ja eine Rückmeldung hinterlassen, wenn es noch Probleme gibt oder ich in obigem Exzerpt was übersehen habe. Thumbs-up in den Nordosten an die Kollegen von deskmodder.de, die das aufgegriffen haben (und an den anonymen Blog-Leser für den Hinweis) – ich wäre sonst dumm gestorben.
Das sollte die Sicherheit der Downloads bei der Übertragung per Internet gegen Manipulationen erhöhen (wenn auch die Update-Pakete selbst ja mit Hashes versehen sind).
Anzeige
Ich sehe schon jede Menge Probleme voraus.
Zunächst – was nützt es? Es sind öffentliche Ressourcen, die von jedermann ohne Anmeldedaten oder sonstige schützenswerte Kommunikation heruntergeladen werden können.
Die Integrität der geladenen Pakete wird schon deit vielen Jahren durch sichere (SHA256) Signaturen gewährleistet, so daß ein Man-in-the-middle Angriff praktisch nichts bringt.
Andererseits verhindert die Verschlüsselung in vielen Fällen das Caching von Daten auf Proxies im Übertragungsweg, so daß für jeden Clienten das .esd oder .msu immer wieder direkt von Microsoft-Servern kommen muß.
Zudem dürfte es auch für Microsoft komplizierter werden, bei großen Rollouts Kapazitäten bei den üblichen Anbietern wie Akamai anzumieten, weil deren Server und Loadbalancer dann eben auch mit vertrauenswürdigen Microsoft-Zertifikaten (die nicht mal eben abhanden kommen dürfen) konfiguriert und die zusätzliche Last der SSL-Verschlüsselung stemmen können müssen.
Den einzigen echten Vorteil an diesem Szenario sehe ich für Microsoft selbst. Durch die damit erzwungene Ende-zu-Ende-Verbindung ist natürlich sehr viel erweitertes Monitoring der Kunden möglich.
Die Diskussionen sind mir im Prinzip bekannt (das Argument, dass das Ver- und Entschlüsseln Energie benötigt und http energetisch günstiger ist, wurde auch schon ins Feld geführt). Trotzdem wird von Seiten der Sicherheitsexperten seit Jahren gefordert, dass Updates immer über gesicherte Verbindungen laufen. Wenn das Problem, dass Browser den Download nicht mehr wegen http-URL verweigern, gelöst ist, stellt das für viele Nutzer bereits einen Vorteil dar, den ich nicht von der Hand weisen möchte. Aber vielleicht übersehe ich etwas.
Wäre es möglich, dass wenn ein Update z.B. neue Zertifikate und oder Verschlüsselungsarten mitbringt und alle vorherig installierten abgelaufen, kompromitiert, veraltet o.ä. sind, dass man dann ggf. nur per http zu den Updates kommt und nicht per https? Ähnlich wie bei alten Android Geräten, die mit dem mitgelieferten Browser keine https Webseiten mehr aufrufen können, weil die Server das ablehnen. Also ohne http hätte man ein Henne-Ei Problem?
Nicht wirklich, weil CRL und OCSP geht zwingend über http, niemals über TLS.
Und auch die Root CA's werden über http geupdated. Wäre mehr ein Problem, wenn TLS 1.0 und 1.1 wie in M365 ausgeschaltet würde und nur noch TLS 1.2 und 1.3 ginge. Dann wären alle älteren Geräte ausgeschlossen.
Sehr interessanter Artikel!!!
Microsoft hat eine gewisse digitale Macht.
Warum auch nicht https://
Bei meiner Bank läuft https:// seit Jahrzehnten!!!
Auch möchte ich mich mal ganz herzlich bei Herrn Born für seine jahrzehnte lange Arbeit bedanken.
Einen kompetenteren Blog muss man schon suchen!!!
Hoffentlich bleibt er der Gemeinde noch lange erhalten!!!
–Einen kompetenteren Blog muss man schon suchen!!!
Ist auch sehr leicht zu finden. Da muss man nicht lange suchen.
"Das sollte die Sicherheit der Downloads bei der Übertragung per Internet gegen Manipulationen erhöhen (wenn auch die Update-Pakete selbst ja mit Hashes versehen sind)." plus "Aber vielleicht übersehe ich etwas": OHNE Transportverschlüsselung kann jeder "man-in-the-middle" statt der erwarteten "sauberen" *.msu/*.msi/*.cab/*.exe gleichnamige "versaute" Dateien unterschieben, die anschliessend von den nichts Böses argwöhnenden Nutzern brav per Doppelklick "ausgeführt" werden.
Die Prüfsummen von *.msu/*.msi helfen hier NICHT, denn die werden erst von dem per Doppelklick gestarteten Programm geprüft. Und Authenticode-Signaturen der heruntergeladenen Dateien können von einem MITM "gespooft" werden: welcher Otto Normalverbraucher prüft nach dem Download und vor dem "Ausführen", ob das zum Signieren verwendete Zertifikat auch wirklich das richtige Microsoft-Zertifikat ist?
>welcher Otto Normalverbraucher prüft nach dem Download und vor dem "Ausführen", ob das zum Signieren verwendete Zertifikat
Die frickeln gar nicht erst mit manuellen Downloads und Update installationen rum. Und wenn etwas nicht geht gibt es immer einen willigen Freizeit-Admin, der das unbezahlt repariert für ein Glas Cola.