Firefox និង Cloudflare បើកការគាំទ្រ ECH សម្រាប់ការលាក់ដែននៅក្នុងចរាចរណ៍ HTTPS

Mozilla បានប្រកាសអំពីការដាក់បញ្ចូលការគាំទ្រសម្រាប់អ្នកប្រើប្រាស់នៃសាខាស្ថិរភាពរបស់ Firefox សម្រាប់យន្តការ ECH (Encrypted Client Hello) ដែលបន្តការអភិវឌ្ឍន៍បច្ចេកវិទ្យា ESNI (Encrypted Server Name Indication) និងត្រូវបានរចនាឡើងដើម្បីអ៊ិនគ្រីបព័ត៌មានអំពីប៉ារ៉ាម៉ែត្រនៃវគ្គ TLS ដូចជាឈ្មោះដែនដែលបានស្នើសុំ។ កូដសម្រាប់ធ្វើការជាមួយ ECH ត្រូវបានបន្ថែមដំបូងទៅ Firefox 85 ចេញផ្សាយ ប៉ុន្តែត្រូវបានបិទតាមលំនាំដើម។ Chrome បានចាប់ផ្តើមបញ្ចូលការគាំទ្រ ECH បន្តិចម្តងៗ ដោយចាប់ផ្តើមជាមួយនឹងការចេញផ្សាយ Chrome 115។

ចាប់តាំងពីបន្ថែមពីលើការតភ្ជាប់ជាមួយ ម៉ាស៊ីនមេ ព័ត៌មានដែនដែលបានស្នើសុំត្រូវបានលេចធ្លាយតាមរយៈ DNS។ ដើម្បីការពារពេញលេញ បន្ថែមពីលើ ECH អ្នកត្រូវតែប្រើ DNS លើ HTTPS ឬ DNS លើ TLS ដើម្បីអ៊ិនគ្រីបចរាចរណ៍ DNS។ Firefox នឹងមិនប្រើ ECH ដោយមិនបើក DNS លើ HTTPS នៅក្នុងការកំណត់ទេ។ អ្នកអាចពិនិត្យមើលការគាំទ្រ ECH នៅក្នុងកម្មវិធីរុករករបស់អ្នកនៅលើទំព័រនេះ។

កត្តាមួយក្នុងចំណោមកត្តាដែលបើកការគាំទ្រ ECH តាមលំនាំដើមនៅក្នុង Firefox គឺការដាក់បញ្ចូល Cloudflare នៃការគាំទ្រ ECH នៅក្នុងបណ្តាញចែកចាយមាតិការបស់វាកាលពីប៉ុន្មានថ្ងៃមុន។ នៅលើផ្នែកជាក់ស្តែង ចាប់តាំងពីទិន្នន័យអំពីម៉ាស៊ីនដែលបានស្នើសុំនៅពេលប្រើ ECH ត្រូវបានលាក់ពីការវិភាគ ការច្រោះ និងការទប់ស្កាត់គេហទំព័រដែលមិនចង់បានដោយប្រើ Cloudflare CDN ឥឡូវនេះនឹងតម្រូវឱ្យបិទបណ្តាញ Cloudflare ទាំងមូល ទប់ស្កាត់សំណើទាំងអស់ពី ECH ឬរៀបចំការស្ទាក់ចាប់ HTTPS ដោយប្រើវិញ្ញាបនបត្រឫសគល់ក្លែងក្លាយ។ នៅលើប្រព័ន្ធអ្នកប្រើប្រាស់។

ដំបូង ដើម្បីរៀបចំការងារនៅលើអាសយដ្ឋាន IP មួយនៃគេហទំព័រ HTTPS ជាច្រើន ផ្នែកបន្ថែម TLS SNI ត្រូវបានប្រើ ដែលឈ្មោះរបស់ម៉ាស៊ីនដែលបានស្នើសុំត្រូវបានចង្អុលបង្ហាញនៅក្នុងសារ ClientHello ដែលបានបញ្ជូន មុនពេលបង្កើតបណ្តាញទំនាក់ទំនងដែលបានអ៊ិនគ្រីប។ លក្ខណៈពិសេសនេះធ្វើឱ្យវាអាចចែកចាយសំណើរនៅលើម៉ាស៊ីននិម្មិតនៅដំណាក់កាលដំបូងនៃដំណើរការការតភ្ជាប់ ប៉ុន្តែក៏ធ្វើឱ្យវាអាចធ្វើទៅបាននៅលើផ្នែក ISP ដើម្បីជ្រើសរើសចរាចរ HTTPS និងវិភាគគេហទំព័រណាដែលអ្នកប្រើប្រាស់បើក ដែលមិនអនុញ្ញាតឱ្យសម្រេចបាននូវការសម្ងាត់ពេញលេញនៅពេលប្រើ។ HTTPS

ដើម្បីដោះស្រាយបញ្ហានេះ និងការពារការលេចធ្លាយព័ត៌មានអំពីគេហទំព័រដែលបានស្នើសុំ ផ្នែកបន្ថែម ESNI ត្រូវបានស្នើឡើងនៅពេលក្រោយ ដែលអនុវត្តការអ៊ិនគ្រីបទិន្នន័យដោយប្រើឈ្មោះម៉ាស៊ីន។ ក្នុងអំឡុងពេលនៃការអនុវត្ត ESNI វាត្រូវបានបង្ហាញថាយន្តការដែលបានស្នើឡើងមិនគ្របដណ្តប់ប្រភពដែលអាចកើតមាននៃការលេចធ្លាយទិន្នន័យម៉ាស៊ីនទេ ហើយការប្រើប្រាស់របស់វាគឺមិនគ្រប់គ្រាន់ដើម្បីធានាបាននូវការសម្ងាត់ពេញលេញនៃវគ្គ HTTPS នោះទេ។ ជាពិសេស នៅពេលបន្តវគ្គដែលបានបង្កើតពីមុន ឈ្មោះដែននៅក្នុងអត្ថបទច្បាស់លាស់បន្តត្រូវបានបញ្ជាក់ក្នុងចំណោមប៉ារ៉ាម៉ែត្រនៃផ្នែកបន្ថែម PSK (Pre-Shared Key) TLS ។ លើសពីនេះទៀត កិច្ចខិតខំប្រឹងប្រែងដើម្បីអនុវត្ត ESNI បានកំណត់បញ្ហាដែលត្រូវគ្នា និងការធ្វើមាត្រដ្ឋាន ដែលបានរារាំងការអនុម័តយ៉ាងទូលំទូលាយនៃ ESNI ។

ដោយគិតពីចំណុចខ្វះខាតដែលបានកំណត់អត្តសញ្ញាណរបស់ ESNI យន្តការ ECH ជាសកលថ្មីមួយត្រូវបានបង្កើតឡើងដែលអនុញ្ញាតឱ្យមានការអ៊ិនគ្រីបប៉ារ៉ាម៉ែត្រនៃផ្នែកបន្ថែម TLS ណាមួយ។ តាមបច្ចេកទេស ភាពខុសគ្នាសំខាន់រវាង ECH និង ESNI គឺថាជំនួសឱ្យវាលនីមួយៗ សារ ClientHello ទាំងមូលត្រូវបានអ៊ិនគ្រីបក្នុងពេលតែមួយ។ ECH ពាក់ព័ន្ធនឹងការបំបែក ClientHello ទៅជាសារពីរដាច់ដោយឡែកពីគ្នា - សារ ClientHelloInner ដែលបានអ៊ិនគ្រីប (SNI Inner) និងសារ ClientHelloOuter ដែលមិនបានអ៊ិនគ្រីប (SNI Outer) ។ SNI Outer ដែលមិនបានអ៊ិនគ្រីបផ្ទុកទិន្នន័យដែលមិនមែនជាឯកជនភាពដូចជាកំណែ TLS និងបញ្ជីនៃលេខកូដដែលបានប្រើ ក៏ដូចជាឈ្មោះដែនទូទៅដែលមិនត្រួតលើគ្នាជាមួយឈ្មោះពិតប្រាកដនៃដែនដែលបានស្នើសុំ។ ឧទាហរណ៍ សម្រាប់អតិថិជន Cloudflare ទាំងអស់ SNI Outer ដែលមិនបានអ៊ិនគ្រីបបញ្ជាក់ម៉ាស៊ីនទូទៅ "cloudflare-ech.com" ប៉ុន្តែឈ្មោះពិតរបស់ម៉ាស៊ីនដែលបានស្នើសុំត្រូវបានបញ្ជូននៅក្នុង SNI Inner ដែលបានអ៊ិនគ្រីប ហើយមិនមានសម្រាប់ការវិភាគទេ។

ECH ក៏ប្រើគ្រោងការណ៍ចែកចាយកូនសោអ៊ិនគ្រីបផ្សេងគ្នាផងដែរ៖ ព័ត៌មានកូនសោសាធារណៈត្រូវបានបញ្ជូននៅក្នុងកំណត់ត្រា DNS HTTPSSVC ជាជាងកំណត់ត្រា TXT។ ការអ៊ិនគ្រីបពីចុងដល់ចុងដែលបានផ្ទៀងផ្ទាត់ដោយផ្អែកលើយន្តការ HPKE (ការអ៊ិនគ្រីបកូនសោសាធារណៈចម្រុះ) ត្រូវបានប្រើដើម្បីទទួលបាន និងអ៊ិនគ្រីបកូនសោ។ ECH ក៏គាំទ្រការបញ្ជូនកូនសោឡើងវិញដែលមានសុវត្ថិភាពពីម៉ាស៊ីនមេ ដែលអាចត្រូវបានប្រើក្នុងករណីមានការបង្វិលកូនសោ។ ម៉ាស៊ីនបម្រើ និងដើម្បីដោះស្រាយបញ្ហាជាមួយនឹងការទាញយកសោហួសសម័យពីឃ្លាំងសម្ងាត់ DNS។

ប្រភព: opennet.ru