Праверка сертыфіката вэб-сайта праз HTTP-проксі з OpenSSL
Выкарыстоўвайце OpenSSL s_client праз HTTP CONNECT-проксі і ўзгадняйце імя мэты, SNI і праверку сертыфіката.
Выкарыстоўвайце ўсталяваны 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 паказаны сертыфікат можа быць выдадзены гэтым пасрэднікам. Параўнайце яго выдаўца і прадугледжаную схему даверу, перш чым тлумачыць розніцу зламаным вэб-сайтам.