Visual Studio wolne tylko przez VPN? Sprawdź CRL i OCSP

Visual Studio uruchamia się normalnie w domu, potem ten sam laptop łączy się z firmowym tunelem i każde uruchomienie stoi pół minuty na ekranie startowym. Usuń zasadę, a opóźnienie zniknie razem z nią; usuń tunel, a stanie się to samo. Obie obserwacje są trafne, dlatego dwa komponenty wciąż obwiniają się nawzajem. Decydujące pytanie brzmi, czy zapytanie o unieważnienie certyfikatu czeka na ścieżkę, którą zapewnia tylko tunel, czy nie znajduje żadnej.

Mierz pobieranie, nie uruchamianie

Jedna zasada WDAC, wdrożona jako podpisany SiPolicy.p7b, decyduje, które obrazy mogą działać na maszynie. Integralność kodu sprawdza łańcuch podpisów obrazu przed wykonaniem, a ta weryfikacja może obejmować pytanie o unieważnienie. Odpowiedź zależy od punktu dystrybucji CRL lub respondera OCSP, który certyfikat wymienia w sobie.

To zwykłe żądania sieciowe, więc ich koszt zależy od tego, gdzie znajduje się responder. Gdy jest dostępny tylko przez tunel, albo jego nazwa jest rozwiązywana tylko przez serwer DNS za tunelem, weryfikacja czeka, aż tunel będzie gotowy. Visual Studio przy starcie wczytuje dużą liczbę podpisanych zestawów i rozszerzeń, a niewielkie opóźnienie na obraz staje się widocznym przestojem. Nic nie jest uszkodzone, a zasada zachowuje się dokładnie tak, jak skonfigurowano, dlatego usunięcie zasady wygląda na naprawę problemu.

Każdy podpisany obraz może wywołać żądanie sieciowe

Zacznij od podpisanego pliku binarnego, który już jest na dysku, i poproś platformę o jego weryfikację z takim samym zachowaniem pobierania, jakiego używa uruchomienie. Wykonaj polecenie raz w tunelu i raz poza nim, a następnie porównaj wiersze pobierania zamiast ostatecznego werdyktu.

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

Dane wyjściowe wymieniają łańcuch, adresy CRL i OCSP oraz to, czy każde pobieranie się powiodło. Responder, który w tunelu przekracza limit czasu, a poza nim odpowiada, jest dowodem, którego potrzebujesz, i waży znacznie więcej niż wrażenie powolności. Jeśli pobieranie kończy się powoli, zapisz adres, aby następny krok mógł przetestować ten host bezpośrednio.

Rozwiąż nazwę hosta respondera i sprawdź dostępność poza aplikacją, ponieważ nazwy, która się nie rozwiązuje, nie naprawi żadne ustawienie klienta. Dziennik operacyjny CodeIntegrity dostarcza drugą połowę dowodu, wiążąc zdarzenie weryfikacji ze znacznikiem czasu wolnego uruchomienia.

Skróć opóźnienie, nie usuwając kontroli

Wyłączenie zasady lub przełączenie jej w tryb audytu usuwa opóźnienie i zabiera kontrolę wdrożoną przez organizację, więc traktuj to jako niewłaściwą naprawę. Węższe opcje to zmiana routingu, aby responder był osiągalny przez tunel, wyjątek w tunelu dzielonym dla hostów respondera, korekta DNS, gdy nazwa rozwiązuje się na nieosiągalny adres, lub obsługiwany proxy z pamięcią podręczną dla danych o unieważnieniu. Każda ma innego właściciela: zespół PKI odpowiada za osiągalność respondera, zespół sieci za podział tunelu, a zespół punktów końcowych za zasadę.

Wykluczenie każdego hosta unieważnienia z tunelu nie jest automatycznie bezpieczne, ponieważ wewnętrzny responder może być wewnętrzny celowo. Potwierdź wyjątek z zespołem, który prowadzi PKI, zanim napiszesz regułę, która po cichu wysyła sprawdzanie certyfikatów do publicznego internetu. Zmiana bez tego potwierdzenia to ta, którą cofa się przy następnym odświeżeniu zasady.

Po zmianie sprawdź zimny start

Zmierz zimny start w obu stanach i zachowaj liczby, bo ciepły start prawie niczego nie dowodzi, gdy zestawy są już w pamięci podręcznej. Powtórz uruchomienie z nowej sesji, aby ścieżka ładowania rozszerzeń została ponownie przećwiczona.

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

Naprawiona konfiguracja nadal kontaktuje się z responderem lub używa ścieżki pamięci podręcznej zatwierdzonej przez twój zespół PKI, a dziennik pokazuje, że weryfikacja kończy się, zamiast przekraczać limit czasu. Potwierdź, że niedawno podpisana aplikacja nadal się uruchamia, bo zasada, która pozwala na wszystko, nie jest udaną naprawą. Sprawdź też folder aktywnej zasady i stan egzekwowania, aby było wiadomo, że debugowana zasada jest tą działającą. Trzymaj łańcuch certyfikatów, adres respondera i znaczniki czasu uruchomienia w jednym bilecie, bo odnowienie zwykle przenosi responder i zostawia regułę wyjątku lub DNS nieaktualną.