តើភាគីណានៃប្រូកស៊ីត្រួតពិនិត្យបានបដិសេធវិញ្ញាបនបត្រ?

អតិថិជនទុកចិត្តប្រូកស៊ីត្រួតពិនិត្យដែលបានអនុម័ត។ សំណើនៅតែបរាជ័យដោយសារកំហុសវិញ្ញាបនបត្រ។ ការពិតទាំងពីរអាចជាការពិត៖ ប្រូកស៊ីនោះមានទំនាក់ទំនង TLS មួយទៀតត្រូវផ្ទៀងផ្ទាត់។

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

ក្នុងការរៀបចំស្ទាក់ចាប់ អ្នកកណ្តាលបញ្ចប់ TLS របស់អតិថិជន ហើយបង្កើតការតភ្ជាប់ផ្ទាល់ខ្លួនបន្តទៅមុខ។ អតិថិជនអាចទទួលយកវិញ្ញាបនបត្រដែលបង្ហាញនៅខាងខ្លួន ខណៈដែលប្រូកស៊ីបដិសេធវិញ្ញាបនបត្រដែលវាទទួលបានពីគេហទំព័រ។

អានកំហុសរបស់អ្នកផ្ទៀងផ្ទាត់

កំណត់ថាដំណើរការណាដែលបានរាយការណ៍ពីខ្សែសង្វាក់ ឬឈ្មោះម៉ាស៊ីនដែលបរាជ័យ។ ទំព័រកំហុសដែលបង្កើតដោយប្រូកស៊ីអាចឈានដល់អតិថិជនដោយជោគជ័យតាមរយៈការតភ្ជាប់ត្រឹមត្រូវ។ ការផ្លាស់ប្តូរឯកសារ CA របស់អតិថិជនម្តងទៀតមិនធ្វើបច្ចុប្បន្នភាពការកំណត់ទុកចិត្តខាងលើរបស់ប្រូកស៊ីទេ។

ឧទាហរណ៍ Mitmproxy ចងក្រងជាឯកសារជម្រើសទុកចិត្តខាងលើដាច់ដោយឡែក រួមទាំង ssl_verify_upstream_trusted_ca។ អ្នកគ្រប់គ្រងសមស្របអាចកំណត់ការទុកចិត្តដែលបានអនុម័តសម្រាប់សេវាខាងលើ ខណៈរក្សាការផ្ទៀងផ្ទាត់។ ផលិតផលប្រូកស៊ីផ្សេងទៀតត្រូវការចំណុចប្រទាក់ដែលត្រូវគ្នា។

ពិនិត្យឈ្មោះគោលដៅពិត និងខ្សែសង្វាក់ផងដែរ។ សេវាឯកជនដែលខ្វះវិញ្ញាបនបត្រកណ្តាល វិញ្ញាបនបត្រផុតកំណត់ និងអ្នកចេញឯកជនដែលមិនស្គាល់ ត្រូវការការជួសជុលផ្សេងគ្នា។ ការលើកលែងដែលមានបំណងសម្រាប់សេវាឯកជនមួយ មិនគួរក្លាយជាការទទួលយកជាសកលនៃវិញ្ញាបនបត្រទាំងអស់ដោយស្ងាត់ៗទេ។

ផ្លូវរូង CONNECT ធម្មតាខុសគ្នា

ផ្លូវរូងបញ្ជូនបន្តស្រអាប់មិនបំបែក TLS គោលដៅតាមរបៀបនេះទេ។ ជាធម្មតា កម្មវិធីចរចា និងផ្ទៀងផ្ទាត់សម័យ TLS ពីចុងម្នាក់ទៅចុងម្នាក់នោះដោយខ្លួនឯង។ ជាដំបូង កំណត់ថាតើការស្ទាក់ចាប់ពិតជាផ្នែកនៃផ្លូវឬអត់ ជំនួសឱ្យការអនុវត្តការកំណត់ប្រូកស៊ីត្រួតពិនិត្យលើអ្នកកណ្តាលណាមួយ។

កត់ត្រាលទ្ធផលផ្ទៀងផ្ទាត់ទាំងពីរដោយឡែកពីគ្នា។ “វិញ្ញាបនបត្រប្រូកស៊ីគឺគួរឱ្យទុកចិត្ត” ឆ្លើយសំណួរខាងអតិថិជន។ វាមិនបញ្ជាក់អ្វីដែលប្រូកស៊ីបានឃើញនៅពេលវាតភ្ជាប់ខាងលើទេ។