Ali lahko veriga strežniških potrdil prepiše shrambo zaupanja odjemalca?

Brskalnik prikaže opozorilo o potrdilu na spletnem mestu, katerega veriga je popolna, in prvi vzgib je popraviti strežnik. Običajno strežnik predstavi točno to, kar bi moral. Odjemalec odloči, katera sidra sprejme, in nobena razporeditev vmesnih potrdil ne more te odločitve spremeniti z drugega konca povezave. Ta meja pojasnjuje večino tega, kar je videti kot težava s potrdilom.

Preverjanje poteka pri odjemalcu, s sidri odjemalca

Preverjanje poti vzame predstavljena potrdila in zgradi verigo do sidra zaupanja, ki ga preveritveni sistem že ima. RFC 5280 opisuje ta model in izbiro sidra postavlja v lokalno izvedbo, ne na strežnik. Aplikacija lahko na vrh doda svojo politiko: pripet ključ, podjetniška shramba zaupanja, ali strožje preverjanje identitete. Seznam potrdil, ki ga strežnik pošlje, je dokaz, ponujen temu procesu, nikoli navodilo zanj.

Popolna veriga torej dokazuje, da ima strežnik dele. Ne dokazuje, da jih bo odjemalec sprejel.

Če želite videti, kaj strežnik dejansko pošlje, zaženite openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts in preštejte potrdila v izpisu. Nepopolna veriga tam je popravek na strani strežnika. Popolna veriga premakne vprašanje na odjemalca in njegova sidra, kjer strežnik nima glasu.

Kaj preverjanje TLS dejansko spremeni

Naprava za preverjanje konča sejo TLS na strani odjemalca in odpre ločeno sejo do prave storitve. Odjemalec nato preveri potrdilo naprave, ki se mora verižiti do sidra, ki mu odjemalec zaupa. Zato upravljane naprave prejmejo koren preverjanja prek upravljanja naprav, in zato osebna naprava brez njega pokaže opozorilo.

Ureditev je namerna in lokalna. Nič v verigi prvotnega strežnika ne more prisiliti neupravljanega brskalnika, da sprejme nadomestno identiteto, in nič v njej ne preprečuje upravljani napravi, da bi to storila.

Zaključek VPN ni dešifriranje HTTPS

Plast VPN prenaša pakete med odjemalcem in prehodom. Njena odstranitev ali branje njene konfiguracije ne razkrije tovora HTTPS v notranjosti.

Seja TLS še vedno poteka med brskalnikom in spletnim strežnikom, z enakimi pravili preverjanja, razen če jo nekaj izrecno konča. Mešanje obeh plasti ustvari zahtevo, naj skrbnik VPN zagotovi potrdilo, medtem ko zadevno potrdilo pripada preveritvenemu posredniku ali samemu mestu. Vprašajte, katera komponenta predstavi potrdilo, preden spremenite katero koli shrambo zaupanja.

Nastavite pričakovanja v komponenti, ki jo nadzorujete

Če upravljate aplikacijo in njenega odjemalca, skupaj določite pričakovano identiteto storitve, sprejete izdajatelje in vse zahteve glede pripenjanja ali preverjanja odjemalca. Načrtujte obnovitev in okrevanje tako, da zakonita sprememba potrdila ne postane izpad. Če upravljate samo javni strežnik, dokumentirajte, kakšno preverjanje zahtevate in katera odjemalčeva okolja podpirate. Pošiljanje prednostne verige ne potrdi naprave neznanca.

Na upravljani opremi neskladje rešujte prek lastnikov aplikacije in omrežja. Izklop preverjanja, dodajanje nerazloženega korena ali poskus preživetja preveritvene politike ne vzpostavi predvidenega razmerja enakopravnih strani.

Rezultat preizkusite v čistem odjemalčevem profilu, ne na stroju, kjer je bila izjema že dodana. To je edino preverjanje, ki pokaže, kaj bo izkusila nova naprava.