Kas serveri sertifikaadiahel saab kliendi usaldushoidla üle kirjutada?

Brauser näitab sertifikaadihoiatust saidil, mille ahel on täielik, ja esimene instinkt on serverit parandada. Tavaliselt esitab server täpselt seda, mida peaks. Klient otsustab, milliseid ankruid ta aktsepteerib, ja ükski vahesertifikaatide paigutus ei saa seda otsust ühenduse teisest otsast muuta. See piir selgitab suuremat osa sellest, mis näeb välja nagu sertifikaadiprobleem.

Valideerimine toimub kliendis, kliendi ankrutega

Teekonna valideerimine võtab esitatud sertifikaadid ja ehitab ahela usaldusankruni, mis valideerival süsteemil juba on. RFC 5280 kirjeldab seda mudelit ja asetab ankru valiku kohalikku rakendusse, mitte serverisse. Rakendus saab selle peale lisada oma poliitika: kinnitatud võti, ettevõtte usaldushoidla, või rangem identiteedikontroll. Sertifikaatide loend, mille server saadab, on tõend, mis on sellele protsessile pakutud, mitte kunagi korraldus sellele.

Nii tõestab täielik ahel, et serveril on tükid olemas. See ei tõesta, et klient need aktsepteerib.

Et näha, mida server tegelikult saadab, käivitage openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts ja loendage väljundis olevad sertifikaadid. Puudulik ahel seal on serveripoolne parandus. Täielik ahel viib küsimuse kliendile ja selle ankrutele, kus serveril pole häält.

Mida TLS-i kontroll tegelikult muudab

Kontrollseade lõpetab kliendipoolse TLS-i sessiooni ja avab eraldi sessiooni tegeliku teenusega. Seejärel valideerib klient seadme sertifikaadi, mis peab ahelama ankruni, mida klient usaldab. Seetõttu saavad hallatavad seadmed kontrollijuure seadmehalduse kaudu ja seetõttu näitab isiklik seade ilma selleta hoiatust.

Lahendus on tahtlik ja kohalik. Miski algse serveri ahelas ei saa sundida haldamata brauserit asendusidentiteeti aktsepteerima, ja miski selles ei takista hallatavat seadet seda tegema.

VPN-i lõpetamine ei ole HTTPS-i dešifreerimine

VPN-kiht kannab pakette kliendi ja lüüsi vahel. Selle eemaldamine või konfiguratsiooni lugemine ei paljasta sees olevat HTTPS-i kandevõimet.

TLS-i sessioon jookseb endiselt brauseri ja veebiserveri vahel, samade valideerimisreeglitega, kui miski ei lõpeta seda selgesõnaliselt. Kahe kihi segamine tekitab palve VPN-i administraatorile sertifikaat esitada, kuigi kõnealune sertifikaat kuulub kontrollpuhverserverile või saidile endale. Küsige, milline komponent sertifikaati esitab, enne kui muudate ükskõik millist usaldushoidlat.

Seadke ootused komponendis, mida te kontrollite

Kui haldate rakendust ja selle klienti, määrake koos oodatav teenuseidentiteet, aktsepteeritud väljaandjad ja kõik kinnitamise või kliendi autentimise nõuded. Planeerige uuendamine ja taastamine nii, et seaduslik sertifikaadimuudatus ei muutuks katkestuseks. Kui haldate ainult avalikku serverit, dokumenteerige, millist autentimist nõuate ja milliseid kliendikeskkondi toetate. Eelistatud ahela saatmine ei tõesta võõra seadme õigsust.

Hallatud seadmetel lahendage ühilduvus rakenduse ja võrgu omanike kaudu. Kontrollimise keelamine, seletamata juure lisamine või katse kontrollipoliitikast üle kasvada ei loo kavandatud võrdset suhet.

Testige tulemust puhtal kliendiprofiilil, mitte masinas, kuhu on juba erand lisatud. See on ainus kontroll, mis näitab, mida uus seade kogeb.