สรุปสั้น
บริษัท Cloudflare กำลังสร้าง certificate authority (CA) ขึ้นมาเพื่อทำให้การยืนยันตัวตนเว็บไซต์แบบ post-quantum ใช้งานได้จริง โดยไม่ต้องให้การเชื่อมต่อ TLS แบกลายเซ็นขนาดใหญ่เกินจำเป็น แผนของบริษัทคือออกใบรับรองแบบเดิมควบคู่ไปกับ Merkle Tree Certificates หรือ MTC โดยตั้งเป้าให้ได้รับการยอมรับเข้าสู่ Quantum-resistant Root Store ตัวใหม่ของ Chrome ภายในต้นปี 2027 และการออก MTC มาตรฐานจะให้บริการฟรี โครงการนี้แก้ช่องว่างในโครงสร้างกุญแจสาธารณะของเว็บ ที่ปัจจุบันเบราว์เซอร์เชื่อถือ CA ให้ตรวจสอบการควบคุมโดเมนและผูกตัวตนของเว็บไซต์เข้ากับกุญแจสาธารณะ ขณะที่ล็อก Certificate Transparency เปิดให้ตรวจสอบการออกใบรับรองได้
ปัญหาคือ Cloudflare ประเมินว่าลายเซ็นแบบ post-quantum อาจเพิ่มความต้องการพื้นที่เก็บ Certificate Transparency ถึง 40 เท่า ทั้งที่ TLS handshake ปกติก็แบกลายเซ็นและกุญแจหลายตัวอยู่แล้ว เรื่องนี้สำคัญเพราะการยืนยันตัวตนที่ปลอดภัยต่อควอนตัมต้องรักษาทั้งความปลอดภัยและความเร็วในการตอบสนองข้ามเว็บไซต์ เบราว์เซอร์ ล็อก มอนิเตอร์ และการต่ออายุใบรับรองนับพันล้านรายการทั่วโลก MTC จึงออกแบบกระบวนการนี้ใหม่รอบ Merkle tree แบบ append-only เปลี่ยนกฎจาก “ล็อกสิ่งที่ออก” เป็น “ออกด้วยการล็อก” ทำให้ transparency กลายเป็นส่วนหนึ่งของการออกใบรับรองแทนที่จะเป็นสิ่งที่แนบตามมาทีหลัง
รายละเอียดข่าว
เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 30 กันยายน 2569 ว่า แทนที่จะเซ็นใบรับรองแต่ละใบแล้วส่งไปยังล็อกแยกต่างหาก CA จะบันทึกข้อมูลใบรับรองไว้ใน issuance log แล้วเซ็น checkpoint ที่ครอบคลุมสถานะของต้นไม้ จากนั้นเว็บไซต์จะได้รับ inclusion proof ซึ่งเป็นลำดับของค่าแฮชที่แสดงว่าใบรับรองของตนอยู่ในต้นไม้ที่ถูกเซ็นไว้
ตามงานวิจัยที่ Cloudflare เผยแพร่ กระบวนการทำงานจะใช้ ACME สำหรับการร้องขอและตรวจสอบการควบคุมโดเมน โดยบริการ ACME จะ fork มาจาก Boulder ซึ่งเป็นซอฟต์แวร์เบื้องหลัง Let’s Encrypt ที่กำลังพัฒนารองรับ MTC อยู่ หลังตรวจสอบแล้ว CA จะเพิ่มข้อมูลใบรับรองลงล็อก เซ็น checkpoint ที่อัปเดต แล้วส่งไปยัง mirroring cosigner ซึ่งเป็นบริการอิสระที่ตรวจความสอดคล้องแบบ append-only เก็บสำเนา และช่วยป้องกันไม่ให้ CA แสดงมุมมองล็อกที่ขัดแย้งกัน

ร่างนโยบายของ Chrome กำหนดให้ต้องมี cosignature จาก CA ที่ออกใบรับรองและอีกหนึ่งจาก mirror ที่ได้รับการรับรองซึ่งดำเนินการโดยองค์กรอื่น Cloudflare ตั้งใจสร้าง mirror ด้วย Azul ซึ่งเป็นซอฟต์แวร์ transparency-log แบบโอเพนซอร์สที่เขียนด้วยภาษา Rust ของบริษัทเอง พร้อมรองรับโปรโตคอล C2SP tlog-mirror เพื่อการทำงานร่วมกัน และต่อเมื่อได้ cosignature ครบตามที่กำหนด CA จึงจะประกอบกุญแจสาธารณะ inclusion proof และลายเซ็นเข้าเป็น MTC แบบ standalone
รายละเอียดช่องโหว่
ประสิทธิภาพที่ดีขึ้นมาจากใบรับรองแบบอิงจุดสังเกต (landmark-relative) เบราว์เซอร์สามารถรับโครงสร้างย่อยของต้นไม้ที่เรียกว่า landmark ผ่านช่องอัปเดตนอกแถบ (out-of-band) ระหว่างการเจรจา TLS เซิร์ฟเวอร์จะส่งเพียงข้อมูลใบรับรองของตนและ proof ขนาดเบาที่เชื่อมโยงไปยัง landmark ที่เชื่อถือได้ จึงตัดลายเซ็น post-quantum ขนาดใหญ่ออกจาก handshake ส่วน MTC แบบ standalone ยังจำเป็นเมื่อไคลเอนต์เป็นเครื่องใหม่ ออฟไลน์ หรือไม่มี landmark ปัจจุบัน
Cloudflare ระบุว่าการนำไปใช้กับผู้ใช้ Chrome Beta 146 ราว 50 เปอร์เซ็นต์สามารถให้บริการ MTC จำนวนหลายพันล้านรายการสำหรับโดเมนแผนฟรี โดย handshake แบบ landmark ส่งกุญแจสาธารณะหนึ่งตัว ลายเซ็นหนึ่งตัว และ inclusion proof ที่เล็กกว่า 1 KB ให้ความเร็วดีขึ้นที่ค่ามัธยฐาน 9 เปอร์เซ็นต์เมื่อเทียบกับสายใบรับรองแบบคลาสสิก อย่างไรก็ตามการทดลองนี้ใช้ลายเซ็นแบบคลาสสิก และ Cloudflare ยอมรับว่าความเร็วที่วัดได้ส่วนใหญ่มาจากการตัดใบรับรองตัวกลางออก
ผลกระทบ
การออกแบบนี้น่าสนใจแต่ยังไม่เสร็จสมบูรณ์ เพราะ MTC ยังเป็น Internet-Draft ของคณะทำงาน IETF PLANTS ไม่ใช่มาตรฐานที่สรุปแล้ว และ Cloudflare ยังต้องผ่านการพิจารณา root program ของ Chrome ก่อนที่เบราว์เซอร์จะเชื่อถือใบรับรอง การนำไปใช้จริงยังต้องพิสูจน์ว่ามอนิเตอร์อิสระ CA หลายราย และ cosigner ที่หลากหลายจะประมวลผลล็อกได้อย่างน่าเชื่อถือในระดับอินเทอร์เน็ต สำหรับฝ่ายตั้งรับ การเฝ้าระวัง CT ยังคงจำเป็น องค์กรที่เริ่มใช้การยืนยันตัวตนแบบ post-quantum ควรเฝ้าระวังใบรับรองแบบเดิมที่โผล่มาโดยไม่คาดคิด ซึ่งอาจเปิดเส้นทางลดระดับ (downgrade) ความปลอดภัยได้
คำแนะนำ
ผู้ดูแลระบบและทีมความปลอดภัยควรเริ่มทำความเข้าใจแนวทาง post-quantum สำหรับ TLS และวางแผนการเปลี่ยนผ่าน แม้มาตรฐาน MTC จะยังไม่สรุป ควรติดตามความคืบหน้าของ IETF PLANTS และนโยบาย root store ของ Chrome เพื่อประเมินผลต่อโครงสร้างใบรับรองขององค์กร ในระหว่างนี้ควรคงการเฝ้าระวัง Certificate Transparency เพื่อจับใบรับรองแบบเดิมที่ไม่คาดคิดซึ่งอาจถูกใช้เป็นช่องลดระดับความปลอดภัย และตรวจสอบว่าเครื่องมือและกระบวนการออก/ต่ออายุใบรับรองขององค์กรจะรองรับทั้งใบรับรองแบบเดิมและแบบ post-quantum ในช่วงเปลี่ยนผ่านได้
