Ĉu servila atestila ĉeno povas superregi la fidostokejon de la kliento?

Retumilo montras atestilan averton ĉe retejo kies ĉeno estas plena, kaj la unua instinkto estas ripari la servilon. Kutime la servilo prezentas ĝuste tion, kion ĝi devus. La kliento decidas, kiujn ankrojn ĝi akceptas, kaj neniu aranĝo de interaj atestiloj povas ŝanĝi tiun decidon de la alia fino de la konekto. Tiu limo klarigas la plejparton de tio, kio aspektas kiel atestila problemo.

Validigo okazas ĉe la kliento, kun la ankroj de la kliento

Pado-validigo prenas la prezentitajn atestilojn kaj konstruas ĉenon ĝis fido-ankro, kiun la validiga sistemo jam posedas. RFC 5280 priskribas tiun modelon, kaj ĝi metas la elekton de ankro ĉe la loka efektivigo anstataŭ ĉe la servilo. Aplikaĵo povas aldoni sian propran politikon supre: fiksita ŝlosilo, entreprena fidostokejo, aŭ pli strikta identeca kontrolo. La atestila listo, kiun servilo sendas, estas pruvo ofertita al tiu procezo, neniam instrukcio al ĝi.

Do plena ĉeno pruvas, ke la servilo havas la pecojn. Ĝi ne pruvas, ke la kliento akceptos ilin.

Por vidi, kion la servilo efektive sendas, rulu openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts kaj kalkulu la atestilojn en la eligilo. Neplena ĉeno tie estas riparo ĉe la servila flanko. Plena ĉeno transigas la demandon al la kliento kaj ĝiaj ankroj, kie la servilo havas neniun voĉdonon.

Kion TLS-inspektado efektive ŝanĝas

Inspekta aparato finas la TLS-sesion ĉe la klienta flanko kaj malfermas apartan sesion al la reala servo. La kliento tiam validigas la atestilon de la aparato, kiu devas ĉeniĝi al ankro, kiun la kliento fidas. Tial administrataj aparatoj ricevas la inspektan radikon per aparata administrado, kaj tial persona aparato sen ĝi montras averton.

La aranĝo estas intenca kaj loka. Nenio en la ĉeno de la origina servilo povas devigi neadministratan retumilon akcepti la anstataŭan identecon, kaj nenio en ĝi malhelpas administrata aparato fari tion.

VPN-finado ne estas HTTPS-malĉifrado

VPN-tavolo portas pakaĵojn inter kliento kaj kluzo. Forigi ĝin, aŭ legi ĝian agordon, ne malkaŝas HTTPS-ŝarĝon interne.

La TLS-sesio ankoraŭ iras inter la retumilo kaj la retservilo, kun la samaj validigaj reguloj, krom se io eksplicite finas ĝin. Konfuzi la du tavolojn kreas peton al la VPN-administranto liveri la atestilon, dum la koncerna atestilo apartenas al inspekta prokurilo aŭ al la retejo mem. Demandu, kiu komponanto prezentas la atestilon, antaŭ ol ŝanĝi ajnan fidostokejon.

Starigu atendojn en la komponanto, kiun vi regas

Se vi administras la aplikaĵon kaj ĝian klienton, difinu kune la atendatan servan identecon, la akceptatajn eldonantojn kaj ajnan postulon pri fiksado aŭ klienta aŭtentigo. Planu renovigon kaj reakiron tiel, ke laŭleĝa atestila ŝanĝo ne fariĝu interrompo. Se vi administras nur la publikan servilon, dokumentu, kiun aŭtentigon vi postulas kaj kiujn klientajn mediojn vi subtenas. Sendo de preferata ĉeno ne atestas aparaton de fremdulo.

Ĉe administrata ekipaĵo, solvu neakordecon per la posedantoj de la aplikaĵo kaj la reto. Malŝalti validigon, aldoni neklarigitan radikon, aŭ provi transpasi inspektan politikon ne starigas la celitan ekvalan rilaton.

Testu la rezulton sur pura klienta profilo, ne sur la maŝino, kie oni jam aldonis escepton. Tio estas la sola kontrolo, kiu montras, kion sperto nova aparato.