on
กระบวนการออกใบรับรองดิจิตอลทุกวันนี้มีช่องว่างสำคัญคือหน่วยงานออกใบรับรองดิจิตอล (certification authority - CA) ทุกรายสามารถออกใบรับรองให้กับโดเมนใดๆ ก็ได้ ตอนนี้มาตรการเพิ่มเติมในการจำกัดสิทธิ์ของ CA ก็เตรียมบังคับใช้เดือนกันยายนนี้ หลังการโหวตมาตรฐาน Certification Authority Authorization (CAA) โดย CA/Browser Forum ผ่านไปแล้ว
CAA เป็นมาตรฐาน rfc6844 มาตั้งแต่ปี 2013 ระบุให้เจ้าของโดเมนสามารถล็อก CA ที่จะออกใบรับรองให้กับโดเมนของตนได้ ผ่าน Resource Record (RR) ใน DNS เช่น example.org. CAA 128 issue "letsencrypt.org" จะล็อกให้ Let's Encrypt เท่านั้นที่สามารถออกใบรับรองให้กับ example.com ได้
CAA มีความคล้ายกับ HPKP ที่ล็อก CA เช่นเดียวกัน แต่ HPKP นั้นล็อกจากฝั่งเบราว์เซอร์ที่จะไม่ยอมรับใบรับรองจาก CA รายอื่นที่ไม่ได้ระบุไว้ HPKP มีผลดีกว่ามากคือสามารถป้องกันปัญหาได้ทั้งกรณีเจ้าของโดเมนผิดพลาด เช่น เปิดทางให้ผู้ใช้บนเว็บเข้าอีเมลหรืออัพโหลดไฟล์ตรวจสอบได้ รวมไปถึงการป้องกัน CA ที่ตรวจสอบความเป็นเจ้าของโดเมนผิดพลาดเอง แต่ HPKP คอนฟิกได้ยากและหากผิดพลาดก็จะมีผลร้ายแรง คือเบราว์เซอร์อาจจะไม่ยอมรับเว็บที่ถูกต้องจนกว่าค่า HPKP จะหมดอายุไปเลย CAA นั้นช่วยลดความเสี่ยงได้แต่ช่วยแจ้ง CA ที่ไม่อยู่ในรายการไม่ออกใบรับรองโดยไม่ตั้งใจ
ผลการลงมติบังคับ CAA มีผลเกือบเอกฉันท์ มีเพียง Sertifitseerimiskeskus จากเอสโทเนียเท่านั้นที่โหวตคัดค้าน และจะมีผลเดือนกันยายนนี้ ตอนนี้ทาง Qualys SSL Labs ก็รายงานแล้วว่าเว็บใดบ้างที่เปิด CAA เอาไว้ (ตัวอย่าง Google.com)
ที่มา - Qualys Blog
ขยายความเพิ่มว่าการล็อกว่า CA
e.p. Tue, 14/03/2017 - 23:08
ขยายความเพิ่มว่าการล็อกว่า CA ไหนที่จะเป็นคนออกใบรับรองได้นั้น__ตัว CA เป็นคนเช็คจาก CAA record เอง__ ดังนั้นถ้ามี CA ที่อยู่นอกรายการที่ระบุใน CAA ออกจะออกใบรับรองก็ยังสามารถทำได้อยู่ (CA อื่นๆ จะออกใบรับรองเพื่อมาดักฟังก็ทำได้เหมือนเดิม)
ใน RFC 6844 ระบุด้วยว่าเนื่องจากใบรับรองมีอายุนาน เป็นไปได้ที่ขณะใช้งานใบรับรองอยู่ตัว CA อาจจะไม่ได้อยู่ในรายการ CAA ปัจจุบันแล้ว (แต่เคยอยู่ในขณะออกใบรับรอง) ดังนั้น__ห้ามใช้ CAA record ในการทำ certificate validation__
สรุปสั้นๆ คือป้องกัน CA ที่ประพฤติตัวดีไม่ให้ออกใบรับรองพลาดในบางกรณี แต่ไม่ช่วยในการป้องกันความจงใจ...
เคสนี้คือถ้า CA ฝ่าด่าน
lew Tue, 14/03/2017 - 23:47
In reply to ขยายความเพิ่มว่าการล็อกว่า CA by e.p.
เคสนี้คือถ้า CA ฝ่าด่าน ออกใบรับรองทั้งๆ ที่มีหลักฐานว่าทำ CAA ไว้ จากเดิมที่บอกว่ามีความผิดพลาดอย่างอื่นๆ ได้ (เช่นเจ้าของโดเมนพลาดเอง) และ CA นี้ไม่เชื่อ CAA หลังจากนี้ถ้าชัดตัว CA ก็มีโอกาสปลิวตาม WoSign, Diginotar, และ CNNIC ไป
พิสูจน์ CAA
e.p. Wed, 15/03/2017 - 07:01
In reply to เคสนี้คือถ้า CA ฝ่าด่าน by lew
พิสูจน์ CAA ว่าเคยมีหรือไม่เคยมีในเวลาที่ออกใบรับรองก็ไม่ง่ายนะครับ มันไม่มีหลักฐาน
ยกตัวอย่างอีกเคส
e.p. Wed, 15/03/2017 - 07:56
In reply to เคสนี้คือถ้า CA ฝ่าด่าน by lew
ยกตัวอย่างอีกเคส ถ้าผู้ขอใบรับรองจงใจสร้าง views ใน DNS ให้ผู้ออกใบรับรองมองเห็น CAA record ที่ระบุชื่อ CA ของตัวไว้ได้คนเดียวแล้วขอใบรับรองไป
คนอื่นๆ ที่อยู่นอกวงจะมองว่า CA ออกใบรับรองเถื่อนไหมครับ? แถม CA เองก็ไม่รู้ด้วยว่าเห็น CAA อันนั้นอยู่คนเดียว
หรือจะสร้าง CAA แล้วขอใบรับรอง ได้แล้วเอา CAA ออก แล้วไปฟ้องว่า CA ออกใบรับรองโดยพละการได้ไหม เพราะ CA เองไม่มีหลักฐานอะไรเลยว่ามันเคยมีอยู่ (ยกเว้นใช้ DNSSEC แล้วเก็บข้อมูลที่ใช้ทำ validation ทุกขั้นเอาไว้ แต่ในกรณีนี้เค้าก็ไม่ได้บังคับว่าต้องทำ DNSSEC)
Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not
required. An issuer MUST NOT issue certificates if doing so would
conflict with the relevant CAA Resource Record set, irrespective of
whether the corresponding DNS records are signed.
DNSSEC provides a proof of non-existence for both DNS domains and RR
set within domains. DNSSEC verification thus enables an issuer to
determine if the answer to a CAA record query is empty because the RR
set is empty or if it is non-empty but the response has been
suppressed.
Use of DNSSEC allows an issuer to acquire and archive a proof that
they were authorized to issue certificates for the domain.
Verification of such archives MAY be an audit requirement to verify
CAA record processing compliance. Publication of such archives MAY
be a transparency requirement to verify CAA record processing
compliance.