Aling mga validator ang naaapektuhan ng karagdagang root certificate?

Nakakita ka ng root certificate na hindi dapat naroon, at ang unang tanong ay kaninong pagkakakilanlan ang maaari nitong gayahin. Ang tapat na sagot ay depende sa kung aling software ang kumukonsulta sa tindahang iyon at kung paano bineberipika ng iyong VPN ang gateway nito. Ang browser, package manager at VPN client na may naka-pin na fingerprint ay hindi laging nagbabahagi ng parehong desisyon sa pagtitiwala. I-map ang mga validator bago magpasya sa saklaw.

Ang root sa system store ay hindi unibersal na susi

Ang pag-install ng root ay ginagawang katanggap-tanggap ang mga certificate na pinirmahan ng susing iyon para sa mga programang gumagamit ng apektadong tindahan. Hindi nito ginagawang katanggap-tanggap ang mga ito sa lahat ng dako nang awtomatiko, dahil ang ilang aplikasyon ay may sariling bundle o nagsusuri ng naka-pin na halaga. Hindi rin nito pinatutunayan na may nagpatakbo ng code sa makina; ang pagbabago ng pagtitiwala ay isang kakayahan sa marami. Ituring ang certificate bilang natuklasang kailangang limitahan, hindi bilang buong insidente.

Ang tindahan ay kasinghalaga ng certificate: ang bundle sa antas ng gumagamit at ang anchor sa antas ng system ay umabot sa magkaibang mamimili.

I-map ang bawat validator at ang pinagmumulan ng pagtitiwala nito

Isulat ang bawat component na nagbeberipika ng mga certificate para sa apektadong workflow: browser, package manager, mail client, VPN. Pagkatapos hanapin ang pinagmumulan ng pagtitiwala na binabasa ng bawat isa.

ls /usr/local/share/ca-certificates
trust list | grep -i -E "vpn|corp"

Ipinapakita ng listahan ng direktoryo ang mga anchor na idinagdag nang lokal sa mga sistemang tulad ng Debian, at ipinapakita ng listahan ng pagtitiwala kung ano ang inilalantad ng system store sa ngayon. Ang browser na may sariling tindahan ay hindi lalabas doon, at ang aplikasyong Java o Python ay maaaring gumamit ng isa pang bundle. Itala kung aling mga entry ang inaasahan at alin ang hindi, gamit ang fingerprint sa halip na ang ipinapakitang pangalan lamang. Ang listahang iyon ang kailangan ng tumutugon sa insidente bago magbura ng anuman.

Suriin ang sariling peer validation ng VPN

Ang VPN na may pribadong CA o tahasang fingerprint ay sinusuri ang gateway ayon sa sarili nitong configuration. Ihambing ang inaasahan ng client sa ipinapakita ng gateway.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -subject

Ibinibigay ng output ang SHA-256 fingerprint at subject ng certificate na ipinapakita ng endpoint, na maaari mong ihambing sa naka-configure na halaga. OpenVPN ay may opsyon sa peer fingerprint na gumagawa ng paghahambing na iyon para sa tunnel nang hindi hinihiling na tanggapin ng system store ang signer. Ang kalayaan na iyon ay kapaki-pakinabang para sa tunnel at walang sinasabi tungkol sa browser. Hindi rin ito nakakatulong kung ang inaasahang fingerprint ay kinopya mula sa kahina-hinalang koneksyon sa simula pa.

Limitahan ang insidente lampas sa certificate

Gamitin ang pamamaraan ng may-ari ng device upang alisin ang hindi awtorisadong anchor at hanapin ang mga pagbabagong karaniwang kasama nito: bagong serbisyo, binagong client, binagong setting ng proxy. Sa pinamamahalaang makina, kumpirmahin ang lehitimong configuration bago magbura ng materyal na umaasa ang ibang software. Para sa bawat validator, itala kung saan nagmumula ang pagtitiwala nito, anong pagkakakilanlan ang inaasahan at paano mo kinumpirma na tama ang kasalukuyang configuration. Ang gumaganang tunnel pagkatapos ng paglilinis ay isang obserbasyon, hindi patunay na malinis ang endpoint.

Pagkatapos ay muling subukan ang mga workflow na gumamit ng tindahan, dahil ang pag-alis ng anchor ay maaaring makasira ng panloob na serbisyo na lehitimong umaasa rito. Kumpleto ang pagbawi kapag gumagana ang inaasahang ugnayan ng pagtitiwala at hindi gumagana ang hindi inaasahan.