Урт SOCKS гинжин хэлхээ дараагийн алхмыг автоматаар нуухгүй
Клиент өөрөө бүтээсэн SOCKS гинжин хэлхээний шифрлэгдээгүй тохиргооны мессежийг өөр алхам очих газрын мета өгөгдлийг нуудаг гэж үзэхээс өмнө тодорхойл.
Гинж нь холбогдол бүрийг хэн нээхийг өөрчилдөг. Жагсаалтад өөр нэг SOCKS хаяг нэмэхэд шифрлэлт нэмэгддэггүй.
Энэ гинжийг өөрөө бүтээдэг клиентийг авч үзье:
application → SOCKS A → SOCKS B → websiteЭхлээд A-аас B-тэй холбогдохыг хүснэ. Тэр урсгалаар дамжуулан дараа нь B-тэй вэбсайт руу холбогдох талаар хэлэлцэж чадна. Хэрэв клиентээс A хүртэлх дамжуулалт хоёр хэлэлцээрийг шифрлэлтгүй зөөвөрлөвөл тухайн холбоос дээрх хангалттай чадамжтай ажиглагч клиентийн илгээсэн тохиргооны байтуудыг уншиж чадна. Гадаад TCP очих газар нь ажиглагчийн цорын ганц боломжит нотолгоо биш.
Гинжийг хамгаалагдсан програмын солилцооноос тусгаарла
HTTPS нь вэбсайтын програмын агуулгыг TLS сесс эхэлсний дараа хамгаалж чадна. Гэхдээ өмнөх SOCKS тохиргооны мессежийг буцаагаад шифрлэдэггүй. SOCKS5-ийн хэрэглэгчийн нэр/нууц үгийн баталгаажуулалт ч шифрлэгдсэн дамжуулалт биш.
Клиент ба эхний алхмын хоорондох шифрлэгдсэн зохион байгуулалт тухайн холбоос дээрх харагдах байдлыг өөрчилдөг. Түүнд ажиллуулагч болон тайлагдсан урсгалыг барьдаг өөр нэг төгсгөлийн цэг байсаар байна. Гинжийг мөрдөх боломжгүй гэж мэдэгдэхийн оронд тэр итгэлийн хил хязгаарыг тайлбарла.
Сервер дээр тохируулсан эх замын чиглэл нь өөр топологи юм. Хэрэв A дотроо B-г сонговол клиент эхний холболтоороо зуучлагчдын бүрэн жагсаалтыг илгээсэн байх албагүй. Гинж бүр алхам бүрийг адилхан илчилдэг гэж бүү мэдэгд.
Хэрэгтэй нууцлалын үнэлгээний тулд ажиглагч, холбоос, прокситой хийх хэлэлцээр, TLS-ийн хил хязгаарыг нэрлэ. B-ийн гаралтыг ажигладаг вэбсайт болон клиентийн эхний холболтыг хардаг хандалтын сүлжээний ажиглагч өөр асуултад хариулдаг. Зөвхөн алхмыг тоолох нь хоёуланд нь хариулт өгөхгүй.