Mabagal ang Visual Studio sa VPN lang? Suriin ang CRL at OCSP

Normal na nagsisimula ang Visual Studio sa bahay, pagkatapos sumasali ang parehong laptop sa corporate tunnel at bawat paglulunsad ay tumitigil nang kalahating minuto sa splash screen. Alisin ang patakaran at mawawala rin ang pagkaantala; alisin ang tunnel at pareho ring nangyayari. Tumpak ang dalawang obserbasyon, kaya patuloy na sinisisi ng dalawang bahagi ang isa't isa. Ang mapagpasyang tanong ay kung ang isang pagtatanong sa pagpapawalang-bisa ng sertipiko ay naghihintay ng landas na iniaalok lamang ng tunnel, o wala itong mahanap.

Sukatin ang pagkuha, hindi ang paglulunsad

Isang patakarang WDAC, na inilagay bilang SiPolicy.p7b na may lagda, ang nagtatakda kung aling mga imahe ang maaaring tumakbo sa makina. Bineberipika ng integridad ng code ang kadena ng lagda ng isang imahe bago ang pagpapatupad, at maaaring kabilang sa beripikasyong iyon ang isang tanong sa pagpapawalang-bisa. Nakasalalay ang sagot sa punto ng pamamahagi ng CRL o sa responder ng OCSP na pinangalanan ng sertipiko sa loob nito.

Karaniwang mga kahilingan sa network ang mga ito, kaya nakasalalay ang gastos sa kung saan naroon ang responder. Kapag naaabot lamang ito sa pamamagitan ng tunnel, o ang pangalan nito ay nalulutas lamang sa pamamagitan ng isang DNS server sa likod ng tunnel, hinihintay ng beripikasyon na maging handa ang tunnel. Naglo-load ang Visual Studio sa pagsisimula ng maraming lagda na assembly at extension, at ang maliit na pagkaantala sa bawat imahe ay nagiging nakikitang paghinto. Walang sira at kumikilos ang patakaran nang eksakto ayon sa pagkaka-configure, kaya lumilitaw na inaayos ng pag-alis ng patakaran ang problema.

Maaaring magdulot ng tawag sa network ang bawat imaheng may lagda

Magsimula sa isang binary na may lagda na nasa disk na, at hilingin sa platform na iberipika ito gamit ang parehong pag-uugali sa pagkuha na ginagamit ng isang paglulunsad. Patakbuhin ang utos nang isang beses sa tunnel at isang beses sa labas nito, pagkatapos ay ihambing ang mga linya ng pagkuha sa halip na ang huling hatol.

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

Inililista ng output ang kadena, ang mga address ng CRL at OCSP, at kung nagtagumpay ang bawat pagkuha. Ang responder na nauubusan ng oras sa tunnel at sumasagot sa labas nito ang ebidensiyang kailangan mo, at mas mabigat ito kaysa sa impresyon ng kabagalan. Kung matagumpay ang pagkuha nang mabagal, itala ang address upang masubukan ng susunod na hakbang ang host na iyon nang direkta.

Lutasin ang hostname ng responder at subukan ang maabot sa labas ng application, dahil ang pangalang hindi nalulutas ay hindi kailanman aayusin ng anumang setting ng client. Ang operational log ng CodeIntegrity ay nagbibigay ng kabilang kalahati ng ebidensiya, na nag-uugnay ng kaganapan sa beripikasyon sa timestamp ng mabagal na paglulunsad.

Paikliin ang pagkaantala nang hindi inaalis ang kontrol

Ang pag-disable ng patakaran o paglipat nito sa audit mode ay nagpapawala ng pagkaantala at nag-aalis ng kontrol na inilagay ng organisasyon, kaya ituring itong maling pag-aayos. Ang mas makitid na opsiyon ay isang pagbabago sa routing upang maabot ang responder sa pamamagitan ng tunnel, isang pagbubukod sa split tunnel para sa mga host ng responder, isang pagwawasto sa DNS kapag nalulutas ang pangalan sa isang address na hindi maabot, o isang sinusuportahang caching proxy para sa data ng pagpapawalang-bisa. Bawat isa ay may ibang may-ari: pagmamay-ari ng PKI team ang maabot ng responder, ng network team ang paghahati ng tunnel, at ng endpoint team ang patakaran.

Ang pagbubukod sa bawat host ng pagpapawalang-bisa mula sa tunnel ay hindi awtomatikong ligtas, dahil ang isang panloob na responder ay maaaring sadyang panloob. Kumpirmahin ang pagbubukod sa team na nagpapatakbo ng PKI bago magsulat ng panuntunang tahimik na nagpapadala ng mga pagsusuri ng sertipiko sa pampublikong internet. Ang pagbabagong ginawa nang walang kumpirmasyong iyon ay ang uri na binabalik sa susunod na pag-refresh ng patakaran.

Iberipika ang cold start pagkatapos ng pagbabago

Sukatin ang cold start sa parehong estado at itago ang mga numero, dahil ang warm start ay halos walang pinapatunayan kapag ang mga assembly ay nasa cache na. Ulitin ang paglulunsad mula sa bagong session upang magamit muli ang landas ng pag-load ng mga extension.

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

Ang naayos na configuration ay nakikipag-ugnayan pa rin sa responder, o gumagamit ng cache path na inaprubahan ng iyong PKI team, at ipinapakita ng log na natatapos ang beripikasyon sa halip na mag-time out. Kumpirmahin na ang isang bagong lagda na application ay nagsisimula pa rin, dahil ang patakarang nagpapahintulot sa lahat ay hindi matagumpay na pag-aayos. Suriin din ang folder ng aktibong patakaran at ang estado ng pagpapatupad, upang malaman na ang patakarang ini-debug mo ang siyang tumatakbo. Itago ang kadena ng sertipiko, ang address ng responder, at ang mga timestamp ng paglulunsad sa parehong ticket, dahil kadalasang inililipat ng renewal ang responder at iniiwan ang panuntunan sa pagbubukod o DNS na lipas na.