Visual Studio lento solo in VPN? Controllate CRL e OCSP

Visual Studio si avvia normalmente a casa, poi lo stesso portatile si collega al tunnel aziendale e ogni avvio resta mezzo minuto sulla schermata iniziale. Togliete la policy e il ritardo se ne va con lei; togliete il tunnel e succede la stessa cosa. Entrambe le osservazioni sono esatte, per questo i due componenti si accusano a vicenda. La domanda decisiva è se una verifica di revoca del certificato attende un percorso che solo il tunnel fornisce, o se non ne trova nessuno.

Misurate il recupero, non l’avvio

Una policy WDAC, distribuita come file SiPolicy.p7b firmato, decide quali immagini possono essere eseguite sulla macchina. L’integrità del codice convalida la catena di firme di un’immagine prima dell’esecuzione, e tale convalida può includere una domanda di revoca. La risposta dipende dal punto di distribuzione CRL o dal responder OCSP che il certificato nomina al proprio interno.

Sono richieste di rete ordinarie, quindi il loro costo dipende da dove si trova il responder. Quando è raggiungibile solo attraverso il tunnel, o il suo nome si risolve solo tramite un server DNS dietro il tunnel, la convalida attende che il tunnel sia pronto. Visual Studio carica all’avvio un gran numero di assembly ed estensioni firmati, e un piccolo ritardo per immagine diventa un blocco visibile. Nulla è malformato e la policy si comporta esattamente come configurata, per questo rimuoverla sembra risolvere il problema.

Ogni immagine firmata può innescare una chiamata di rete

Partite da un binario firmato già presente sul disco e chiedete alla piattaforma di verificarlo con lo stesso comportamento di recupero usato da un avvio. Eseguite il comando una volta sul tunnel e una fuori, poi confrontate le righe di recupero invece del verdetto finale.

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

L’output elenca la catena, gli indirizzi CRL e OCSP e se ogni recupero è riuscito. Un responder che va in timeout sul tunnel e risponde fuori è la prova che vi serve, e pesa molto più di un’impressione di lentezza. Se il recupero riesce lentamente, annotate l’indirizzo così il passo successivo può testare quell’host direttamente.

Risolvete il nome host del responder e provate la raggiungibilità fuori dall’applicazione, perché un nome che non si risolve non verrà mai riparato da un’impostazione del client. Il registro operativo di CodeIntegrity fornisce l’altra metà della prova, collegando un evento di convalida al timestamp dell’avvio lento.

Riducete il ritardo senza togliere il controllo

Disattivare la policy o portarla in modalità di controllo fa sparire il ritardo e toglie il controllo distribuito dall’organizzazione, quindi consideratela la riparazione sbagliata. Le opzioni più strette sono una modifica del routing perché il responder sia raggiungibile attraverso il tunnel, un’esclusione nello split tunneling per gli host del responder, una correzione DNS quando il nome si risolve su un indirizzo irraggiungibile, o un proxy di cache supportato per i dati di revoca. Ognuna ha un proprietario diverso: il team PKI possiede la raggiungibilità del responder, il team di rete possiede la divisione del tunnel e il team degli endpoint possiede la policy.

Escludere ogni host di revoca dal tunnel non è automaticamente sicuro, perché un responder interno può essere interno di proposito. Confermate l’esclusione con il team che gestisce la PKI prima di scrivere una regola che invia silenziosamente i controlli dei certificati verso internet pubblico. Una modifica fatta senza quella conferma è del tipo che viene annullata al successivo aggiornamento della policy.

Verificate un avvio a freddo dopo la modifica

Misurate un avvio a freddo in entrambi gli stati e conservate i numeri, perché un avvio a caldo non dimostra quasi nulla una volta che gli assembly sono in cache. Ripetete l’avvio da una sessione nuova perché il percorso di caricamento delle estensioni venga esercitato di nuovo.

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

Una configurazione riparata contatta ancora il responder, o usa un percorso di cache approvato dal vostro team PKI, e il registro mostra che la convalida si completa invece di andare in timeout. Confermate che un’applicazione firmata di recente si avvii ancora, perché una policy che permette tutto non è una riparazione riuscita. Controllate anche la cartella della policy attiva e lo stato di applicazione, così che la policy che state esaminando sia quella in esecuzione. Tenete la catena dei certificati, l’indirizzo del responder e i timestamp di avvio nello stesso ticket, perché un rinnovo di solito sposta il responder e lascia la regola di esclusione o DNS obsoleta.