როგორ გავხადოთ HTTPS პირველი მოთხოვნა VPN-ის საშუალებით

ბრაუზერმა, რომელიც პირველ რიგში აკრიფებს http://-ს და გადამისამართების შემდეგ ჯდება https://-ზე, უკვე გაგზავნილია ერთი მოთხოვნა გასუფთავებული და VPN არ ცვლის ამას. გვირაბი იცავს ფეხს კლიენტიდან გასასვლელ კვანძამდე; ის არაფერს შიფრავს სატრანსპორტო ფენის ზემოთ, ამიტომ დამკვირვებელი გასასვლელსა და საწყისს შორის მაინც ხედავს უბრალო ტექსტის ჰოპს. HTTPS-ის პირველი მოთხოვნა არის კლიენტის მხრიდან ცვლილება სამი ნაწილისგან: რეალური HTTPS მისამართი, ბრაუზერის განახლების რეჟიმი და საიტის საკუთარი პოლიტიკა. ქვემოთ მოცემული ნაბიჯები არის თანმიმდევრობა, რომელსაც მე ვიყენებ, თითოეულს აქვს ჩეკი, რომელიც გეტყვით, დასჭირდა თუ არა.

ნაბიჯი 1: დაადასტურეთ რა არის სინამდვილეში პირველი მოთხოვნა

სანამ რამეს შეცვლით, ნახეთ რას აგზავნის ბრაუზერი. გახსენით ქსელის პანელი ცივი ქეშიდან გადატვირთული გვერდით და წაიკითხეთ პირველი სტრიქონი: თუ სქემა არის http და სტატუსი 301 ან 308, ამ მწკრივის შემდეგ ყველაფერი მეორე მოთხოვნაა. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com აწარმოებს იმავე თანმიმდევრობას ბრაუზერის გარეთ და ბეჭდავს URL-ს, რომელზეც დაასრულეთ.

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

ნაბიჯი 2: ჩართეთ ბრაუზერის მხოლოდ HTTPS რეჟიმი

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

Firefox-ში კონტროლი განთავსებულია about:config და კონფიდენციალურობის პარამეტრების გვერდზე, dom.security.https_only_mode, როგორც გადამრთველი და თითო საიტის გამონაკლისები იმართება ბოქლომის მენიუდან. Chrome-სა და Edge-ში იგივე იდეა დევს სექციაში: პარამეტრები, კონფიდენციალურობა და უსაფრთხოება, უსაფრთხოება, იარლიყით ყოველთვის გამოიყენეთ უსაფრთხო კავშირები. როგორიც არ უნდა იყოს ეტიკეტი, გადაამოწმეთ ქცევა ჰოსტის მიმართ, რომელიც პასუხობს მხოლოდ 80-ე პორტზე, რადგან რეჟიმი, რომელიც განახლდება და შემდეგ ჩუმად უკან იხევს, არ არის დაცვა, რომელიც ფიქრობთ, რომ ჩართული გაქვთ. Firefox HTTPS-Only დოკუმენტაცია ასახავს ამ ბრაუზერის განახლებას, გაფრთხილებას და გამონაკლისის ქცევას.

ნაბიჯი 3: შეასწორეთ რესურსები და არა მხოლოდ მისამართების ზოლი

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

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

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

ნაბიჯი 4: რას ამატებს HSTS და რას არა

HSTS არის საიტის პოლიტიკა და არა ბრაუზერის პრიორიტეტი და ეს არის ერთადერთი მექანიზმი აქ, რომელიც გადარჩება აკრეფილ http://-ს ახალ პროფილზე. მას შემდეგ, რაც ბრაუზერი დაინახავს Strict-Transport-Security სათაურს ჰოსტისთვის, ის ხელახლა წერს შემდეგ მოთხოვნებს https-ზე გაგზავნამდე, რაც ზუსტად ის თვისებაა, რაც გსურთ. ის არაფერს აკეთებს ჰოსტისთვის, რომელსაც ბრაუზერი არასოდეს ეწვია და არაფერს აკეთებს სხვა ჰოსტის სახელისთვის, რომელიც ემსახურება იმავე აპლიკაციას.

შეამოწმეთ, რას აგზავნის წყარო curl -sSI https://example.com | grep -i strict-transport-security. გამოტოვებული სათაური არის სერვერის ცვლილება და არა ის, რაც კლიენტს შეუძლია დააინსტალიროს. თუ ის არსებობს, წაიკითხეთ max-age და დაყენებულია თუ არა includeSubDomains, რადგან მოკლე მაქსიმალური ასაკი იწურება ვიზიტებს შორის და გამოტოვებული includeSubDomains ტოვებს ყველა ქვედომენს დაუცველს. RFC 6797 განსაზღვრავს, თუ როგორ იყენებს მომხმარებლის აგენტი პოლიტიკას და რა შეიძლება უგულებელყოს. წინასწარ ჩატვირთვა ცალკე ვალდებულებაა, ამიტომ შეამოწმეთ სტატუსი hstspreload.org API-ით, სანამ ვინმეს დაჰპირდებით, რომ დომენი არის სიაში.

დადასტურება და უკან დაბრუნება

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

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

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