Visual Studio nur im VPN langsam? CRL und OCSP prüfen

Visual Studio startet zu Hause normal, dann verbindet sich dasselbe Notebook mit dem Firmentunnel, und jeder Start hängt eine halbe Minute am Startbildschirm. Nehmen Sie die Richtlinie weg, und die Verzögerung verschwindet mit ihr; nehmen Sie den Tunnel weg, und dasselbe passiert. Beide Beobachtungen stimmen, weshalb die beiden Komponenten sich ständig gegenseitig beschuldigen. Die entscheidende Frage ist, ob eine Zertifikatssperrabfrage auf einen Pfad wartet, den nur der Tunnel bietet, oder ob sie gar keinen findet.

Messen Sie den Abruf, nicht den Start

Eine WDAC-Richtlinie, bereitgestellt als signierte SiPolicy.p7b, legt fest, welche Images auf dem Rechner laufen dürfen. Die Codeintegrität prüft die Signaturkette eines Images vor der Ausführung, und diese Prüfung kann eine Sperrfrage enthalten. Die Antwort hängt vom CRL-Verteilungspunkt oder vom OCSP-Responder ab, den das Zertifikat in sich benennt.

Das sind gewöhnliche Netzwerkanfragen, ihre Kosten hängen also davon ab, wo der Responder liegt. Wenn er nur über den Tunnel erreichbar ist oder sein Name sich nur über einen DNS-Server hinter dem Tunnel auflösen lässt, wartet die Prüfung, bis der Tunnel bereit ist. Visual Studio lädt beim Start eine große Zahl signierter Assemblys und Erweiterungen, und eine kleine Verzögerung pro Image wird zu einem sichtbaren Stillstand. Nichts ist fehlerhaft, und die Richtlinie verhält sich genau wie konfiguriert, weshalb das Entfernen der Richtlinie das Problem zu beheben scheint.

Jedes signierte Image kann einen Netzwerkaufruf auslösen

Beginnen Sie mit einer signierten Binärdatei, die bereits auf der Platte liegt, und lassen Sie die Plattform sie mit demselben Abrufverhalten prüfen, das ein Start verwendet. Führen Sie den Befehl einmal im Tunnel und einmal außerhalb aus und vergleichen Sie dann die Abrufzeilen statt des endgültigen Urteils.

certutil -verify -urlfetch C:\Tools\Contoso.Editor.dll
nslookup ocsp.contoso.example
Test-NetConnection ocsp.contoso.example -Port 80

Die Ausgabe listet die Kette, die CRL- und OCSP-Adressen und ob jeder Abruf erfolgreich war. Ein Responder, der im Tunnel in eine Zeitüberschreitung läuft und außerhalb antwortet, ist der Beweis, den Sie brauchen, und wiegt weit mehr als ein Eindruck von Langsamkeit. Wenn der Abruf langsam gelingt, notieren Sie die Adresse, damit der nächste Schritt diesen Host direkt testen kann.

Lösen Sie den Hostnamen des Responders auf und testen Sie die Erreichbarkeit außerhalb der Anwendung, denn ein Name, der sich nicht auflösen lässt, wird durch keine Client-Einstellung repariert. Das operative CodeIntegrity-Protokoll liefert die andere Hälfte des Beweises und verknüpft ein Prüfereignis mit dem Zeitstempel des langsamen Starts.

Verkürzen Sie die Verzögerung, ohne die Kontrolle zu entfernen

Das Deaktivieren der Richtlinie oder das Umschalten in den Auditmodus lässt die Verzögerung verschwinden und entfernt die Kontrolle, die die Organisation eingeführt hat, also ist das die falsche Reparatur. Die engeren Optionen sind eine Routingänderung, damit der Responder über den Tunnel erreichbar ist, eine Split-Tunneling-Ausnahme für die Responder-Hosts, eine DNS-Korrektur, wenn der Name auf eine nicht erreichbare Adresse auflöst, oder ein unterstützter Caching-Proxy für Sperrdaten. Jede hat einen anderen Eigentümer: Das PKI-Team verantwortet die Erreichbarkeit des Responders, das Netzwerkteam die Tunnelaufteilung und das Endpoint-Team die Richtlinie.

Jeden Sperrhost aus dem Tunnel auszuschließen ist nicht automatisch sicher, denn ein interner Responder kann absichtlich intern sein. Bestätigen Sie die Ausnahme mit dem Team, das die PKI betreibt, bevor Sie eine Regel schreiben, die Zertifikatsprüfungen still ins öffentliche Internet schickt. Eine Änderung ohne diese Bestätigung ist die Sorte, die beim nächsten Richtlinien-Refresh zurückgenommen wird.

Prüfen Sie nach der Änderung einen Kaltstart

Messen Sie einen Kaltstart in beiden Zuständen und behalten Sie die Zahlen, denn ein Warmstart beweist fast nichts, sobald die Assemblys im Cache liegen. Wiederholen Sie den Start aus einer neuen Sitzung, damit der Ladepfad der Erweiterungen erneut durchlaufen wird.

Get-WinEvent -LogName Microsoft-Windows-CodeIntegrity/Operational -MaxEvents 40 |
  Where-Object { $_.TimeCreated -gt (Get-Date).AddMinutes(-10) }
Get-ChildItem C:\Windows\System32\CodeIntegrity\CiPolicies\Active
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Eine reparierte Konfiguration kontaktiert den Responder weiterhin oder nutzt einen Cache-Pfad, den Ihr PKI-Team genehmigt hat, und das Protokoll zeigt, dass die Prüfung abgeschlossen wird statt in eine Zeitüberschreitung zu laufen. Bestätigen Sie, dass eine neu signierte Anwendung weiterhin startet, denn eine Richtlinie, die alles erlaubt, ist keine erfolgreiche Reparatur. Prüfen Sie auch den Ordner der aktiven Richtlinie und den Durchsetzungsstatus, damit bekannt ist, dass die Richtlinie, die Sie debuggen, auch die laufende ist. Halten Sie die Zertifikatskette, die Responder-Adresse und die Startzeitstempel im selben Ticket, denn eine Erneuerung verschiebt meist den Responder und lässt die Ausnahme- oder DNS-Regel veralten.