ქეში VPN-ის უკან: რას მალავს HTTPS ჯერ კიდევ

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

TLS სეანსი ბრაუზერს ეკუთვნის

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

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

CONNECT გვირაბია, არა ქეში

აშკარა წინა პროქსი ჩვეულებრივ იღებს HTTP CONNECT მოთხოვნას და შემდეგ ბაიტებს ორივე მიმართულებით გადასცემს. გადაცემა მთავარი სიტყვაა: პროქსი დაშიფრულ საუბარს არ აანალიზებს.

curl -sSI -x http://proxy.example:3128 https://example.com/

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

ქეშირეთ ის, რასაც მართავთ, და არა ის, რასაც ათვალიერებთ

სადაც შიგთავსი თქვენია, უკუპროქსის შეუძლია TLS-ის დასრულება და დამტკიცებული პასუხების განზრახ შენახვა. სადაც ის პაკეტების საცავს ეკუთვნის, გამოიყენეთ ის სარკე, რომელსაც პროექტი მხარს უჭერს.

nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"

პირველი ბრძანება გვიჩვენებს, არის თუ არა ქეშის ზონა კონფიგურირებული და სად მოქმედებს, ხოლო მეორე - წყაროს საკუთარ ქეშირების მითითებებს ერთი ობიექტისთვის. საზიარო ქეშმა უნდა პატივი სცეს სიახლეს, ქეშის კონტროლს და მოთხოვნის იმ ატრიბუტებს, რომლებიც წარმოდგენებს არჩევს; private და no-store სხვადასხვა რამეს ნიშნავს და არც ერთი არ უნდა მოიხსნას დარტყმის მაჩვენებლის ასამაღლებლად. HTTP ქეშირების წესები ასევე ზღუდავს პასუხების შენახვას ავტორიზებული მოთხოვნებისთვის, და სწორედ იქ იქცევა პერსონალიზებული გვერდი მონაცემთა გამჟღავნებად. შეზღუდეთ პროქსი დამტკიცებულ კლიენტებზე, ნაცვლად ღია რელეს გამოფენისა.

გაზომეთ დარტყმა, არა წამზომი

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

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