Ці можа ланцуг сертыфікатаў сервера перавызначыць сховішча даверу кліента?

Браўзер паказвае папярэджанне пра сертыфікат на сайце, ланцуг якога поўны, і першая думка — выправіць сервер. Звычайна сервер прад’яўляе менавіта тое, што павінен. Кліент вырашае, якія якары ён прымае, і ніякае размяшчэнне прамежкавых сертыфікатаў не можа змяніць гэтае рашэнне з другога канца злучэння. Гэтая мяжа тлумачыць большасць таго, што выглядае як праблема з сертыфікатам.

Праверка выконваецца на кліенце, з якарамі кліента

Праверка шляху бярэ прад’яўленыя сертыфікаты і будуе ланцуг да якара даверу, які сістэма праверкі ўжо мае. RFC 5280 апісвае гэтую мадэль і змяшчае выбар якара ў лакальную рэалізацыю, а не ў сервер. Праграма можа дадаць сваю палітыку зверху: замацаваны ключ, карпаратыўнае сховішча даверу, або больш строгую праверку асобы. Спіс сертыфікатаў, які адпраўляе сервер, — гэта доказ, прапанаваны гэтаму працэсу, а не ўказанне яму.

Такім чынам, поўны ланцуг даказвае, што сервер мае часткі. Ён не даказвае, што кліент іх прыме.

Каб убачыць, што сервер фактычна адпраўляе, запусціце openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts і палічыце сертыфікаты ў вывадзе. Няпоўны ланцуг там — гэта выпраўленне на баку сервера. Поўны ланцуг пераносіць пытанне на кліент і яго якары, дзе сервер не мае голасу.

Што насамрэч змяняе інспекцыя TLS

Прылада інспекцыі завяршае TLS-сесію з боку кліента і адкрывае асобную сесію да рэальнай службы. Затым кліент правярае сертыфікат прылады, які павінен весці да якара, якому кліент давярае. Таму кіраваныя прылады атрымліваюць корань інспекцыі праз кіраванне прыладамі, і таму асабістая прылада без яго паказвае папярэджанне.

Гэтае ўладкаванне наўмыснае і лакальнае. Нішто ў ланцугу першапачатковага сервера не можа прымусіць некіраваны браўзер прыняць падменную асобу, і нішто ў ім не перашкаджае кіраванай прыладзе зрабіць гэта.

Завяршэнне VPN — гэта не расшыфроўка HTTPS

Слой VPN пераносіць пакеты паміж кліентам і шлюзам. Яго выдаленне або чытанне яго канфігурацыі не раскрывае HTTPS-нагрузку ўнутры.

TLS-сесія па-ранейшаму ідзе паміж браўзерам і вэб-серверам, з тымі ж правіламі праверкі, калі нешта яўна яе не завяршае. Блытаніна двух слаёў спараджае просьбу да адміністратара VPN прадаставіць сертыфікат, тады як сертыфікат належыць праксі інспекцыі або самому сайту. Спытайце, які кампанент прад’яўляе сертыфікат, перш чым змяняць любое сховішча даверу.

Вызначце чаканні ў кампаненце, які вы кантралюеце

Калі вы кіруеце праграмай і яе кліентам, вызначце чаканую асобу службы, прыманыя выдаўцы і любое патрабаванне замацавання або аўтэнтыфікацыі кліента разам. Плануйце абнаўленне і аднаўленне так, каб законнае змяненне сертыфіката не стала перапынкам. Калі вы кіруеце толькі публічным серверам, дакументуйце, якая аўтэнтыфікацыя патрабуецца і якія асяроддзі кліента падтрымліваюцца. Адпраўка пераважнага ланцуга не сертыфікуе чужую прыладу.

На кіраваным абсталяванні вырашайце несумяшчальнасць праз уладальнікаў праграмы і сеткі. Адключэнне праверкі, даданне непатлумачанага кораня або спроба перачакаць палітыку інспекцыі не ўсталёўваюць патрэбныя адносіны бакоў.

Праверце вынік на чыстым профілі кліента, а не на машыне, дзе выключэнне ўжо дададзена. Гэта адзіная праверка, якая паказвае, што адчуе новая прылада.