Visual Studio бавен само през VPN? Проверете CRL и OCSP

Visual Studio стартира нормално вкъщи, после същият лаптоп се присъединява към корпоративния тунел и всяко стартиране стои на началния екран половин минута. Махнете политиката и забавянето изчезва с нея; махнете тунела и се случва същото. И двете наблюдения са точни, затова двата компонента постоянно се обвиняват взаимно. Решаващият въпрос е дали проверката за отменен сертификат чака път, който само тунелът предоставя, или изобщо не намира такъв.

Измерете изтеглянето, не стартирането

Политика WDAC, разгърната като подписан SiPolicy.p7b, решава кои образи могат да се изпълняват на машината. Целостта на кода проверява веригата от подписи на образа преди изпълнение и тази проверка може да включва въпрос за отмяна. Отговорът зависи от точката за разпространение на CRL или от OCSP ответника, който сертификатът посочва вътре в себе си.

Това са обикновени мрежови заявки, така че цената им зависи от това къде живее ответникът. Когато е достъпен само през тунела или името му се решава само чрез DNS сървър зад тунела, проверката чака тунелът да е готов. Visual Studio зарежда при стартиране голям брой подписани сборки и разширения и малко забавяне за всеки образ се превръща в забележимо задържане. Нищо не е повредено и политиката се държи точно както е конфигурирана, затова премахването ѝ изглежда като поправка.

Всеки подписан образ може да задейства мрежово повикване

Започнете с подписан двоичен файл, който вече е на диска, и помолете платформата да го провери със същото поведение на изтегляне, което използва стартирането. Изпълнете командата веднъж в тунела и веднъж извън него, после сравнете редовете за изтегляне, а не крайната присъда.

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

Изходът изброява веригата, адресите на CRL и OCSP и дали всяко изтегляне е успешно. Ответник, който изтича в тунела и отговаря извън него, е доказателството, което ви трябва, и тежи много повече от впечатление за бавност. Ако изтеглянето успява бавно, запишете адреса, за да може следващата стъпка да тества този хост директно.

Решете името на хоста на ответника и тествайте достъпността извън приложението, защото име, което не се решава, никога няма да бъде поправено от настройка на клиента. Оперативният журнал на CodeIntegrity дава другата половина от доказателствата, свързвайки събитие за проверка с времевата марка на бавното стартиране.

Съкратете забавянето, без да премахвате контрола

Изключването на политиката или преминаването ѝ в режим на одит премахва забавянето и маха контрола, който организацията е разгърнала, затова го считайте за грешна поправка. По-тесните варианти са промяна в маршрутизацията, така че ответникът да е достъпен през тунела, изключение в разделен тунел за хостовете на ответника, корекция на DNS, когато името се решава към недостъпен адрес, или поддържан кеширащ прокси за данни за отмяна. Всяко има различен собственик: екипът по PKI отговаря за достъпността на ответника, мрежовият екип — за разделянето на тунела, а екипът по крайни точки — за политиката.

Изключването на всеки хост за отмяна от тунела не е автоматично безопасно, тъй като вътрешният ответник може да е вътрешен умишлено. Потвърдете изключението с екипа, който управлява PKI, преди да напишете правило, което тихо изпраща проверките на сертификати към публичния интернет. Промяна без това потвърждение е от онзи вид, който се връща назад при следващото обновяване на политиката.

Проверете студен старт след промяната

Измерете студен старт и в двете състояния и запазете числата, защото топлият старт не доказва почти нищо, след като сборките са в кеша. Повторете стартирането от нова сесия, за да се упражни отново пътят за зареждане на разширенията.

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

Поправената конфигурация все още се свързва с ответника или използва кеширащ път, одобрен от вашия екип по PKI, а журналът показва, че проверката завършва, вместо да изтича. Потвърдете, че новоподписано приложение все още стартира, защото политика, която разрешава всичко, не е успешна поправка. Проверете и папката на активната политика и състоянието на прилагане, за да е известно, че политиката, която отстранявате, е тази, която работи. Дръжте веригата от сертификати, адреса на ответника и времената на стартиране в един и същ тикет, защото подновяването обикновено мести ответника и оставя правилото за изключване или DNS остаряло.