WRONG_VERSION_NUMBER ជាមួយប្រូកស៊ី៖ ពិនិត្យ HTTP និង HTTPS

កំហុសនិយាយថា “កំណែខុស” ដូច្នេះវាទាក់ទាញឱ្យចាប់ផ្តើមប្តូរកំណែ TLS។ ជាមួយប្រូកស៊ី សូមពិនិត្យលទ្ធភាពមួយមុនសិន៖ តើអតិថិជនបានផ្ញើការចាប់ដៃ TLS ទៅកាន់ច្រកដែលកំពុងរង់ចាំ HTTP ធម្មតាដែរឬទេ?

គោលដៅដូចជា https://example.com/ និងប្រូកស៊ីដូចជា http://proxy.example:8080 គឺជាគូធម្មតា។ ការប្តូរ URL ទីពីរទៅ HTTPS ប្រាប់អតិថិជនឱ្យអ៊ិនគ្រីបការសន្ទនារបស់ខ្លួនជាមួយប្រូកស៊ីខ្លួនឯង។ នេះមិនមែនជាការណែនាំឱ្យអនុញ្ញាតគេហទំព័រ HTTPS ទេ។

រកការសន្ទនា TLS ដំបូង

ជាមួយប្រូកស៊ី HTTP អតិថិជនអាចផ្ញើ CONNECT មុន ហើយទទួលការឆ្លើយតប HTTP។ បន្ទាប់មកទើបវាចាប់ផ្តើម TLS របស់គោលដៅនៅក្នុងផ្លូវរូង។ ជាមួយប្រូកស៊ី HTTPS ជាដំបូងគឺ ការតភ្ជាប់ TLS ដាច់ដោយឡែកទៅប្រូកស៊ី។

ឧបករណ៍ញែក TLS ដែលទទួលទំព័រកំហុស HTTP ឬអត្ថបទធម្មតាផ្សេងទៀតអាចរាយការណ៍កំហុសពិធីការ។ ពាក្យទាំងនោះមិនបញ្ជាក់ថាតើគេហទំព័រគាំទ្រកំណែ TLS ណាទេ ហើយក៏មិនបញ្ជាក់ថាបានទាក់ទងគេហទំព័រនោះដែរ។

1. កត់ត្រា URL របស់ប្រូកស៊ី រួមទាំងគ្រោងការណ៍របស់វា និងពិធីការដែលបានចងក្រងនៃចំណុចចេញ។
2. រកថាតើការបរាជ័យកើតឡើងមុនការឆ្លើយតប CONNECT អំឡុងពេល TLS របស់គោលដៅ ឬពេលផ្ទៀងផ្ទាត់វិញ្ញាបនបត្ររបស់ប្រូកស៊ីខ្លួនឯង។
3. ពិនិត្យកំណែពិតរបស់អតិថិជន និងភាពអាស្រ័យ ពេលប្រៀបធៀបដំណោះស្រាយចាស់។ ការអនុវត្តប្រូកស៊ីមុនៗ ពេលខ្លះចាត់ទុកគ្រោងការណ៍ខុសគ្នា។

ការកែច្រើនអាចខុសដោយហេតុផលផ្សេងៗ។ បញ្ជីប្រូកស៊ី HTTP ផ្តល់បេក្ខជនចំណុចចេញ HTTP ធម្មតាសម្រាប់សំណើសាធារណៈដែលត្រូវបានអនុញ្ញាតតាមផ្លូវបែបនេះ។ ចំណុចចេញ HTTP ធម្មតាត្រូវការគ្រោងការណ៍ប្រូកស៊ី HTTP; ចំណុចចេញដែលបានបើក TLS ពិតប្រាកដគួររក្សា HTTPS និងការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្ររបស់វា។ ប្រូកស៊ីដែលបដិសេធ CONNECT ត្រូវការសេវា ឬគោលនយោបាយដែលគាំទ្រ មិនមែនការបន្ថយបណ្ណាល័យតាមអំពើចិត្តទេ។

រក្សាការបរាជ័យដំបូងដែលអាចសង្កេតបាន។ ការបិទការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រ មិនអាចធ្វើឱ្យឧបករណ៍ស្តាប់ដែលចេះតែ HTTP និយាយ TLS បានឡើយ ហើយការជ្រើសគោលនយោបាយស៊ីហ្វឺចាស់ ក៏មិនអាចពន្យល់ការបដិសេធ HTTP ដែលផ្ញើមុនការចាប់ដៃគេហទំព័របានដែរ។