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

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

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

Прачытайце памылку правяральніка

Вызначце, які працэс паведаміў пра збойны ланцуг або імя хоста. Старонка памылкі, створаная праксі, можа паспяхова дайсці да кліента праз сапраўднае злучэнне. Чарговае змяненне файла CA кліента не абнаўляе канфігурацыю даверу праксі да вышэйшага ўзроўню.

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

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

Звычайны тунель CONNECT іншы

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

Запішыце два вынікі праверкі асобна. «Сертыфікату праксі можна давяраць» адказвае на пытанне з боку кліента; ён не сведчыць пра тое, што праксі бачыў, калі злучаўся далей.

Падобныя артыкулы