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 застарена.