პროქსის ხარვეზების კვლევა CRL და OCSP სერტიფიკატების შემოწმებებში

ვებსაიტის მოთხოვნამ შეიძლება მიაღწიოს თავის პროქსის და მაინც ჩავარდეს, რადგან სერტიფიკატის შემოწმებას კიდევ ერთი ქსელური მოთხოვნა სჭირდება. CRL ან OCSP მოძიება შეიძლება განხორციელდეს პლატფორმის კომპონენტის მეშვეობით, რომლის ანგარიში და პროქსის პოლიტიკა განსხვავდება აპლიკაციის HTTP კლიენტისგან.

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

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

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

.NET-ში ჯაჭვის პოლიტიკაზე UrlRetrievalTimeout აკონტროლებს ონლაინ შემოწმების ან CRL მოძიების ლოდინს. ჩვეულებრივი HTTP პასუხის დროის გახანგრძლივება არ ახანგრძლივებს იმავე ტაიმერს, ხოლო მოძიების ტაიმერის გახანგრძლივება არ იძლევა პროქსის სერტიფიკატებს ან მარშრუტს.

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