[English]Die besten Geschichten schreibt immer noch das Leben. Heute ein "What the Fuck" (WTF) eines Microsoft-Mitarbeiters, der gerade über den Sachverhalt gestolpert ist, dass die Edge-Entwickler die Verifikation von TLS-Zertifikaten ab der Edge-Version 110 vom Host entkoppelt haben. Auf das Thema hatte ich Mitte Februar hier im Blog bereits hingewiesen.
Anzeige
Ein WTF von Ryan Ries …
Ich bin die Tage auf einen Tweet von Ryan Ries gestoßen, den ich mir sofort als Perle "aufgehoben" habe. Joseph Ryan Ries ist Windows Escalation Engineer bei Microsoft und ackert im Bereich Active Directory und Coding in diesem Unternehmen. Ries ist wohl die Tage auf einen Microsoft Supportbeitrag gestoßen, der ihn zu folgendem Tweet veranlasst hat.
In seinem WTF verweist er auf einen Abschnitt Known revocation checking behavior differences on Windows zum Edge Supportbeitrag Changes to Microsoft Edge browser TLS server certificate verification. In obigem Tweet schreibt er:
Ich bin beunruhigt. Verwendet Edge nicht mehr dieselbe Zertifikatswiderrufs-Engine wie Windows? Wie kann das in Unternehmensumgebungen nicht zu einem absoluten Blutbad führen? (Vor allem in Bezug auf LDAP CRLs, die Intranetseiten von Unternehmen DEFINITELY STILL USE)
Im betreffenden Support-Artikel heißt es, dass die neue, (wohl in Edge) integrierte Zertifikatsüberprüfung strenger bei der Durchsetzung der RFC 5280-Anforderungen für Zertifikatsperrlisten (CRLs) ist als die alte, (in Windows implementierte) plattformbasierte Überprüfungsfunktion. Außerdem unterstützt die neue Prüfstelle keine LDAP-basierten CRL-URIs. Weiterhin heißt es:
Wenn ein Unternehmen die Richtlinie RequireOnlineRevocationChecksForLocalAnchors aktiviert und die CRLs nicht gemäß RFC 5280 gültig sind, kann es in Ihrer Umgebung zu den Fehlern ERR_CERT_NO_REVOCATION_MECHANISM und/oder ERR_CERT_UNABLE_TO_CHECK_REVOCATION kommen.
Wenn ERR_CERT_NO_REVOCATION_MECHANISM auftritt, sollten Sie sich vergewissern, dass die CRL an dem vom Zertifikat angegebenen URI eine DER-kodierte (nicht PEM-kodierte) Antwort zurückgibt.
Wenn ERR_CERT_UNABLE_TO_CHECK_REVOCATION-Fehler auftreten, sollten Sie sich vergewissern, dass der Zertifikatsaussteller auch der CRL-Aussteller ist, das cRLIssuer-Feld des Zertifikats nicht gesetzt ist und der URI, der die CRL hostet, das HTTP-Protokoll verwendet. Riecht irgendwie nach Ärger, den auch Ryan Ries heraufziehen sieht.
Interessant scheint mir auch die Diskussion auf Twitter zu sein, wo angedeutet wird, dass das Ganze auf eine Entscheidung des Chromium-Teams zurück geht (und die Edge-Entwickler hängen da dran).
Hinweise auf das Thema hier im Blog
Dass Schwierigkeiten zu erwarten seien, hatte ich im Januar im Beitrag Edge 109.0.1518.49 bereits angedeutet. Microsoft hatte eine Änderung in der Verifizierung von TSL bekannt gegeben. Dort hieß es unter "Änderungen bei der TLS-Server-Zertifikatsüberprüfung":
In Microsoft Edge Version 110 werden die Zertifikatsvertrauensliste und die Zertifikatsüberprüfung vom Root Store des Host-Betriebssystems entkoppelt.
Stattdessen werden die Standard-Zertifikatsvertrauensliste und die Zertifikatsüberprüfung vom Browser bereitgestellt und mit diesem ausgeliefert.
Die Richtlinie MicrosoftRootStoreEnabled ist jetzt zum Testen verfügbar, um zu steuern, wann der integrierte Root Store und die Zertifikatsüberprüfung verwendet werden. Es ist geplant, die Unterstützung für diese Richtlinie in Microsoft Edge Version 111 zu entfernen.
Und dann gab es nochmals im Februar 2023 den Blog-Beitrag Änderungen im Edge: Änderung bei TLS-Zertifikaten, kein Uninstall mehr, Server 2012/R2-Support wo ich einen Hinweis eines Lesers aufgegriffen hatte, der mir dazu schrieb:
Hi – hast ja mitbekommen dass der Edge jetzt das Verhalten bei den RootCa ändert. In Zukunft schaut er erst mal bei der MS nach, ob das RootCert gültig ist, und wenn da nichts ist erst in den lokalen Speicher für RootCa Zerts.
Das bedeutet aber dass der Admin die Macht verliert, selber über die RootCa Certs zu entscheiden. Machen auch heute die wenigsten und lassen die RootCas von MS patchen, aber manchen mag das Ärgern. Behörden z.B. […]
Der Leser meinte, dass er in der Praxis noch keinen Administrator getroffen habe, der sich klar war, wo die RootCa Certs herkommen, bzw. nachgedacht hat. Frage: Ist das Thema bei euch auf dem Radar? Werden Probleme erwartet oder sind bereits welche aufgetreten? Ich kann das Thema TLS-Zertifikatsverifikation im Edge aktuell noch nicht so richtig abschätzen.
Anzeige
2015
wie praktisch. Dann kann die NSA jedem Rechner der Welt der immer noch Windows verwendet,kurzmal, remote, seine Speziellen Zertifikate zur Verfügung stellen? So was will man doch.
Und nein, drehen am DNS hilft nichts. MS hat zum Teil feste IP hart im code stehen. Wegen der bösen Viren, wissen schon..
Wenn die IPs hardcodiert sind, dann kann man die doch einfach in der Firmen-Firewall sperren.
So wird der Edge gezwungen, im lokalen Speicher nachzuschauen.
welche willste Sperren?
MS verrät das ja nicht. Viren und so pssssst
und beim nächsten Update kommt eine neue IP in den Code.
Sie haben zig Hunderte Millionen an eigenen IP gehortet via Msnet für ihren Cloud.
Man kann ja versuchen sein Netz komplett alleine zu betreiben.
Updates per WSUS, wozu braucht man Updates?
Mangels Netz Anbindung können ja keine Daten abfließen und
ms365 geht dann natürlich nicht.
… weil du 100% sicher sein willst, das das Update vom Microsoft kommt und nicht aus dem Keller einer Software Bude, die den DNS vom WiFi Hotspot hostet
Dann nutzt man einen WSUS, für den Ausnahmen eingerichtet wurden.
Ich stell mir gerade die Frage, ob Elon Musk Ihn bezgl. des Tweets
a) instant gefeuert (wenn er denn sein Chef wäre)
oder
b) gefeiert hätte ^^
Chrome macht schon lange keine Revocation mehr, und Edge basiert ja auf Chrome. Edge benutzt auch keine Windows-Webpaßwörter und auch nicht SChannel, die TLS-Bibliothek von Windows.