Visual Studio lent doar în VPN? Verificați CRL și OCSP

Visual Studio pornește normal acasă, apoi același laptop se conectează la tunelul corporativ și fiecare pornire stă o jumătate de minut pe ecranul de pornire. Scoateți politica și întârzierea dispare odată cu ea; scoateți tunelul și se întâmplă același lucru. Ambele observații sunt corecte, de aceea cele două componente se învinovățesc reciproc. Întrebarea decisivă este dacă o interogare de revocare a certificatului așteaptă o rută oferită doar de tunel sau nu găsește niciuna.

Măsurați aducerea, nu pornirea

O politică WDAC, implementată ca fișier SiPolicy.p7b semnat, decide ce imagini pot rula pe mașină. Integritatea codului validează lanțul de semnături al unei imagini înainte de execuție, iar acea validare poate include o întrebare de revocare. Răspunsul depinde de punctul de distribuție CRL sau de respondenul OCSP pe care certificatul îl numește în interiorul său.

Sunt cereri de rețea obișnuite, așa că costul lor depinde de unde se află respondenul. Când este accesibil doar prin tunel, sau numele său se rezolvă doar printr-un server DNS din spatele tunelului, validarea așteaptă ca tunelul să fie gata. Visual Studio încarcă la pornire un număr mare de ansambluri și extensii semnate, iar o mică întârziere pe imagine devine o oprire vizibilă. Nimic nu este defect și politica se comportă exact cum este configurată, de aceea scoaterea politicii pare să rezolve problema.

Fiecare imagine semnată poate declanșa un apel de rețea

Începeți cu un binar semnat care este deja pe disc și cereți platformei să îl verifice cu același comportament de aducere pe care îl folosește o pornire. Rulați comanda o dată în tunel și o dată în afara lui, apoi comparați liniile de aducere în loc de verdictul final.

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

Ieșirea enumeră lanțul, adresele CRL și OCSP și dacă fiecare aducere a reușit. Un responden care expiră în tunel și răspunde în afara lui este dovada de care aveți nevoie și cântărește mult mai mult decât o impresie de încetineală. Dacă aducerea reușește lent, notați adresa pentru ca pasul următor să poată testa acel host direct.

Rezolvați numele de gazdă al respondenului și testați accesibilitatea în afara aplicației, deoarece un nume care nu se rezolvă nu va fi reparat niciodată de o setare a clientului. Jurnalul operațional CodeIntegrity oferă cealaltă jumătate a dovezii, legând un eveniment de validare de momentul pornirii lente.

Scurtați întârzierea fără a elimina controlul

Dezactivarea politicii sau trecerea ei în modul de audit face întârzierea să dispară și elimină controlul implementat de organizație, așa că tratați asta ca reparația greșită. Opțiunile mai înguste sunt o modificare a rutării astfel încât respondenul să fie accesibil prin tunel, o excepție în tunelul divizat pentru gazdele respondenului, o corecție DNS când numele se rezolvă într-o adresă inaccesibilă, sau un proxy de cache acceptat pentru datele de revocare. Fiecare are alt proprietar: echipa PKI deține accesibilitatea respondenului, echipa de rețea deține divizarea tunelului, iar echipa de endpoint deține politica.

Excluderea fiecărei gazde de revocare din tunel nu este automat sigură, deoarece un responden intern poate fi intern intenționat. Confirmați excluderea cu echipa care operează PKI înainte de a scrie o regulă care trimite în liniște verificările de certificate către internetul public. O modificare făcută fără acea confirmare este genul care se anulează la următoarea actualizare a politicii.

Verificați o pornire la rece după modificare

Măsurați o pornire la rece în ambele stări și păstrați numerele, deoarece o pornire la cald nu demonstrează aproape nimic după ce ansamblurile sunt în cache. Repetați pornirea dintr-o sesiune nouă, astfel încât calea de încărcare a extensiilor să fie exersată din nou.

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

O configurație reparată contactează în continuare respondenul sau folosește o cale de cache aprobată de echipa dumneavoastră PKI, iar jurnalul arată validarea finalizându-se în loc să expire. Confirmați că o aplicație semnată recent încă pornește, deoarece o politică ce permite tot nu este o reparație reușită. Verificați și folderul politicii active și starea de aplicare, ca să se știe că politica pe care o depanați este cea care rulează. Păstrați lanțul de certificate, adresa respondenului și momentele pornirii în același tichet, deoarece o reînnoire mută de obicei respondenul și lasă regula de excludere sau DNS învechită.