უფრო გრძელი SOCKS ჯაჭვი შემდეგ ნახტომს ავტომატურად არ მალავს

ჯაჭვი ცვლის, ვინ ხსნის ყოველ კავშირს. ის არ ამატებს დაშიფვრას მხოლოდ იმიტომ, რომ სიაში კიდევ ერთი SOCKS მისამართი დაემატა.

განვიხილოთ კლიენტი, რომელიც ამ ჯაჭვს თავად აშენებს:

application → SOCKS A → SOCKS B → website

ის ჯერ A-ს სთხოვს B-სთან დაკავშირებას. ამ ნაკადის მეშვეობით მას შემდეგ შეუძლია B-სთან საიტთან დაკავშირებაზე მოლაპარაკება. თუ კლიენტიდან A-მდე ტრანსპორტი ორივე მოლაპარაკებას დაშიფვრის გარეშე გადაიტანს, ამ რგოლზე საკმარისად უნარიან დამკვირვებელს შეუძლია წაიკითხოს კლიენტის მიერ გაგზავნილი კონფიგურაციის ბაიტები. გარე TCP დანიშნულება დამკვირვებლის ერთადერთი შესაძლო მტკიცებულება არ არის.

გამოყავით ჯაჭვი დაცული აპლიკაციის გაცვლისგან

HTTPS-ს შეუძლია საიტის აპლიკაციის შიგთავსის დაცვა მას შემდეგ, რაც მისი TLS სესია დაიწყება. ის უკუძალით არ შიფრავს ადრინდელ SOCKS კონფიგურაციის შეტყობინებებს. SOCKS5-ის მომხმარებლის სახელით და პაროლით ავთენტიფიკაციაც არ არის დაშიფრული ტრანსპორტი.

დაშიფრული მოწყობა კლიენტსა და პირველ ნახტომს შორის ცვლის ხილვადობას ამ რგოლზე. მას კვლავ ჰყავს ოპერატორი და კიდევ ერთი ბოლო წერტილი, რომელიც ინახავს გაშიფრილ ნაკადს. აღწერეთ ეს ნდობის საზღვარი იმის მტკიცების ნაცვლად, რომ ჯაჭვის მიკვლევა შეუძლებელია.

სერვერზე კონფიგურირებული მშობლიური მარშრუტი სხვა ტოპოლოგიაა. თუ A შიდად ირჩევს B-ს, კლიენტმა სულაც არ არის ვალდებული თავისი პირველი კავშირით გაგზავნოს შუამავლების სრული სია. ნუ ამტკიცებთ, რომ ყოველი ჯაჭვი ყოველ ნახტომს ერთნაირად ამჟღავნებს.

სასარგებლო კონფიდენციალურობის შეფასებისთვის დაასახელეთ დამკვირვებელი, რგოლი, პროქსისთან მოლაპარაკება და TLS საზღვრები. B-ის გასასვლელზე დამკვირვებელი საიტი და კლიენტის პირველ კავშირზე დამკვირვებელი წვდომის ქსელის დამკვირვებელი სხვადასხვა კითხვას პასუხობენ. მხოლოდ ნახტომების დათვლა არც ერთს არ პასუხობს.