Выкарыстоўвайце ўсталяваны OpenSSL s_client, які падтрымлівае -proxy. Для аўтарызаванага канчатковага пункта HTTP CONNECT:

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 і HTTP-проксі з Basic-аўтэнтыфікацыяй выкарыстоўвайце параметры ўліковага запісу проксі s_client, захоўваючы праверку мэты.

Канчатковы пункт толькі SOCKS не дае інтэрфейсу HTTP-проксі, які выкарыстоўвае гэтая каманда. Пры дазволеным перахопе TLS паказаны сертыфікат можа быць выдадзены гэтым пасрэднікам. Параўнайце яго выдаўца і прадугледжаную схему даверу, перш чым тлумачыць розніцу зламаным вэб-сайтам.

Падобныя артыкулы