Шалгалтын проксийн аль тал гэрчилгээгээс татгалзсан бэ?

Клиент зөвшөөрөгдсөн шалгалтын проксид итгэдэг. Гэсэн хэдий ч хүсэлт гэрчилгээний алдаанаас болж бүтэлгүйтдэг. Хоёр баримт хоёулаа үнэн байж болно: тэр проксид баталгаажуулах өөр нэг TLS харилцаа бий.

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

Таслан солилцох зохион байгуулалтад зуучлагч клиентийн TLS-ийг дуусгаад цааш өөрийн холболтыг үүсгэдэг. Клиент өөрийн талд үзүүлсэн гэрчилгээг хүлээн авч болох бол прокси вэбсайтаас авсан гэрчилгээгээс татгалздаг.

Баталгаажуулагчийн алдааг уншина уу

Амжилтгүй болсон гинжин хэлхээ эсвэл хост нэрийг аль процесс мэдээлснийг тодорхойлно уу. Проксийн үүсгэсэн алдааны хуудас хүчинтэй холболтоор клиентэд амжилттай хүрч болно. Клиентийн CA файлыг дахин өөрчлөх нь проксийн дээд урсгалын итгэлцлийн тохиргоог шинэчлэхгүй.

Жишээлбэл, Mitmproxy нь ssl_verify_upstream_trusted_ca зэрэг тусдаа дээд урсгалын итгэлцлийн сонголтуудыг баримтжуулдаг. Эрх бүхий администратор баталгаажуулалтыг хадгалан дээд урсгалын үйлчилгээнд зөвшөөрөгдсөн итгэлцэл тохируулах боломжтой. Өөр прокси бүтээгдэхүүнд өөрийн харгалзах интерфейс хэрэгтэй.

Бодит очих газрын нэр болон гинжин хэлхээг мөн шалгана уу. Завсрын гэрчилгээгүй хувийн үйлчилгээ, хугацаа дууссан гэрчилгээ, танигдаагүй хувийн олгогч нь өөр өөр засвар шаарддаг. Нэг хувийн үйлчилгээнд зориулсан үл хамаарах зүйл чимээгүйгээр бүх гэрчилгээг дэлхий даяар хүлээн зөвшөөрөх болж болохгүй.

Энгийн CONNECT хонгил өөр

Тунгалаг бус дамжуулах хонгил очих газрын TLS-ийг ингэж хуваахгүй. Програм ихэвчлэн тэр төгсгөлөөс төгсгөл хүртэлх TLS сессийг өөрөө хэлэлцэж, баталгаажуулдаг. Шалгалтын проксийн тохиргоог аль ч зуучлагчид хэрэглэхийн оронд таслан солилцох нь үнэхээр маршрутын хэсэг мөн эсэхийг эхлээд тогтооно уу.

Хоёр баталгаажуулалтын үр дүнг тус тусад нь бүртгэнэ үү. «Проксийн гэрчилгээнд итгэж болно» гэдэг нь клиент талын асуултад хариулдаг; прокси дээш холбогдохдоо юу харсныг нотолдоггүй.