Gumamit ng naka-install na OpenSSL s_client na sumusuporta sa -proxy. Para sa awtorisadong 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

Palitan ang proxy address at gamitin nang pare-pareho ang nilalayong destination name. Para subukan ang public destination sa pamamagitan ng proxy na maaari mong piliin, pumili ng HTTP candidate mula sa HTTP proxy list. Pinipili ng -connect ang target, nagpapadala ang -servername ng SNI para sa TLS virtual host nito, at sinusuri ng -verify_hostname ang identity. Ang SNI lamang ay hindi hostname verification. Tingnan ang manual ng naka-install na release kapag inaangkop ang mga option.

Ipinapakita ng -showcerts ang ipinadala ng server, hindi nito ipinapahayag na trusted ang chain. Ginagawa ng -verify_return_error na matapos ang handshake kapag may verification error; kung hindi, maaaring magpatuloy ang diagnostic client pagkatapos ng error. Para sa private service, gumamit ng approved CA material sa halip na magtiwala sa random na na-download na certificate.

ResultaYugto
407Proxy authentication bago ang destination TLS.
Tinanggihang CONNECT targetProxy destination policy.
Natanggap ang certificate at sinubukang i-verifyDestination TLS exchange sa pamamagitan ng tinanggap na tunnel.

Sa OpenSSL 3.x at HTTP proxy na gumagamit ng Basic authentication, gamitin ang s_client proxy-account options habang pinapanatili ang destination verification.

Ang SOCKS-only endpoint ay hindi nagbibigay ng HTTP proxy interface na ginagamit ng command na ito. Sa awtorisadong TLS interception, maaaring ang intermediary na iyon ang nag-issue ng ipinakitang certificate. Ihambing ang issuer nito at intended trust arrangement bago sisihin ang sirang website sa pagkakaiba.

Kaugnay na mga artikulo