რატომ შეიძლება ბრაუზერებმა დაფარონ Squid-ის HTTPS დაბლოკვის გვერდი
გაიგეთ, რატომ შეიძლება ბრაუზერმა აჩვენოს საკუთარი გვირაბის შეცდომა უარყოფილი CONNECT მოთხოვნისთვის დაბრუნებული მორგებული HTML-ის ნაცვლად.
პროქსის მორგებული დაბლოკვის გვერდი ჩანს HTTP საიტისთვის. HTTPS საიტისთვის ბრაუზერი სამაგიეროდ აჩვენებს გვირაბის შეცდომას. HTML შაბლონის ხელახლა შეცვლამ შეიძლება არაფერი შეცვალოს.
გამოკვეთილი HTTP პროქსით HTTPS ვიზიტი ჩვეულებრივ იწყება CONNECT-ით. ბრაუზერი პროქსის სთხოვს გახსნას გვირაბი ჰოსტისა და პორტისკენ. თუ Squid უარყოფს ამ მოთხოვნას, საიტის TLS სესია არასოდეს იწყება.
უარყოფას შეიძლება ჰქონდეს HTTP სტატუსი და პასუხის შიგთავსი. შეგიძლიათ შეამოწმოთ ეს წარუმატებელი CONNECT პასუხი curl-ით ბრაუზერის შეცდომის გვერდისგან დამოუკიდებლად. ეს არ მოითხოვს, რომ ბრაუზერმა მოწოდებული HTML წარმოადგინოს დანიშნულების ვებგვერდად. ბრაუზერმა შეიძლება გადააგდოს CONNECT შეცდომის სხეული და გამოიყენოს საკუთარი პროქსი შეცდომის ინტერფეისი; ზუსტი წარდგენა დამოკიდებულია კლიენტზე.
თუ Squid-ის უარყოფა უკვე შეიცავს განზრახ deny_info სხეულს, მისი ტექსტის, სტილის ფურცლის ან ფაილის ნებართვების რედაქტირება არ ცვლის, პასუხის რომელ ეტაპს ამუშავებს ბრაუზერი. შეინახეთ უარყოფის სტატუსი და წვდომის ჟურნალი ხელმისაწვდომი, რათა დაადგინოთ, უარყოფილ იქნა CONNECT და რატომ. ზოგადმა ბრაუზერის გვერდმა შეიძლება დაფაროს პოლიტიკის დეტალები, მაშინ როცა პროქსი სწორად აღასრულებს წესს.
დაბლოკვის გვერდის მიწოდება ჩაჭერილ HTTPS კავშირში სხვა არქიტექტურაა, რომელიც მოიცავს TLS-ის დასრულებას, კლიენტის ნდობას და სერტიფიკატების დამუშავებას. ის არ აქტიურდება deny_info-ის რედაქტირებით და მორგებული შაბლონი არ იძლევა რაიმე უფლებამოსილებას დაბლოკილი საიტის განსახიერებისთვის. აირჩიეთ ეს დიზაინი მხოლოდ საჭიროების შემთხვევაში; წინააღმდეგ შემთხვევაში გამოიყენეთ კლიენტის ხელმისაწვდომი შეცდომების ანგარიშგება და პროქსის ოპერატიული ჟურნალები.