ვებგვერდის სერტიფიკატის შემოწმება HTTP პროქსის გავლით OpenSSL-ით
გამოიყენეთ OpenSSL s_client HTTP CONNECT პროქსის გავლით და შეათანხმეთ დანიშნულების სახელი, SNI და სერტიფიკატის შემოწმება.
გამოიყენეთ დაყენებული OpenSSL s_client, რომელიც -proxy-ს უჭერს მხარს. ავტორიზებული HTTP CONNECT endpoint-ისთვის:
openssl s_client -proxy proxy.example:3128 -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -showcertsშეცვალეთ პროქსის მისამართი და თანმიმდევრულად გამოიყენეთ დანიშნულების განზრახული სახელი. საჯარო დანიშნულების შესამოწმებლად არჩეული პროქსის გავლით, აირჩიეთ HTTP კანდიდატი HTTP პროქსების სიიდან. -connect ირჩევს სამიზნეს, -servername აგზავნის SNI-ს მის TLS ვირტუალურ ჰოსტზე, ხოლო -verify_hostname ამოწმებს იდენტობას. მხოლოდ SNI ჰოსტის სახელის დადასტურება არ არის. პარამეტრების მორგებისას იხილეთ დაყენებული რელიზის სახელმძღვანელო.
-showcerts აჩვენებს სერვერის მიერ გაგზავნილს და არ აცხადებს, რომ ჯაჭვი სანდოა. -verify_return_error შემოწმების შეცდომებისას handshake-ს ასრულებს; წინააღმდეგ შემთხვევაში დიაგნოსტიკურ კლიენტს შეცდომების შემდეგ გაგრძელება შეუძლია. კერძო სერვისისთვის გამოიყენეთ დამტკიცებული CA მასალა და ნუ ენდობით შემთხვევით ჩამოტვირთულ სერტიფიკატს.
| შედეგი | ეტაპი |
|---|---|
| 407 | პროქსის ავთენტიფიკაცია დანიშნულების TLS-მდე. |
| უარყოფილი CONNECT სამიზნე | პროქსის დანიშნულების პოლიტიკა. |
| სერტიფიკატი მიღებულია და შემოწმება სცადეს | დანიშნულების TLS გაცვლა მიღებული გვირაბის გავლით. |
OpenSSL 3.x-თან და Basic ავთენტიფიკაციის მქონე HTTP პროქსისთან გამოიყენეთ s_client-ის პროქსის ანგარიშის პარამეტრები და შეინარჩუნეთ დანიშნულების შემოწმება.
მხოლოდ SOCKS endpoint არ იძლევა HTTP პროქსის ინტერფეისს, რომელსაც ეს ბრძანება იყენებს. ავტორიზებული TLS interception-ისას ნაჩვენები სერტიფიკატი შეიძლება იმ შუამავლის მიერ იყოს გაცემული. სხვაობის გაფუჭებულ ვებსაიტზე მიწერამდე შეადარეთ მისი გამცემი და ნდობის განზრახული მოწყობა.