ในขณะที่หลายคนคิดว่า HTTPS นั้นปลอดภัยไร้ที่ติแล้ว AdGuard ก็ได้อัปเดตซีรีส์ 7.5 (เวอร์ชัน Windows ยืนยันเป็น 7.17 ส่วน Android และ Mac อัปเกรด CoreLibs พร้อมกัน) เพิ่มชิ้นส่วนสุดท้ายของปริศนาการปกป้องความเป็นส่วนตัว: การสนับสนุน **Encrypted ClientHello (ECH)** แบบทดลองที่ก้าวไปอีกขั้น พร้อมทั้งนำ DNS-over-HTTPS ฟิลเตอร์แบบทันทีมาใช้กับทุกอุปกรณ์ ถ้าคุณยังกังวลว่าผู้ให้บริการอินเทอร์เน็ตจะเห็นว่าเข้าชมเว็บไซต์ไหนบ้าง อัปเดตนี้คุ้มค่าที่จะใช้เวลาห้านาทีทำความเข้าใจ
ECH คืออะไร? ทำไมถึงถูกเรียกว่าชิ้นส่วนสุดท้ายของความเป็นส่วนตัว
ทุกครั้งที่คุณเปิดเว็บไซต์ HTTPS เบราว์เซอร์จะต้องส่งข้อความทักทายไปยังเซิร์ฟเวอร์ก่อน นั่นคือข้อความ
ClientHello ในการจับมือ TLS ปัญหาคือ ถึงแม้เนื้อหาภายในเพจจะถูกเข้ารหัสทั้งหมด แต่ข้อความ "สวัสดี" แรกนี้กลับมี **ชื่อโดเมนของเว็บไซต์ที่คุณกำลังจะไป** (Server Name Indication หรือ SNI) อย่างเปิดเผย ผู้ให้บริการอินเทอร์เน็ต ผู้ดูแล WiFi ตามสนามบิน หรือแม้แต่อุปกรณ์ดักฟังในตึก ก็สามารถเห็นได้ทันทีว่าคุณกำลังเข้าถึง `example.com` แม้จะไม่รู้ว่าคุณทำอะไรภายใน แต่ "คุณไปที่ไหน" นั้นไม่มีความลับอีกต่อไป
ECH ถูกออกแบบมาเพื่อแก้ปัญหาที่น่าอึดอัดนี้ โดยจะเข้ารหัส ClientHello ทั้งหมด มีเพียงคุณและเซิร์ฟเวอร์เป้าหมายเท่านั้นที่สามารถถอดรหัสได้ ฝ่ายกลางจะเห็นเพียงว่าคุณเชื่อมต่อกับโหนด CDN ที่รองรับ ECH แต่เว็บไซต์ไหนกันแน่? ให้เดาเอาละกัน พูดอีกอย่างคือ ECH ทำให้ HTTPS มีการเข้ารหัสตั้งแต่แพ็กเกจแรกถึงแพ็กเกจสุดท้ายอย่างสมบูรณ์
AdGuard 7.5 ทำได้อย่างไร? ECH ระดับระบบ ไม่จำกัดเบราว์เซอร์
ในอดีต ECH สามารถทำงานได้เฉพาะในเบราว์เซอร์เท่านั้น เช่น Chrome หรือ Firefox ที่ต้องเปิดตัวเลือกทดลอง และยังขึ้นอยู่กับฝั่งเว็บไซต์ว่าสนับสนุนหรือไม่ แต่วิธีการของ AdGuard แตกต่างอย่างสิ้นเชิง: จัดการทราฟฟิกในระดับระบบโดยตรง
ในบันทึกการอัปเดตเวอร์ชัน Android นักพัฒนายังเขียนติดตลกว่า "ขั้นตอนแรกในการรองรับ ECH กลับต้องเรียนรู้ที่จะ 'ปราบ' มันก่อน" เพราะ AdGuard มีสวิตช์ `pref.dns.block.ech` ภายในตัว และเมื่อใช้ร่วมกับ `pref.https.redirect.doh` ก็สามารถสกัดกั้นคำขอ ECH ดั้งเดิมไว้ก่อน จากนั้น AdGuard จะสร้างการเชื่อมต่อที่รองรับ ECH อย่างแท้จริงขึ้นมาใหม่เอง ด้วยวิธีนี้ **ทุกแอป ทุกเบราว์เซอร์บนโทรศัพท์ของคุณ ตราบใดที่ทราฟฟิกไหลผ่าน AdGuard ก็จะได้รับประโยชน์ด้านความเป็นส่วนตัวจาก ECH** โดยไม่ต้องรอให้ผู้พัฒนาแอปปรับแต่งแต่อย่างใด
เวอร์ชัน Windows 7.17 และ Mac 2.10 ก็มีฟีเจอร์ทดลองนี้ในตัวเช่นกัน และเพื่อให้ ECH ทำงานได้อย่างราบรื่น AdGuard จึงเปิดใช้งาน **DNS Filtering เป็นค่าเริ่มต้น** เป็นครั้งแรก เหตุผลง่าย ๆ: พารามิเตอร์การเข้ารหัสที่จำเป็นสำหรับ ECH ต้องได้จากระเบียน DNS HTTPS หากไม่ใช้โมดูลป้องกัน DNS ของ AdGuard เอง ก็จะไม่สามารถรับพารามิเตอร์เหล่านี้ในเครื่องเพื่อเข้ารหัสทั้งระบบได้
สามขั้นตอนตรวจสอบว่า ECH ทำงานจริงหรือไม่
AdGuard มีวิธีการตรวจสอบที่ง่ายมาก:
- ในการตั้งค่าขั้นสูง ตรวจสอบว่า Block ECH ปิดอยู่ และ DNS Protection เปิดใช้งานแล้ว
- เปิดตัวเลือกทดลอง Use Encrypted ClientHello (Windows/Android อยู่ใน "การตั้งค่าขั้นสูง" ส่วน Mac อยู่ในส่วนการตั้งค่า "เครือข่าย")
- เข้าไปที่
crypto.cloudflare.com/cdn-cgi/trace หากเห็น sni=encrypted หรือไปที่ www.cloudflare.com/ssl/encrypted-sni/ แล้วเห็น SSL_ECH_STATUS: success แสดงว่า ECH ทำงานสำเร็จ
หากทดสอบแล้วไม่ผ่าน อย่ารีบร้อน เพราะปัจจุบัน ECH ต้องการฝั่งเซิร์ฟเวอร์รองรับด้วย (เว็บไซต์ในเครือ Cloudflare ส่วนใหญ่เปิดไว้แล้ว) และเนื่องจากเป็นฟีเจอร์ทดลอง บางครั้งอาจส่งผลต่อความเร็วในการเรียกดูเล็กน้อย ทีมงานกำลังปรับปรุงประสิทธิภาพในส่วนนี้
ไม่ใช่แค่ ECH: DoH ฟิลเตอร์แบบทันที และการอัปเกรดเอนจินครั้งใหญ่
การปรับปรุงความเป็นส่วนตัวที่ AdGuard 7.5 นำมาให้นั้นไม่ได้มีแค่ ECH เท่านั้น เอนจินกรอง CoreLibs ได้รับการอัปเดตจาก v1.12.80 ไปจนถึง v1.14.59 พร้อมการปรับปรุงที่แข็งแกร่งหลายอย่าง:
- On-the-fly DNS-over-HTTPS ฟิลเตอร์: เดิมทีการกรองคำขอ DoH ค่อนข้างเชิงรับ หลังอัปเดตนี้ AdGuard สามารถสกัดกั้นและเปลี่ยนเส้นทางคำขอ DNS ที่ปลอดภัยไปยังพรอกซีในเครื่องแบบเรียลไทม์ ป้องกันการเลี่ยงผ่านฟิลเตอร์ของ DoH หมายความว่าแอปใดก็ตามที่พยายามหลบหนีผ่าน DNS เข้ารหัสจะถูกดึงกลับมา
- ECH GREASE และการดึงพารามิเตอร์: ดึงการกำหนดค่า ECH จากคำค้นหา DNS HTTPS ที่สกัดกั้น และฉีดค่า GREASE ลงในทราฟฟิก เพื่อป้องกันไม่ให้มิดเดิลแวร์ที่ไม่รองรับ ECH ก่อกวน และทำให้การเชื่อมต่อที่รองรับ ECH ทำงานราบรื่น
