ប្រើ OpenSSL s_client ដែលបានដំឡើង និងគាំទ្រ -proxy។ សម្រាប់ endpoint 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 virtual host របស់វា ហើយ -verify_hostname ពិនិត្យអត្តសញ្ញាណ។ SNI តែមួយមិនមែនជាការផ្ទៀងផ្ទាត់ឈ្មោះ host ទេ។ ពេលកែជម្រើស សូមពិនិត្យ សៀវភៅណែនាំរបស់ release ដែលបានដំឡើង។

-showcerts បង្ហាញអ្វីដែល server បានផ្ញើ មិនមែនប្រកាសថា chain គួរឱ្យទុកចិត្តទេ។ -verify_return_error ធ្វើឱ្យ verification errors បញ្ចប់ handshake; បើមិនដូច្នោះ diagnostic client អាចបន្តបន្ទាប់ពីកំហុស។ សម្រាប់សេវាឯកជន ប្រើ CA material ដែលបានអនុម័ត ជំនួសឱ្យជឿលើ certificate ដែលបានទាញយកដោយចៃដន្យ។

លទ្ធផលដំណាក់កាល
407ការផ្ទៀងផ្ទាត់ប្រូកស៊ី មុន TLS របស់គោលដៅ។
គោលដៅ CONNECT ត្រូវបានបដិសេធគោលការណ៍គោលដៅរបស់ប្រូកស៊ី។
ទទួលបានវិញ្ញាបនបត្រ និងបានព្យាយាមផ្ទៀងផ្ទាត់ការផ្លាស់ប្តូរ TLS របស់គោលដៅតាម tunnel ដែលបានទទួលយក។

ជាមួយ OpenSSL 3.x និងប្រូកស៊ី HTTP ដែលផ្ទៀងផ្ទាត់ដោយ Basic សូមប្រើ ជម្រើសគណនីប្រូកស៊ីរបស់ s_client ដោយរក្សាការផ្ទៀងផ្ទាត់គោលដៅ។

endpoint ដែលមានតែ SOCKS មិនផ្តល់ HTTP proxy interface ដែលពាក្យបញ្ជានេះប្រើទេ។ នៅពេលមាន TLS interception ដែលបានអនុញ្ញាត certificate ដែលបង្ហាញអាចត្រូវបានចេញដោយ intermediary នោះ។ ប្រៀបធៀប អ្នកចេញ និង trust arrangement ដែលបានគ្រោង មុននឹងបន្ទោសគេហទំព័រខូចចំពោះភាពខុសគ្នា។

អត្ថបទពាក់ព័ន្ធ