A mundet një zinxhir certifikatash i serverit të anashkalojë ruajtësin e besimit të klientit?

Shfletuesi shfaq një paralajmërim certifikate në një sajt, zinxhiri i të cilit është i plotë, dhe instinkti i parë është të rregullohet serveri. Zakonisht serveri paraqet pikërisht atë që duhet. Klienti vendos cilat ankora pranon, dhe asnjë renditje e certifikatave të ndërmjetme nuk mund ta ndryshojë atë vendim nga ana tjetër e lidhjes. Ky kufi shpjegon pjesën më të madhe të asaj që duket si problem certifikate.

Validimi ekzekutohet në klient, me ankorat e klientit

Validimi i shtegut merr certifikatat e paraqitura dhe ndërton një zinxhir deri në një ankorë besimi që sistemi validues e ka tashmë. RFC 5280 përshkruan atë model dhe e vendos zgjedhjen e ankorës në implementimin lokal, jo në server. Një aplikacion mund të shtojë politikën e vet sipër: një çelës i fiksuar, një ruajtës besimi ndërmarrjeje, ose një verifikim identiteti më i rreptë. Lista e certifikatave që dërgon një server është provë që i ofrohet atij procesi, kurrë udhëzim për të.

Pra, një zinxhir i plotë provon që serveri i ka pjesët. Nuk provon që klienti do t’i pranojë ato.

Për të parë çfarë dërgon në të vërtetë serveri, ekzekutoni openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts dhe numëroni certifikatat në dalje. Një zinxhir i paplotë atje është rregullim nga ana e serverit. Një zinxhir i plotë e zhvendos pyetjen te klienti dhe ankorat e tij, ku serveri nuk ka votë.

Çfarë ndryshon në të vërtetë inspektimi i TLS

Një pajisje inspektimi përfundon sesionin TLS nga ana e klientit dhe hap një sesion të veçantë drejt shërbimit real. Klienti pastaj validon certifikatën e pajisjes, e cila duhet të zinxhirohet deri në një ankorë që klienti i beson. Kjo është arsyeja pse pajisjet e menaxhuara e marrin rrënjën e inspektimit përmes menaxhimit të pajisjeve, dhe pse një pajisje personale pa të shfaq një paralajmërim.

Rregullimi është i qëllimshëm dhe lokal. Asgjë në zinxhirin e serverit origjinal nuk mund të detyrojë një shfletues të pamenaxhuar të pranojë identitetin zëvendësues, dhe asgjë në të nuk e pengon një pajisje të menaxhuar ta bëjë këtë.

Përfundimi i VPN nuk është dekriptim i HTTPS

Një shtresë VPN transporton paketa midis një klienti dhe një porte. Heqja e saj, ose leximi i konfigurimit të saj, nuk zbulon një ngarkesë HTTPS brenda.

Sesioni TLS vazhdon të ekzekutohet midis shfletuesit dhe serverit web, me të njëjtat rregulla validimi, përveç nëse diçka e përfundon atë në mënyrë eksplicite. Përzierja e dy shtresave krijon një kërkesë drejtuar administratorit të VPN për të siguruar certifikatën, ndërsa certifikata në fjalë i përket një përfaqësuesi inspektimi ose vetë sajtit. Pyetni cili komponent po paraqet certifikatën përpara se të ndryshoni çdo ruajtës besimi.

Vendosni pritshmëritë në komponentin që kontrolloni

Nëse administroni aplikacionin dhe klientin e tij, përcaktoni bashkë identitetin e pritur të shërbimit, emetuesit e pranuar dhe çdo kërkesë për fiksim ose vërtetim klienti. Planifikoni rinovimin dhe rikuperimin, që një ndryshim legitim certifikate të mos bëhet ndërprerje. Nëse administroni vetëm serverin publik, dokumentoni çfarë vërtetimi kërkoni dhe cilat mjedise klienti mbështesni. Dërgimi i një zinxhiri të preferuar nuk certifikon pajisjen e një të huaji.

Në pajisjet e menaxhuara, zgjidhni papajtueshmërinë përmes pronarëve të aplikacionit dhe rrjetit. Çaktivizimi i verifikimit, shtimi i një rrënje të pashpjeguar ose përpjekja për të tejkaluar një politikë inspektimi nuk vendosin marrëdhënien e synuar mes palëve.

Testoni rezultatin në një profil klienti të pastër, jo në makinën ku është shtuar tashmë një përjashtim. Ky është kontrolli i vetëm që tregon çfarë do të përjetojë një pajisje e re.