გამოიყენეთ დაყენებული 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-ისას ნაჩვენები სერტიფიკატი შეიძლება იმ შუამავლის მიერ იყოს გაცემული. სხვაობის გაფუჭებულ ვებსაიტზე მიწერამდე შეადარეთ მისი გამცემი და ნდობის განზრახული მოწყობა.

დაკავშირებული სტატიები