ინსპექციის პროქსის რომელმა მხარემ უარყო სერტიფიკატი?

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

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

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

წაიკითხეთ შემმოწმებლის შეცდომა

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

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

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

ჩვეულებრივი CONNECT გვირაბი სხვაა

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

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